为什么传统黑盒测试正在拖累现代应用安全团队

应用程序早已从单体结构演变为复杂的云原生架构。这意味着我们所依赖的、经过时间考验的方法正变得危险地过时。为了使应用安全（AppSec）能够跟上步伐，我们必须超越当前的工具集，重新审视动态应用安全测试（DAST）——即自动化黑盒测试——的最基本理念。

黑盒安全测试的基础

在深入探讨现代挑战之前，让我们先回顾任何成功的黑盒安全测试所依赖的三个支柱——即使在技术变迁中依然保持不变的基础：

这些基本原则始终受到两大资源的制约：

服务器负载：系统（尤其是生产系统）能否承受测试负载？测试生产环境通常是理想的，因为它包含了所有业务关键数据，并且与预发布环境永远不可能完全一致。
扫描时间与成本：资源是有限的。在快速构建管道中运行的扫描与在 QA 环境中的扫描，其时间预算是不同的。此外，渲染、流量甚至 AI 令牌的计算成本也必须考虑在内。

黑盒测试的基本原理是稳定的，但我们所测试的应用程序已经发生了彻底的革命。

单体遗留架构（“过去的好日子”）

在传统的 LAMP 栈时代，事情更简单：

现代应用程序架构

如今，架构变得复杂且分层，打破了所有旧有的假设：

URL ≠ 状态：应用程序状态现在由操作（例如点击按钮将产品添加到购物车）驱动，而不仅仅是 URL。现代 URL 经常使用片段（#），并且可能通过 JavaScript 历史 API 在客户端更改，而不会触发 HTTP 请求。
隐藏的技术栈：应用程序现在由 CDN、云存储、容器组、消息队列（如 Kafka）和调度程序组成。底层技术被隐藏在许多层后面并受到保护。
载荷在组件间触发：一个载荷可能通过 Kafka 消息总线传播，并在一个独立的系统中触发，这可能是由于不同编程语言之间的序列化/反序列化差异造成的，甚至可能在第三方服务（例如日志记录工具）中触发。

由于架构发生了根本性变化，难怪许多基于几十年前底层项目的黑盒工具都难以跟上步伐。

为了应对现代应用程序的挑战，黑盒工具必须改进其处理状态、载荷和断言的方法。

1. 生成状态

图，而非树：URL 树已经过时。现代 Web 应用必须建模为一个图，其中节点是状态，边是修改状态的、经过推测的操作。这需要对客户端和服务器端状态都进行建模。
状态的重建：仅靠 URL 或 HAR 存档已无法可靠地重建状态。工具必须重放达到特定状态所采取的操作序列。
短暂的状态：状态的有效期越来越短（例如，具有短 TTL 的 JWT），这使得传统爬虫难以有效地在后续对其进行测试。

2. 构造载荷

上下文感知的载荷：由于整个技术栈是隐藏的，载荷必须设计成能在多种上下文中工作。一个单独的字符串必须在不同编程语言间的序列化/反序列化过程中存活下来，因为它会在系统中传播，并可能在另一个软件栈中触发。

3. 进行断言

延迟的和带外触发：载荷现在可能在很久之后才触发，可能在排队处理之后，或从不同的视图返回之后。Log4j 漏洞就是一个明显的例子，载荷在架构深处触发，需要使用带外方法和网络 pingback 来检测。
更嘈杂的系统：测量系统行为（例如使用响应时间进行盲 SQL 注入）在基于消息队列和负载均衡的架构中几乎是不可能的。

关键不在于“把所有东西都 AI 化”，而是战略性地使用先进方法来优化决策。我们在 Detectify 已经开始推出几项下一代评估更新来解决这个问题，动态载荷轮换（Dynamic Payload Rotation）就是我们的 API 扫描器的一个典型例子，更多功能计划于明年初推出。

该功能利用一个近乎无限的载荷池，将恒定的检查与实验性的变体混合。如果一个实验性载荷成功，它会立即在该技术栈的未来测试中被复用。这种无监督机器学习形式使扫描器能够获得永久性的测试优势，确保状态、载荷和断言的基本原理能够与其保护的应用程序一样快速地进化。