如何在AppSec测试中处理SAST FPs

GitMore

已于 2022-06-20 18:06:29 修改

阅读量670

点赞数

分类专栏： DevSecOps分享文章标签： web安全安全代码复审源代码管理 devops

于 2022-06-20 17:19:38 首次发布

本文链接：https://blog.csdn.net/qzt961003/article/details/125376591

版权

DevSecOps分享专栏收录该内容

36 篇文章 4 订阅

订阅专栏

SAST（静态应用程序安全测试）是一种行之有效的应用程序安全测试技术，它有助于开发人员创建高质量和更安全的软件，以便抵御近年来越来越普遍的各种攻击。

然后，SAST最大的不足之处在于它往往会产生大量的假正例（False Positives），浪费开发团队大量的时间。接下来，我会介绍关于SAST FPs的一些基础知识，以及如何避免这些麻烦。

一、SAST

SAST是一种应用程序测试方法，它通过扫描源代码来发现潜在的设计缺陷，并利用静态程序分析来发现漏洞。在SAST中，我们不需要运行应用程序代码就可以进行扫描，因此SAST也被称为白盒测试。

SAST是AST（应用程序安全测试）中使用的几种方法之一，其他的还有DAST、IAST和SCA。（这部分内容具体的可以看我之前发的文章，这里就不赘述了）

在理想情况下，SAST在SDLC的早期阶段执行。通过将安全性左移，开发人员能够快速修复问题，而不会破坏架构，也不会将漏洞传递到开发后期阶段，这样可以有效的节约安全成本。

与DAST、IAST相比，SAST的一个最大的优点是能够几乎100%的识别代码库中的缺陷。例如，DAST无法检测到不恰当的加密，但SAST很容易就可以检测到。

二、什么是SAST FPs

尽管SAST有许多优点，但它不可避免的会产生较多的FPs（假正例）。

简单的来说，FPs看上去像漏洞但实际上并不是漏洞，或者直白的说就是误报。但考虑到信号检测论的相关知识，将FPs和误报直接画上等号并不严谨，不过从理解层面上来说二者几乎一致。为了更好的说明FPs的基本概念，让我们来看两个典型的例子。

1.一个SQL注入的示例：

final var allowedColumns = List.of(“col1”, “col2”, “col3”);

