DAST (动态应用程序安全测试)工具的结果是否为假阳性？

Question

我知道静态应用程序安全测试(，SAST)的结果可能是假阳性的，也可能是真实的，这取决于安全分析人员和开发人员根据场景和上下文来决定哪个漏洞是真实的。

同样适用于DAST扫描结果吗？

到目前为止，我相信DAST (动态应用程序安全测试)工具的结果都是真实的/真实的，需要解决。有些结果也会是假阳性吗？DAST是否需要开发人员和安全分析人员同样的时间和精力来过滤假阳性？

Answer 1

DAST绝对会有假阳性。这取决于您正在使用的工具，但也有一些可能给您数百个假阳性。

例如，工具可能通过插入单引号和检查SQL错误消息来检查SQL注入，但存在错误消息并不一定意味着存在SQL注入漏洞。

就像SAST一样，您应该在计划开发时间来修复它之前，验证实际上存在一个漏洞。

Answer 2

哦，是的，我刚刚完成了一份满是假阳性的报告(我从一份20页的DAST报告中拿出了一张合法的罚单)。我的意思是，就像@BrianWilliams的例子一样，这个工具报告它们是正确的，因为它们在某些场景中可能是真实的，但是需要一个熟练的分析师来决定是否在这个场景中应用。我在最后一小时看到的一些例子：

• 默认umask太宽了。我的分析是:不相关，因为这是一个IoT设备，应用程序无论如何都会以根用户的身份运行。
• 没有设置X帧ClickJacking保护。我的分析:不相关，因为它在静态的，非交互式的网页上。
• 失踪的CSRF保护。我的分析是:不正确，一旦登录，(非cookie) auth令牌就会计数，但是工具盲目地寻找一个名为"CSRF“的标头。
• 启用了TLS 1.0。我的分析:是的，我们需要它的兼容性！
• 带有弱选项的分区--我的分析:不相关，因为如果你能进入设备内感染分区，那么你已经在设备内了.

是的，我们可以(而且可能应该)修复它们，只是为了不那么草率，但是它们在这个应用程序中是不可利用的，所以它不再是一个安全问题，它会与其他技术债务/代码清理任务混为一谈。

关于你的问题：

DAST是否需要开发人员和安全分析人员同样的时间和精力来过滤假阳性？

您希望开发人员参与到这个过程中来，这样他们就可以不断提高自己的安全技能，并编写更安全的代码！手握的数量取决于开发人员的技能。

对于一些团队，我需要做100%的报告，对需要改变的特定事物进行分类和打开罚单。对于其他团队，我与开发人员进行了分类，对于一个经验丰富的开发团队，他们几乎完成了100%的分阶段工作，我在每次发布之前都签署了他们的分析。

对我来说，一位盲目要求修复SAST/DAST报告中所有内容的安全分析师要么懒惰，要么不了解他们应该保护的技术。

听起来你需要在你的分类过程中付出更多的努力，并且作为安全分析人员，你需要深入了解每一个报告的漏洞将决定它是否真的需要修复(这将产生扩展你自己技能的副作用)。

借用伟大的坦尼娅·贾卡：

“在Dev和安全团队之间制造敌意的最简单的方法是向开发人员盲目地抛出自动化报告，并说修复它！”-- Tanya