每种测试形式的相对优缺点是什么?
即静态代码分析和运行时/动态渗透测试有什么区别?
各自的优缺点是什么?是否存在一种比另一种更可取的情况?
白盒与黑盒
我相信这个问题最好在Mark Dowd、Justin Schuh 和 John McDonald 所著的The Art of Software Security Assessment 的第 4 章中得到解决。
如果没有它作为参考,我可以安全地告诉你,最好的方法是使用运行时数据和源代码,同时使用黑盒测试确定“命中”(或跟踪,也就是覆盖率)——但只有在威胁模型之后并且系统的一般架构是众所周知的。
当与候选点策略结合使用时,作者似乎也喜欢安全的静态代码分析,尽管我认为这些在价值上可能会有很大差异,假设以下情况不正确:
- 安全静态分析工具必须支持该语言及其基类库
- 整个系统通常必须可用。即它必须包括可构建的源代码,包括所有第三方/contrib 组件和外部库——甚至可能包括系统编译器、VM 或原始系统的其他工件
- 不属于基类库的所有外部组件/库必须在安全静态分析工具的 source-sink-passthru 数据库中定义源和接收器。某些通路(即过滤器)的复杂性可能因实施或实施者而异,因此几乎总是需要自定义配置
- 某些模式或架构代码元素的额外使用可能会导致其他变化,这可能需要大多数现代安全静态分析工具无法实现的定制
由于上述原因,以及 NIST SATE 研究(由 NIST SAMATE 完成)中提出的原因,我发现很难推荐许多用于白盒分析的安全静态分析工具。使用最有可能涉及从上到下阅读源代码的代码理解策略几乎总是更好,如果您正在寻找托管代码 rootkit 等,这真的非常重要。
我不会测试和审计/评估应用程序,而是采用一种不同的方法,这种方法在很大程度上与技术无关。我的建议是实施一个应用程序安全风险管理门户,其中包括一个应用程序清单以及每个应用程序当前实施的应用程序安全控制。在初始基线之后,应根据 MITRE CWE、SAFEcode 和 OWASP ASVS 等行业标准评估应用程序安全控制。然后可以使用差距分析(请注意,这是一个标准风险管理术语,在基于 ISO 27001 或类似标准的信息安全管理计划中实施时效果最佳)可用于确定最佳应用程序安全控制,以及获得从当前实施的控制到所需的控制。
您应该在执行风险评估活动(例如白盒或黑盒测试)之前实施此风险管理门户,以获得更好的结果,并衡量您的计划是否成功。
这里有一些非常好的答案,但我认为补充几点很重要:
- 正如@atdre 提到的,它不应该是/或,它们是两种不同的生物,它们测量不同的东西。如果可能的话,你应该两者都做。
- 同样正如@atdre 所说,测试——即使是白盒+黑盒——是不够的。为了确保安全,您还需要做其他事情,包括所有整体 SDL,以及适当的风险管理、分析等。
- 重点... Blackbox 通常更快,通常是数量级。白盒(包括代码审查)通常需要更多的工作。
- 黑盒(即渗透测试)的成本通常比白盒便宜,不仅是总成本,而且是每小时成本。
- 有比白盒更多的优质 3rd 方黑盒提供商 - 不是总数,而是只计算那些真正知道他们在做什么的人。(或者这只是我的看法?)
- WB 经常发现比 BB 更深的漏洞。
- WB 通常可以找到故障过滤器,而 BB 无法绕过(直到知道过滤器是如何构造的——灰盒测试的另一个要点)。
- BB 甚至无法测试许多类型的缺陷 - 例如审计日志、加密缺陷、后端强化等。
- BB 可以测试整个系统,所有非代码保护都已到位(例如 WAF、IPS、操作系统强化等),而 WB 仅在应用程序级别(例如代码/设计等)。请注意,这可能是双向的 - 有时您会被阻止完成 BB 扫描,即使一旦您知道向量,您就可以绕过保护。
- 同样,BB 可以发现子系统之间的错误交互,而 WB 通常会错过它。将此视为单元测试与系统测试。
- WB 通常可以在系统完成之前很久就执行,BB 需要构建、编译、启动和运行(最好是大多数功能性错误都已消除)。当可以在生命周期的早期进行审查时,这可以使 SDL 更加高效。
- 另一方面,如果系统已经启动,启动 BB 很简单,但如果你想做 WB(做对了),你必须开始寻找所有源代码、库、工具等。通常,你甚至没有源代码,因为它的第 3 方、COTS 等。
黑盒子
- 优点:简单、快速和简单的测试
- 缺点:有时无法测试应用程序的某些部分(检查散列算法、会话 id 熵……);您无法确定整个应用程序是否经过测试
白盒
- 优点:检查源代码的能力(节省时间 - 如果您可以看到参数在任何地方都以安全的方式使用,则无需测试 SQL 注入);您可以使用 GUI 测试不可访问/不可测试的应用程序部分
- 缺点:测试可能变得非常复杂
一般来说,白盒测试允许您深入研究源代码并执行完整的渗透测试,但可能非常耗时,而黑盒测试则简单、快速且简单。我更喜欢灰盒测试——使用黑盒方法和采访开发人员/仅在应用程序的特定部分(身份验证、会话管理、配置管理......)检查源代码。