if(allowedColumns.contains(userInput)){

stmt.executeQuery(“SELECT ” + userInput + ” FROM table”)

在本例中，userInput是一个来自外部的字符串，这就是所谓的“受污染数据（taint data）”。这种数据很容易被攻击者控制，并且可能会导致SQL注入。

当这个受污染的数据到达一个可能造成损害的代码位置时，这里就被称为污染槽（taint sink）。在上面的代码中，executeQuery method就是SQL注入的污染槽。如果没有进一步的保护措施，攻击者可以通过userInput添加一个有害的字符串来攻击数据库，然后使用它来进行恶意攻击，比如删除所有用户、获得管理员权限等等。

通常，SAST工具检测是否存在到污染槽的路径，即污染流（taint flow）。如果存在，则报告检测到了一个漏洞。但是，如果对该流采取了一些措施，以便只有无害的数据可以到达接收器，那么实际上是没有漏洞的。这种措施被称为污染无害处理（taint sanitizers），即通过数据加密或者移除危害操作等手段使数据传播不再对系统的信息安全产生危害。通过这种方法，攻击者就不能使用有害字符串访问executeQuery调用。

一般来说sanitizers可以是一些典型的库函数，也可以是“自制”函数。在上述情况下，allowedColumns.include(userInput)充当的是sanitizers，它来检查userInput是不是被允许的字符串。

但是，在SAST的视角里，防止SQL注入的最佳方法是使用预处理语句。你在这里没有使用，所以它就认为这里存在漏洞。但实际上，你用了sanitizers不是吗，于是乎，FPs产生了。

2.特定的上下文漏洞：

安全工具根本无法预先知道某个软件是否足够敏感，需要身份验证和授权。因此，许多工具对每种类型的未经身份验证的访问都进行报告，这会产生FPs，但实际上这些访问时无害的。例如，对提供每日时间查找的软件的未经身份验证的访问可能并不是一个真正的漏洞。

三、出现FPs的原因

接下来我们可以来探讨FPs出现的真正原因了。

所有SAST工具产生的结果都可以分为四类：（为了方便理解，接下来的相关描述不与信号检测论进行区分，因为正如开头所说，它们在理解层面几乎一致）

1.True Positives（TPs）：真正例、正确接受——正确识别存在的漏洞；

2.True Negatives（TNs）：真负例、正确拒斥——正确识别不存在的漏洞；

3.False Positives（FPs）：假正例、虚报——错误的认定某个漏洞存在，但实际上它并不存在；’

4.False Negative（FNs）：假负例、漏报——未检测到漏洞的存在，但实际上它是存在的。

任何SAST工具的目标都应该是最大限度的增加TPs和TNs的数量，同时最大限度的减少FPs和FNs的数量。然而，从工程学的角度来说，这是不可能实现的。因此，工程师需要做出一个设计决策：他是否应该让SAST来产生更多的TPs，同时也产生更多的FPs？又或者他应该让SAST减少FPs，代价是错过一些TPs？

OWASP建立了一个免费和开源的Benchmark项目，它是一个示例应用程序，其中包含数千个可利用的漏洞，有些是真的，有些是假的。你可以运行各种SAST工具并对结果进行评分然后绘图：

理想状况下，最佳结果应该是在最左上角——表示最小的FPs和最大的TPs。但实际上，ROC是一条曲线，你永远无法达到最左上角。因此，FPs是不可避免的，而且为了实现较高的TPs，往往会导致较高的FPs。这也就是SAST扫描结果的实质——即TPs和FPs之间的动态平衡。

从外在表现形式来说，在SAST测试中，有两个主要的误报原因：

1.超过scanners的假设

为了支持好几种编程语言，一些SAST工具包含了太多的假设，在大多数情况下，这些假设是通用的，不能准确的应用于所有编程语言。

如果一些源代码对这些工具没有意义，或者缺少一个依赖项，那么SAST就会认为代码一定存在问题。因此，这些工具会产生大量的误报。

2.设计不当的规则

一些传统的SAST工具设计很差，不能准确的标记漏洞。为了弥补这一点，厂商为了安全起见，往往会将工具设置成即使只有一点点迹象表明可能存在问题，也会发出漏洞警报。

例如，一些SAST工具在字符串变量名中搜索某些单词，以确定它们是否包含敏感数据，如身份验证凭据、密钥和密码。让我们来看看下面的代码：

userPasswordLabel.Text = “Please enter your password”;

虽然变量名包含“password”，但这并不一定意味着它包含敏感信息。这可能只是个标签，如果SAST不能执行进一步的分析，已确定变量是否显示敏感数据，它很可能会产生FPs。

四、如何尽可能避免SAST FPs

1.选择一个好的工具

衡量一个SAST工具的最简单的方法就是用它的TPs去减FPs。但是，这一方法是不全面的，例如有这两个SAST工具，每个工具都与上文提到的OWASP项目进行对比检测：

A.检测出了10个TPs和3个FPs，准确率为70%；

B.检测出了100个TPs和30个FPs，准确率为70%。

尽管这两个工具的准确率得分相同，但你可能会偏爱其中的一款。因此，我们需要引入一些额外的指标，例如：

a.完整性：TPs与实际存在的漏洞总数之比。较高的完整性评分（理论上最大值为1）表明SAST工具能够检测应用程序中存在的更多问题，提供更好的代码可见性。

b.深度：指工具检测各种漏洞的能力。如果一款SAST工具支持大量的编程语言，并有一个全面的漏洞数据库，那它的覆盖深度是很好的。

2.定制规则

将定制的规则集应用于 SAST 工具将有助于减少误报的数量。使用工具的默认设置可能不适合组织的特定需要。如果您将 SAST 工具配置为您的首选项，它可以帮助检测正确的问题并最大限度地减少误报。实现一个没有自定义的工具可能会产生很多垃圾，这可能会让您错过困扰您的软件的真正问题。

3.过滤和优先排序

您还可以过滤掉对软件的健康无关紧要的结果。例如，您可以忽略来自组成“dead code”的软件部分或未被调用的包的结果。这将有助于根据对组织最重要的内容对测试结果进行优先排序。您可以根据威胁的严重程度、漏洞的状态以及解决问题的能力对它们进行优先排序。这将使您能够集中精力解决最关键的异常情况，而不是浪费精力处理影响很小或没有影响的问题。