Cloudflare 使用能够在每次尝试后修改攻击请求的先进人工智能模型，对其 Web 应用程序防火墙（WAF）进行了测试，而不是仅依赖一组固定测试。公司在客户专用的 staging 环境中开展了这项实验，并事先获得批准；共记录了 45 个场景中的 1,107 次尝试。
核心思路是模拟攻击者行为的一部分：攻击者可以尝试不同的编码方式，将有效载荷转移到 HTTP 请求中的其他位置，或改变目标的表示方式，然后利用响应选择下一次尝试。模型没有获得应用程序代码、WAF 内部规则或规则编号，而只能处理请求上下文和指定的 HTTP 响应数据。
自适应测试如何运作？
每个场景都从一个已知会被 WAF 拦截的请求开始，然后由模型提出新的修改方案。请求发送后，另一个模型或模型审查调用会检查响应，随后系统在最大尝试次数限制内确定下一步。代码负责执行请求并记录证据；此外，每次尝试前都会通过允许列表验证域名，停止重定向，并禁止系统更改或部署防护规则。
其中 44 个场景涵盖六类攻击：跨站脚本攻击（XSS）、SQL 注入、命令注入、服务器端请求伪造（SSRF）、路径遍历或本地文件包含（LFI），以及 Log4j 攻击。第 45 个场景则单独涉及日志注入。
从 1,107 次尝试到 49 项可调查结果
总体而言，WAF 的表现很强，对 XSS、LFI、SQLi 和 Log4j 类别几乎实现了完整覆盖。经过人工审查后，共有 49 项结果值得调查，其中 48 项属于命令注入和 SSRF 两类。被拦截的请求数量为 558；其他尝试则因无效、良性、重复或未到达目标而被排除。
Cloudflare 并未将未被拦截的请求视为已确认的漏洞。该请求必须有效并到达目标，仍然明显具有恶意性，行为必须归因于 WAF，并且工程师能够安全地复现。这个区分很重要，因为绕过 WAF 本身并不能证明应用程序成功遭到利用或敏感数据已被访问。
SSRF 检测漏洞的示例
在其中一个场景中，系统改变了云元数据服务地址的书写方式，使用了不同的数字表示形式，并将该地址放入请求的多个部分。大多数尝试都被拦截，但其中一次使用尾随点表示形式的尝试导致重定向，而不是被 WAF 拦截。Cloudflare 将其视为值得调查的信号，而不是访问凭据或成功利用的证据。
实际发生了哪些变化？
Cloudflare 对结果进行了审查，以确定是否需要新增规则、改进请求规范化，或由其他安全层介入。这些结果促成了 Managed Ruleset 中的三项变化：在 7 月 21 日发布的版本中新增 SSRF - Obfuscated Host 和 SSRF - Restricted Protocol 检测，并改进 SSRF - Cloud 检测。混淆主机检测直接源自使用内部地址异常数字格式的请求。
这项实验表明，在这里人工智能是扩大测试范围的工具，而不是工程判断的替代品。同一系列中的两个模型产生了不同的变体，但两者都出现了相同的基本问题。此外，在单个场景中增加尝试次数并不能保证发现更多结果；有些序列开始重复相同思路，而增加起始点、攻击类别和输入位置则提供了更广泛的覆盖。
WAF 的局限性依然存在：能够绕过防火墙的有效载荷只有在应用程序本身存在可利用性时才会成功，因此更新软件和修复漏洞仍然必不可少。Cloudflare 还建议先以记录模式启用规则，审查匹配请求和安全事件，然后在确认合法流量不受影响后再切换到拦截模式。公司计划稍后展示一种 white-box 测试，在这种测试中，模型同时了解应用程序漏洞和 WAF 规则。