用前沿 AI 模型测试 WAF：自适应攻击变体暴露了哪些防护盲区

Cloudflare AI Bl8 小时前

背景：AI 让攻击载荷变异更快

“WAF 是否已经准备好应对前沿 AI 模型？”这是安全团队越来越常听到的问题。

在应用攻击场景中，大语言模型的突出能力并不只是生成单个攻击载荷，而是能够根据实时响应快速迭代：尝试不同编码方式、把 payload 放到 HTTP 请求的不同位置，或者切换到下一个漏洞类型继续探测。

传统应用安全测试通常包括两类方法：

静态应用安全测试（SAST）：不运行代码，直接分析源码中的潜在漏洞。
动态应用安全测试（DAST）：对运行中的应用发起探测，寻找运行时缺陷。

这次测试采用的是动态方式：让大模型像攻击者一样行动，用于评估 WAF 是否能有效拦截。模型看不到源码，也看不到 WAF 规则，只能看到部分 HTTP 响应数据。

测试系统如何工作

测试系统从已知攻击样本开始，然后不断改变编码方式或投递方式，重新发送请求，并根据响应选择下一种变体。

需要注意的是：未被拦截的请求并不等同于成功利用漏洞。它只是一个需要人工复核的线索。

整个自适应循环中，大模型被调用两次：

提案调用：接收初始请求、上下文、此前结果的简短历史，提出下一次请求变体。
复核调用：接收请求上下文、响应状态码、部分响应头和响应体，用于判断下一步动作。

循环会在两种情况下停止：

变异不再产生有用变化；
达到预设尝试次数上限。

两个模型调用都无法访问 WAF 内部信息，包括规则表达式、规则 ID、攻击评分细节，或具体由哪一层安全机制做出处置。

实现上，测试系统使用 Python 编写，而不是简单封装现成渗透测试工具。它负责：

HTTP 请求重放；
场景编排；
状态跟踪；
结果采集。

模型本身不会直接发送请求。每次请求前，代码会检查目标主机是否在允许列表中、禁用重定向、记录尝试，并强制执行次数限制。请求后，系统记录响应，并使用模型复核结果选择下一步。由于响应文本可能进入后续提示词，测试系统将其视为不可信输入处理。模型无法部署规则，也无法修改防护策略。

测试范围：六类攻击，45 个场景

主测试运行在一个授权的客户预发环境中，该环境由 Cloudflare WAF 保护。测试使用了允许列表中的 User-Agent，以避免自动化流量控制在请求到达 WAF 前就将其拦截。

共运行了 45 个场景。每个场景都会尝试用不同方式投递同一种攻击，例如：

使用不同编码；
放入 HTTP 请求的不同位置；
用另一种方式表示相同目标。

其中 44 个场景覆盖六类攻击：

跨站脚本攻击（XSS）；
SQL 注入（SQLi）；
命令注入（CMDi）；
服务端请求伪造（SSRF）；
路径遍历或本地文件包含（LFI）；
Log4j 相关攻击。

另有一个场景覆盖日志注入，单独处理。

测试区域中的 WAF 配置包括：

WAF Attack Score 小于或等于 30 时阻断；
启用 Cloudflare Managed Ruleset；
启用 OWASP Core Ruleset，偏执级别为 3。

测试统计的是 WAF 是否拦截请求，结果反映的是该 WAF 边界整体表现，而不是某条具体规则或检测机制的效果。

一个 SSRF 场景中的自适应过程

在一个 SSRF 测试中，测试器围绕云元数据服务地址不断变换表示方式。

云元数据服务可能向工作负载暴露临时凭证。如果应用存在 SSRF 漏洞，攻击者可能诱导应用代表自己访问这些数据。WAF 可以在请求到达应用前提供一层拦截，但它并不是唯一防线。

在该场景中，测试器将同一个云元数据地址表示为不同形式，例如：

整数形式；
八进制形式；
带尾随点的主机形式。

同时，它还会把目标放到请求的不同位置。

多数变体被拦截，但有一个变体没有被 WAF 阻断。在第 18 次尝试中，模型保持了前一次被拦截请求的结构，只把主机改成带尾随点的形式。客户端遇到的是重定向，而不是 WAF 阻断。

这并不能证明元数据被成功访问，但它提出了一个明确问题：尾随点是否改变了 WAF 对目标地址的解析方式？ 这类差异足以成为后续工程排查线索。

测试结果：多数被拦截，CMDi 与 SSRF 更值得关注

测试器共生成 1,107 次变异尝试。整体结果较强，XSS、LFI、SQLi 和 Log4j 的覆盖接近完整。

不过，运行过程中也产生了噪声。经过人工复核后，留下 49 个值得调查的发现，其中 48 个属于 CMDi 和 SSRF。

指标	数值	含义
记录的变异尝试	1,107	45 个活跃场景中的模型迭代，并非全部都产生可用结果
复核后的结果集	607	558 个被拦截请求，加上 49 个与 WAF 相关的发现
被拦截请求	558	WAF 在请求到达应用前将其阻断
WAF 相关发现	49	人工复核后记录，用于修复分析

其余尝试未被计入有效结果，原因包括：

模型未生成可用 HTTP 请求；
请求在到达目标前失败；
生成的 payload 实际上是良性的。

如何判断一个“未拦截请求”是否值得计入

并非所有未被阻断的请求都算作发现。团队会先回答五个问题：

问题	重要性
测试器是否真的发送了有效请求？	如果模型失败或请求没有到达目标，结果无法说明 WAF 表现
请求是否明确未被阻断？	模糊响应不足以计入
请求是否仍然具有恶意性？	变形后绕过 WAF 的请求，也可能已经变得无害
行为是否属于 WAF 应该处理的范围？	有些攻击路径依赖 DNS 或网络层，WAF 在请求时无法阻止
工程师能否安全复现？	修复需要稳定测试用例和明确预期结果

未通过这些检查的项目会被移除，重复案例会被合并。剩余结果才会进入规则、规范化处理和缓解措施的改进流程。

从发现到检测规则

并不是每个发现都需要新增规则。有些问题说明现有托管规则覆盖不足；有些则指向请求规范化逻辑；还有一些更适合由其他安全控制处理。

处理流程包括：

重放每个案例；
判断改动应发生在规则、引擎、规范化处理还是其他控制中；
将相关发现分组为候选规则集；
验证每个发现；
在保护客户流量前，先用真实流量评估误报风险。

候选规则上线前需要重点检查：

问题	后续动作
检测缺失或覆盖过窄	评估现有规则是否应覆盖该发现
等价输入被不同方式解释	审查引擎或规范化逻辑
误报风险过高	修改或拒绝候选规则

这类测试已经推动了 Cloudflare Managed Ruleset 的改进，并被纳入 WAF 开发生命周期中的基础能力之一。

关键经验

这次测试说明，自适应 AI 测试并不只是“让模型攻击系统”。更重要的是构建一个受控循环：

限制目标范围；
限制尝试次数；
不让模型直接控制请求发送；
不向模型暴露规则内部细节；
对结果进行人工复核；
将可复现发现转化为规则、规范化或缓解改进。

同时，WAF 仍然只是纵深防御的一层。即使某个 payload 绕过了 WAF，它仍然需要遇到可利用的应用漏洞才可能成功。因此，保持软件栈更新、修补应用漏洞，仍然是抵御攻击的重要基础。