我们用前沿AI模型测试了自己的WAF，以下是我们的发现
内容提要
Cloudflare利用前沿AI模型模拟黑客，对自家WAF进行测试，在客户测试环境发起1107次攻击，涵盖XSS、SQL注入、命令注入、SSRF、路径遍历和Log4j六类。绝大多数攻击被拦截，仅49个发现值得调查，主要涉及命令注入和SSRF。这些发现促使Managed Ruleset新增SSRF混淆主机等检测规则。结论：WAF只是防护的一层，仍需及时修补应用漏洞。
延伸解读
AI测试WAF的方法与局限
Cloudflare使用前沿AI模型模拟黑客，在客户测试环境中发起1107次攻击，涵盖XSS、SQL注入等六类。AI能快速变异攻击载荷，但测试中模型无WAF内部信息，仅凭HTTP响应迭代。最终仅49个发现值得调查，且多数为命令注入和SSRF。这表明AI测试能发现潜在绕过，但需人工复核，且结果受模型能力和环境限制。
从发现到规则：WAF的持续加固
测试中未拦截的请求经人工分析后，部分转化为Managed Ruleset的新检测规则，如针对SSRF混淆主机的检测。Cloudflare强调，新规则需评估误报风险，并在实时流量中验证。这体现了WAF开发闭环：AI测试提供线索，人工确认后更新规则，从而提升整体防护，但规则更新可能滞后于新型攻击。
WAF并非万能：纵深防御是关键
文章指出，WAF只是防护的一层，绕过WAF的攻击仍需利用应用漏洞才能成功。因此，及时修补软件漏洞至关重要。Cloudflare建议客户正确部署Managed Rules和WAF Attack Score，并考虑API安全、机器人检测等附加控制。采用正向安全模型（定义预期请求形状）可进一步减少攻击面。
对安全团队的实践启示
企业可借鉴Cloudflare的方法：在 staging 环境用AI测试WAF，但需人工复核未拦截请求，避免误报。部署新规则时，先在日志模式观察，确认不影响合法流量后再启用阻断。此外，定期进行应用安全测试，并确保测试环境与生产环境防护一致，以发现配置差距。
Q&A
Cloudflare 如何用 AI 模型测试自己的 WAF？
Cloudflare 构建了一个 WAF 测试器，让前沿 AI 模型扮演黑客，从已知漏洞利用开始，通过改变编码或传递方式迭代变异攻击载荷，并根据 HTTP 响应选择下一步变异。模型无法查看源代码或 WAF 规则，只能看到部分响应数据。测试在授权的客户暂存环境中进行，共发起 1107 次攻击尝试。
这次 WAF 测试覆盖了哪些攻击类型？
测试覆盖了六类攻击：跨站脚本（XSS）、SQL 注入（SQLi）、命令注入（CMDi）、服务器端请求伪造（SSRF）、路径遍历/本地文件包含（LFI）以及 Log4j。共运行了 45 个场景，其中 44 个覆盖这六类攻击，另一个场景覆盖日志注入。
测试结果如何？有多少攻击被拦截？
在 1107 次尝试中，558 次被 WAF 拦截。经过人工审查后，有 49 个发现值得进一步调查，其中 48 个属于命令注入和 SSRF。XSS、LFI、SQLi 和 Log4j 几乎被完全覆盖。
哪些攻击向量更容易绕过 WAF？
命令注入（CMDi）和服务器端请求伪造（SSRF）是更容易绕过 WAF 的攻击向量。在 49 个值得调查的发现中，有 48 个属于这两类。
这些发现如何转化为 WAF 规则改进？
Cloudflare 将相关发现分组为四组候选规则，验证每个发现并在实时流量上测试候选规则，评估误报风险。这促成了 Managed Ruleset 的三项更改：在 7 月 21 日发布中新增 SSRF - Obfuscated Host 和 SSRF - Restricted Protocol 检测，并改进现有的 SSRF - Cloud 规则。
从这次 AI 测试中学到了什么？
模型只是测试的一部分，需要人工审查决定哪些请求重要。同一模型家族的不同版本产生不同变异，但底层问题相同。在一个场景中增加尝试次数并不总能发现更多，扩大起始请求、攻击类别和输入位置的覆盖更有效。未拦截的请求需要重放和人工审查才能成为发现、缓解措施或回归测试。
客户现在可以采取哪些措施来加强 WAF 防护？
客户应确保 Managed Rules 和 WAF Attack Score 正确部署在应用前。可以部署 API Security、Bots 和 Fraud 检测、Threat Intelligence 等工具。建议先以日志模式运行 Managed Rules，在 Security Events 中审查匹配请求，确认合法流量不受影响后再切换到阻止模式。也可以联系客户团队开启 Attack Signature Detection。如果已有应用安全测试，应在与生产环境相同 Cloudflare 控制的暂存主机名上运行测试。
