Cloudflare 测试 WAF 抵御前沿人工智能自适应攻击
Cloudflare AI··作者 Kuber Nandwani
关键信息
模型无法访问源代码、WAF 规则、规则 ID、Attack Score 详情或执行拦截的安全层身份；请求发送、目标允许列表检查、重定向控制、日志记录和尝试次数限制均由代码控制，而不是由模型直接执行。通过 WAF 的请求只被视为需要人工复核的线索，并不代表漏洞已经成功利用；格式错误、良性、重复和超出范围的观察结果也被从结果中剔除。
资讯摘要
Cloudflare 调查了其 WAF 能否抵御前沿人工智能模型，这些模型会迭代搜索修改 Web 攻击载荷的方法。Cloudflare 认为，模型在利用漏洞方面尤其擅长的一点，是根据实时响应尝试不同编码、把载荷放入 HTTP 请求的不同位置，或转而测试另一种漏洞。Cloudflare 没有扫描源代码，而是采用动态应用安全测试方法，让模型只与正在运行的应用交互，并接收经过筛选的 HTTP 响应数据。测试器在每个场景开始时使用一个已经被 WAF 拦截的漏洞利用样本，然后允许模型在固定次数内进行变异，并通过一次提议调用和一次复核调用选择后续变体。
模型无法获得任何 WAF 内部信息，而 Python 代码负责 HTTP 重放、流程编排、状态跟踪、主机名允许列表、禁用重定向、日志记录和尝试次数限制。系统在获得授权的客户预发布环境中，针对六类攻击进行了 1,107 次尝试；经过人工审核并过滤无关观察结果后，绝大多数请求都被拦截。最初通过 WAF 检查的请求帮助 Cloudflare 创建了新的检测规则，但公司强调，绕过 WAF 仍需要目标应用本身存在可利用漏洞，及时更新和修补软件依然是最有力的防御手段之一。
资讯正文
“你的 WAF 准备好应对前沿 AI 模型了吗？”我们不断从客户那里听到这个问题，因此决定一探究竟。
在利用应用程序漏洞方面，LLM 真正擅长的是以远超任何人类黑客的速度反复调整和变异攻击载荷。LLM 可以根据实时响应不断迭代并改变技术，例如测试不同的编码方式、将载荷放在 HTTP 请求的不同位置发送，或转而测试下一个漏洞。
早在 LLM 出现之前，安全工程师就普遍采用两种方法测试应用程序：静态应用安全测试和动态应用安全测试。前者在不执行代码的情况下分析代码，以识别漏洞；后者则探测正在运行的应用程序，以发现运行时缺陷。目前已有大量使用前沿 AI 模型扫描代码的研究，其中也包括如何构建自己的测试框架的详细说明。
对于这篇博客文章所述的项目，我们采用了动态方法：让 LLM 模拟黑客的行为，以评估 WAF 是否发挥了应有的作用。LLM 无法查看源代码，也看不到 WAF 的规则，只能看到经过筛选的 HTTP 响应数据。
我们构建了一个 WAF 测试器：它从已知漏洞利用手法入手，通过改变载荷的编码或投递方式进行迭代，再次发送请求，并根据响应选择下一种变体。未被拦截的请求只会被视为供人工审查的线索，而不是已确认的漏洞利用。
我们在一个经过授权的客户预发布环境中，针对六类攻击运行了该测试器，共记录了 1,107 次尝试。在审查未被拦截的请求，并剔除格式错误、无害、重复以及超出范围的观察结果后，我们发现绝大多数攻击都被 Cloudflare WAF 拦截。那些成功通过的请求则帮助我们创建了新的检测机制，进一步强化安全防护，使所有 Cloudflare 客户受益。
接下来，我们将说明如何搭建这一系统、测试了哪些类型的攻击、哪些攻击向量更容易绕过 WAF，以及我们如何修复这些问题。更重要的是，我们将分享从这一过程中获得的经验，以及这项实践如何逐渐成为 WAF 开发生命周期中的基础组成部分。
最后，我们还将提供相关指导，帮助你在应用程序前端正确部署 WAF；而最重要的是，要及时修补软件。即使攻击载荷绕过了 WAF，也仍然需要存在可被利用的应用程序漏洞才能成功，因此，让技术栈保持最新状态仍是抵御攻击者最有力的措施之一。
自适应循环如何运作
为了使用前沿模型测试我们的 WAF，我们构建了一个能够针对多种场景反复迭代的系统。所谓场景，是指选择一种攻击类别，将输入放置在请求的特定部分，以一个已被 WAF 拦截的版本作为起点，并给予测试器固定次数的尝试机会，以探索其他变体。该循环会调用 LLM 模型两次：第一次是提案调用，第二次是审查调用。
第一次调用接收初始请求、上下文以及此前结果的简短历史记录，并提出下一个变体；随后由代码构建并发送请求。审查调用接收请求上下文、响应状态、选定的响应头以及响应正文。当变异不再产生有用的变化，或达到硬编码的尝试次数上限时，循环停止。
两次模型调用都无法访问 WAF 的内部信息。它们都不会接收规则表达式、规则 ID、WAF Attack Score 详情，也不会知道执行操作的安全层身份。我们使用 Python 实现了这一系统，而不是对现有的渗透测试工具进行封装。系统负责 HTTP 重放、场景编排、状态跟踪和结果收集。
在当前实现中，模型不会直接发送请求——每一步的执行都由代码控制。每次请求发送前，系统都会检查目标主机名是否在允许列表中、禁用重定向、记录尝试，并执行尝试次数限制。每次请求发送后，系统都会记录响应，并根据模型的审查结果选择下一个预定义步骤。响应文本可能会出现在后续提示中，因此测试器会将其视为不受信任的输入。两次模型调用都无法部署规则或更改执行策略。
系统会为每次尝试记录结构化证据。
针对一个 WAF 配置测试六类攻击
主要测试针对的是一个经过授权的客户暂存环境，该环境由 Cloudflare 的 WAF 保护。我们使用了已加入允许列表的测试 User-Agent，这样客户的自动化流量控制就不会在请求到达 WAF 之前将测试拦截。
我们运行了 45 个场景。对于每个场景，我们都寻找以不同方式传递同一种攻击的方法：使用不同的编码、请求的不同部分，或以另一种方式书写相同的目标地址。其中 44 个场景涵盖六类攻击：跨站脚本攻击（XSS）、SQL 注入（SQLi）、命令注入（CMDi）、服务器端请求伪造（SSRF）、路径遍历或本地文件包含（LFI），以及 Log4j。剩余的一个场景涉及日志注入，单独报告。
测试区域中的 WAF 配置如下：
WAF Attack Score 的拦截分数为 30 分或以下，全部拦截；Cloudflare Managed Ruleset 已启用；OWASP Core Ruleset 的 Paranoia Level 为 3。
对于标题所述的测量结果，我们记录了 WAF 是否拦截每个请求。结果反映的是整个已配置 WAF 边界的表现，而不是任何单独规则或检测机制的性能。
一次记录会话中的适应过程
下面是测试期间，LLM 如何调整一次服务器端请求伪造（SSRF）攻击的示例。
云元数据服务可能会向工作负载公开临时凭据。SSRF 漏洞可能允许应用代表攻击者获取这些数据。WAF 可以帮助在恶意请求到达应用之前将其拦截，但它只是保护措施中的一层。
在这一 SSRF 场景中，测试器以不同形式（例如整数、八进制，以及同一 IP 的末尾加点表示法）发送了相同的云元数据地址，并将其放在请求的不同部分。WAF 拦截了除其中一个之外的所有请求。在第 18 次尝试中，模型沿用了上一次被拦截请求的相同请求结构，并切换为末尾加点的形式。客户端遇到的是重定向，而不是 WAF 拦截。
下表展示了这次会话中的几个关键时刻。“假设”一栏概述了模型在每次操作前所说的尝试方向。这不是逐字记录，也不能证明该解释是正确的。
第 17 次和第 18 次尝试很有意思：请求结构相同，但主机表示形式不同。一个被拦截了，另一个没有。这给了我们一个明确的问题：末尾的点是否改变了 WAF 读取目标地址的方式？这为后续调查提供了线索，但不能证明模型访问了元数据。
这是 45 个场景中的一条选定轨迹。下一节将介绍我们如何统计并分流处理整个运行过程。
我们发现
测试器共生成了 1,107 次尝试；总体结果在 XSS、LFI、SQLi 和 Log4j 方面表现良好，覆盖率接近完整。虽然这次运行产生了有用的发现，但也带来了噪声。经过人工审查后，我们留下了 49 个值得进一步调查的发现，其中 48 个属于 CMDi 和 SSRF。
具体情况如下：
记录的变异尝试：1,107 次。含义：模型在 45 个活跃场景中的迭代次数；并非所有尝试都产生了可用结果。
分流后的结果集：607 个。含义：558 个被拦截的请求，加上 49 个记录在案的、与 WAF 相关的发现。
被拦截的请求：558 个。含义：WAF 在这些请求到达应用程序之前将其拦截。
与 WAF 相关的发现：49 个。含义：经人工审查后记录下来，用于修复分析。
其余尝试没有产生值得计入的结果：有些是因为模型未能生成可用的 HTTP 请求，有些在到达目标之前就失败了，还有一些生成的负载是无害的。
当一个请求没有被拦截时，我们会先围绕以下五个问题进行核查，然后才将其计为一个发现：
测试器是否确实发送了有效请求？如果模型失败，或者请求从未到达目标，那么这个结果无法说明 WAF 的任何情况。
请求是否明确没有被拦截？模棱两可的响应不足以计入结果。
请求是否仍然具有恶意性？为了绕过 WAF 而修改请求，也可能使请求变得无害。
这种行为是否确实属于 WAF？有些攻击只有通过 WAF 在请求处理时无法阻止的 DNS 或网络路径才能奏效。
工程师能否安全地重现这种情况？修复工作需要一个稳定的测试用例，以及明确的预期结果。
我们删除了未通过这些检查的结果，并合并了重复案例。剩余内容成为规则、规范化处理和缓解措施工作的输入。
发现转化为检测
并非每个发现都需要新增规则。有些发现指向现有 Managed Rules 覆盖范围中的缺口。另一些则指向 WAF 对请求进行规范化处理的方式，或者属于其他安全控制措施。我们重新执行了每个案例，并决定应在哪个环节进行改动。
我们将相关发现归入四组候选规则，逐一验证每项发现，并在任何规则能够保护客户流量之前，先使用实时流量对候选规则进行测试。
在新规则或更新后的规则能够保护客户流量之前，我们会检查其对合法流量的影响，并评估误报风险。在评估新的候选规则时，我们发现的问题包括：
问题
下一步
检测缺失或范围过窄
检查现有规则是否已覆盖该发现
对等输入的解读方式不同
审查引擎或规范化处理
误报风险过高
修改或拒绝该候选规则
这项工作促成了 Cloudflare Managed Ruleset 的三项变更：在 7 月 21 日发布的版本中新增“SSRF - Obfuscated Host”和“SSRF - Restricted Protocol”检测，并改进现有的“SSRF - Cloud”规则。“SSRF - Obfuscated Host”检测直接源于一些请求：这些请求使用非标准的数字形式对内部地址进行了编码。
我们学到了什么
模型只是测试的一部分。我们使用同一模型系列的两个版本运行了相同的场景。它们生成了不同的变体，但两者都出现了相同的底层问题。由于请求重放和证据捕获过程保持一致，我们可以比较两次运行的结果，而不把任何一个模型的输出视为事实标准。
在同一个场景中增加尝试次数，并不总能发现更多问题。有些场景在接近 25 次尝试上限时，开始重复之前的想法。与其延长单个序列，不如测试更多的起始请求、攻击类别和输入位置，这样能够获得更广泛的覆盖范围。
模型生成请求，而我们决定哪些请求值得关注。一个未被拦截的请求仍然需要经过重放和人工审核，之后才能成为一项发现、缓解措施或回归测试。如果没有这项审核，就不会产生任何发现。
客户现在可以做什么
WAF 只是可部署的检测层之一。部署所有可用的防护措施，可以提高整体安全防护栈的有效性。
首先，检查应用前方的 Managed Rules 和 WAF Attack Score 是否已正确设置。你还可以部署 API Security、Bots and Fraud detection 以及 Threat Intelligence，进一步强化安全态势。例如，正向安全控制增加了另一层防护：它们不只是寻找已知攻击模式，而是定义应用所预期的请求形态，并识别超出这一契约的输入。这会大幅缩小攻击面。
客户无需复现这项实验。为了最大限度地增加部署在应用前方的规则数量，我们建议先以日志模式运行 Managed Rules，在 Security Events 中检查匹配的请求，并确认合法流量不受影响，然后再将规则切换为 Block。或者，客户也可以联系客户团队以获取 Attack Signature Detection
在相关区域启用后，这项新功能简化了对匹配流量的审查，以及签名检测的部署方式。如果你已经在进行应用安全测试，请针对一个由与生产环境相同的 Cloudflare 控制措施保护的暂存主机运行这些测试。
后续步骤
通过将自适应的 AI 驱动测试与人工分流和验证相结合，我们发现了固定测试可能遗漏的检测盲点，并将这些发现转化为更强大的 WAF 防护措施，从而提高了拦截率。在未来的文章中，我们将分享采用白盒方法进行进一步测试的结果。在这种方法中，模型同时了解应用程序的漏洞以及保护该应用程序的 WAF 规则。
来源与参考
收录于 2026-09-30