白盒与黑盒

Question

每种测试形式的相对优势和缺点是什么？

也就是说，静态代码分析和运行时/动态渗透测试之间有什么区别？

每种方法的优缺点是什么？是否有一种比另一种更可取的情况？

Answer 1

这里有一些非常好的答案，但我认为还有几点是很重要的：

• 正如@atdre所提到的，它不应该是或者，它们是两种不同的生物，它们测量不同的东西。如果可能的话，你应该两者兼得。
• 此外，正如@atdre所说，测试--即使是白盒+黑盒--也是不够的。您还需要做其他的事情来确保安全，包括所有的整体SDL，以及适当的风险管理、分析等。
• 说到重点..。黑匣子通常更快，通常是数量级。Whitebox (包括代码评审)通常需要更多的工作。
• 黑匣子(即五箱)的成本通常比白盒便宜，不仅在总数上，而且在每小时也是如此。
• 有更多的质量第三方黑匣子供应商比白盒-不是全部，但只包括那些真正知道他们在做什么。(或者这只是我的看法？)
• WB经常发现比BB更深的漏洞。
• WB经常能找到错误的滤波器，BB无法绕过(直到知道过滤器是如何构造的-另一个点向灰色盒测试)。
• 有许多类型的缺陷BB甚至无法测试-例如审计日志，密码缺陷，后端硬化，等等。
• BB可以测试整个系统，所有的非代码保护都到位了(例如WAF、IPS、OS强化等等)。其中WB仅在应用程序级别(例如代码/设计等)。请注意，这可能是双向的-有时你会被阻止完成BB扫描，即使一旦你知道了矢量，你将能够绕过保护。
• 类似地，BB可以发现子系统之间的错误交互，而WB通常会错过它。将此视为单元测试与系统测试。
• WB通常可以在系统完成之前执行很久，BB需要构建、编译、启动和运行(最好是大多数功能错误被清除)。这可以提高SDL的效率，因为在生命周期的早期就可以进行检查。
• 另一方面，如果一个系统已经启动，启动BB很简单，但是如果你想做WB (做的对)，你必须开始搜索所有的源代码，库，工具等。通常，你甚至没有源代码，因为它的第三方，COTS，等等。

Answer 2

我相信这个问题最好在软件安全评估的艺术的第4章中解决，这本书是由Mark，Justin和John McDonald写的。

如果没有它作为参考，我可以安全地告诉您，最好的方法是使用运行时数据和源代码，同时使用黑匣子测试来确定“命中”(或跟踪，也就是覆盖范围) --但只有在系统的模型和一般体系结构都是众所周知的威胁之后。

作者似乎也喜欢将安全的静态代码分析与候选点策略相结合，尽管我认为，假设以下情况不正确，这些策略的价值可能会大不相同：

• 该语言及其基类库必须由安全静态分析工具支持。
• 整个系统必须是可用的。也就是说，它必须包括可构建的源代码，包括所有第三方/控制组件和外部库--甚至可能包括系统编译器、VM或原始系统的其他构件。
• 不是基类库一部分的所有外部组件/库都必须在安全静态分析工具的源-接收器-passthru数据库中定义源和接收器。某些passthrus (即过滤器)的复杂性可能因实现或实现者而异，因此几乎总是需要自定义配置。
• 对某些模式或体系结构代码元素的额外使用可能会导致其他变化，这可能需要使用大多数现代安全静态分析工具无法进行的自定义。

由于上述原因，以及NIST SATE研究(由NIST SAMATE完成)中提出的原因，我发现很难推荐许多安全的静态分析工具用于白盒分析。使用最有可能从上到下阅读源代码的代码理解策略几乎总是更好，如果您正在寻找托管代码、rootkit等，这是非常重要的。

而不是测试和审计/评估应用程序，我会采取一种不同的方法，在很大程度上是非常技术不可知论。我的建议是实现一个应用程序安全风险管理门户，其中包括一个应用程序清单以及每个应用程序当前实现的应用程序安全控制。在初始基线之后，应用程序安全控制应该根据行业标准(如MITRE、SAFEcode和OWASP )进行评估。差距分析(注意，这是一个标准的风险管理术语，并且在基于ISO 27001或类似标准的信息安全管理程序中实现时效果最好)然后可以用来确定最佳的应用程序安全控制，以及从当前实现的控制到所需的控制的路径。

在执行风险评估活动(如白盒或黑匣子测试)之前，您应该实现此风险管理门户，以便获得更好的结果，并衡量程序的成功程度。

Answer 3

黑匣子

• 优点:简单、快速、简单的测试
• 缺点:有时不可能测试应用程序的某些部分(检查哈希算法、会话id熵、.)；您无法确定整个应用程序是否经过了测试

白盒

• 优点:能够检查源代码(节省时间-如果可以看到参数在任何地方都以安全的方式使用，就不需要测试SQL注入)；您可以测试应用程序中使用GUI无法访问/测试的部分。
• 缺点:测试可能变得非常复杂。

一般来说，白盒测试允许您深入源代码并执行完整的渗透测试，但这是非常耗时的，而黑匣子是简单、快速和简单的。我更喜欢灰色盒测试--使用黑匣子方法，并且只在应用程序的特定部分(身份验证、会话管理、配置管理，.)访问开发人员/检查源代码。