Cloudflare 利用 AI 测试框架探测并加固其 WAF

Cloudflare 把前沿 AI 模型放进一个受控测试框架，用来探测自己的 Web 应用防火墙（WAF）。这套做法的起点不是一份固定的测试用例清单，而是 WAF 已经拦截过的攻击载荷——模型以这些被拦下的载荷为素材，生成并细化新的变体。

这个选择决定了整场演练的性质。重复重放固定用例只能验证已知规则是否还在生效；而从已被拦截的载荷出发，等于把“规则为什么拦住它”当作可被绕开的假设去试探。模型调用会根据此前尝试返回的响应，提出对载荷编码、位置或投递方式的修改，使后续尝试具备自适应性。

这套框架的分工是刻意设计的。一个 Python 框架承担了 Cloudflare 不愿交给模型的部分：构造和重放 HTTP 请求、维护场景状态、执行限制并收集响应。模型并不直接控制请求执行。

在模型侧，一个模型调用负责提出下一次变异，另一个模型调用负责审查返回的响应，从而让后续尝试能够自适应。与此同时，模型无法访问 Cloudflare 的 WAF 规则、源代码或内部安全信号，因此从模型视角看，这场测试实际上是黑盒的。

把“提出假设”和“执行动作”分开，是这套设计里最值得注意的约束。模型可以不断猜测编码、位置和投递方式，但真正把请求发出去的是框架，边界由框架而非模型掌握。

一个 SSRF 测试可以说明这个反馈回路如何运转。测试者反复改变云元数据地址的表示与位置，尝试十进制、八进制等形式，最终一个使用十进制表示的请求被拦截。

在下一次尝试中，模型保留了相同的请求形态，但改用带尾点的地址表示；这一次客户端遇到的是重定向，而不是 WAF 拦截。Cloudflare 将该结果保留以供调查，而没有把它当作攻击已经成功的证据。

这个处理方式本身就是一个判断标准：客户端遇到重定向，与请求真正抵达目标并造成危害，是两件不同的事。来源没有说明该重定向结果后续调查的结论。

规模数据是这场演练最可核查的部分。实验覆盖 45 个场景，系统共生成 1,107 次尝试，经人工分诊后留下 49 项发现。

在 1,107 次记录的变异尝试中，有 607 次产生了分诊后的结果集；这个结果集里，558 个请求被 WAF 拦截，49 项发现被认为与后续修复工作相关。49 项发现中有 48 项涉及命令注入或服务器端请求伪造（SSRF）。

人工审查仍是最终验证步骤。审查者要检查请求是否真正到达目标、是否仍具恶意、是否明显未被拦截、是否属于 WAF 的职责范围，以及能否被安全复现。只有通过这些检查的案例，才会被重放并评估为规则、归一化或其他缓解措施的候选改动。

来源未说明 607 次分诊后结果集与 1,107 次总尝试之间其余尝试的处理结果，也未说明 49 项发现中除命令注入与 SSRF 之外剩余 1 项的具体类型。

这次演练最终促成了 Cloudflare Managed Ruleset 的三项改动：两项新检测规则 SSRF - Obfuscated Host 与 SSRF - Restricted Protocol，以及对现有 SSRF - Cloud 规则的改进。

三项改动全部落在 SSRF 方向，与 49 项发现中 48 项涉及命令注入或 SSRF 的分布相互印证。但来源未说明这三项改动上线后的实际拦截效果或误报情况，因此“改动已生效并改善了防护”目前只能视为待验证的预期，而非已确认的结果。

从已披露的信息看，这套做法的可迁移之处在于框架而非模型：约束执行、保留状态、验证发现，把概率性的探索转化为既有安全流程可以使用的证据。模型在其中提供的是变异方向的搜索能力，而不是判定权。

但若干关键维度来源并未交代。来源未说明所使用的前沿 AI 模型具体是哪些模型或版本，未说明该实验的时间跨度、运行成本或模型调用次数，也未说明该测试框架是否已常态化用于持续探测，还是仅为一次性演练。

因此，把这次演练理解为一次有明确产出、但边界与可持续性尚未公开的探索，比理解为“AI 已能自主攻破 WAF”更贴近已披露的事实。