Cloudflare 在受控测试中使用 AI 编织体探测并加固 WAF
2026年10月10日 · 阅读 1 分钟
Cloudflare 将前沿 AI 模型置于受控测试编织体中，探测其实际 Web 应用防火墙。该系统使用已被阻止的攻击作为起点，让模型生成并完善新的变体。
在 45 个场景中，系统生成了 1107 次尝试，经人工筛选后留下 49 条发现。最终，这些结果促成了 Cloudflare 受管规则集的三项修改。
实验从 WAF 已经阻止的攻击载荷开始。与其反复重放固定的测试用例，模型则基于早前尝试的响应，建议调整编码、位置或投递方式。模型无法访问 Cloudflare 的 WAF 规则、源代码或内部安全信号，从其角度看，此测试实质上是黑盒。
一个 Python 编织体处理 Cloudflare 不想委托给模型的部分。它构建并重放 HTTP 请求，维持场景状态，执行限制，并收集响应。一个模型调用建议下一次变体，另一个审查产生的响应，从而让后续尝试在不将请求执行直接交给模型的情况下适应。
一次 SSRF 测试说明了这一反馈循环是如何运作的。测试人员反复更改云元数据地址的表示和位置，尝试十进制、八进制及其他形式。最终，使用十进制表示的请求被阻止。在下一次尝试中，模型保持请求形状不变，但将云元数据地址的表示改为带有尾随点的形式；这次客户端遇到的不是 WAF 阻止，而是重定向。Cloudflare 将该结果保留以供调查，而非将其视为攻击成功的证据。
这种区分在规模上也证明了重要性。在 1107 次记录的变体尝试中，607 次产生了筛选后的结果集：558 次请求被 WAF 阻止，49 条被认为与进一步的补救工作相关。这 49 条发现中有 48 条涉及命令注入或服务器端请求伪造（SSRF）。
人工审查仍然是最后一步验证。审查员检查请求是否实际到达了目标、是否仍然具有恶意、是否明显未被阻止、是否在 WAF 的责任范围内，以及是否可以安全地重放。存活的案例随后被重放并作为规则、标准化或其他缓解措施的候选案例进行评估。
这项工作促成了 Cloudflare 受管规则集的三项修改：两项新检测（SSRF - 隐藏主机和 SSRF - 受限协议），以及对现有 SSRF - Cloud 规则的改进。
相同的编织体模式出现在其他安全工程领域。虽然 Cloudflare 的漏洞发现编织体将漏洞发现与独立验证分离，但 Google Mandiant 的代理漏洞发现编织体通过源代码分析、假设生成和验证，在发现结果到达人工审查员之前链接专用代理。
"代理漏洞发现编织体链" - Source Google
其他系统使用不同的术语，但遵循相似的发现与验证模式。OpenAI 的 Codex Security 为仓库构建威胁模型，搜索漏洞，并在隔离环境中尝试复现候选项，然后向人工审查员提出修复建议。Google 的 PageBreak 同样专注于验证 AI 生成的漏洞假设是否实际上可被利用，部分目的是为了防止安全团队被合理但未经验证的发现所淹没。
在这些系统中，共同的线索是围绕模型的编织体：限制执行、保持状态、验证发现，并将概率性探索转化为现有安全工作流可使用的证据。