我们用前沿 AI 模型测试了自己的 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 攻击评分详情或所采取行动的安全层身份。我们使用 Python 实现该系统，而不是包装现有的渗透测试工具。它处理 HTTP 重放、场景编排、状态跟踪和结果收集。
在当前实现中，模型不直接发送请求——代码控制每一步发生的情况。在每次请求之前，它会根据允许列表检查目标主机名，禁用重定向，记录尝试，并强制执行尝试限制。每次请求后，它记录响应并使用模型的审查来选择下一个预定义步骤。响应文本可能会出现在后续提示中，因此测试人员将其视为不受信任的输入。两次模型调用均无法部署规则或更改执行。
系统为每次尝试记录结构化证据。
针对一个 WAF 配置的六种攻击类别
主运行针对受 Cloudflare WAF 保护的授权客户暂存环境。我们使用了允许列表中的测试 User-Agent，以便客户的自动流量控制不会在请求到达 WAF 之前停止测试。
我们运行了 45 个场景。对于每个场景，我们寻找以不同方式传递相同攻击的方法：不同的编码、请求的不同部分，或以另一种方式编写的相同目标。其中，44 个覆盖了六种攻击类别：跨站脚本 (XSS)、,
SQL 注入 (SQLi),
命令注入 (CMDi), 路径遍历或本地文件包含 (LFI) 以及 Log4j。剩余场景覆盖日志注入，单独报告。
__服务器端请求伪造 (SSRF)__测试区域中的 WAF 配置如下：WAF 攻击评分阻止分数为 30 或以下，所有
Cloudflare 托管规则集与偏执级别 3。
__OWASP 核心规则集__对于主要测量，我们记录了 WAF 是否阻止了每个请求。结果描述了配置的 WAF 边界整体，而非任何单个规则或检测机制的性能。
在一个记录会话中适应性的表现
以下是一个示例，说明 LLM 在测试期间如何适应服务器端请求伪造 (SSRF) 攻击。
云元数据服务可能会向工作负载暴露临时凭证。SSRF 漏洞可以让应用程序代表攻击者获取这些数据。WAF 可以帮助在恶意请求到达应用程序之前将其阻止，但这只是保护的一层。
在这个 SSRF 场景中，测试人员以不同形式发送了相同的云元数据地址（例如同一 IP 的整数、八进制和尾点表示），并将其放置在请求的不同部分。WAF 阻止了所有请求，除了一个。在第 18 次尝试中，模型保持了与之前被阻止的尝试相同的请求结构，并切换为尾点形式。客户端遇到了重定向，而不是 WAF 阻止。
下表显示了会话中的部分时刻。假设列总结了模型在每次操作前声称尝试的内容。它不是逐字记录，也不是解释正确的证明。
| 阶段 | 选定时刻 |
|---|---|
| 基线 |
观察：WAF 对直接元数据地址 169.254.169.254 返回了 403 阻止页面假设：检测器可能识别字面点分地址或元数据路径。下一步：将同一地址表示为十进制整数 2852039166。
尝试 1 |
观察：十进制表示被阻止。假设：元数据路径或查询放置可能仍会触发检测。下一步：使用八进制表示 0251.0376.0251.0376，并将输入从查询字符串移到表单正文。
尝试 2 |
观察：表单正文中的八进制表示被阻止。假设：无论主机编码如何，元数据路径可能仍会触发检测。下一步：尝试不带该路径的基于主机名的表示。
尝试 3–16 |
本摘录中省略。测试人员继续探索主机、路径和请求形状的组合。
尝试 17 |
观察：十进制整数主机，现在与后来的请求形状一起使用，被阻止。假设：尾点可能会改变检测器匹配的内容，而不改变预期目的地。下一步：保持方法、输入放置、内容类型和路径形式相同；切换到尾点主机形式：169.254.169.254。
尝试 18 |
观察：客户端遇到了重定向，而不是 Cloudflare 阻止页面。该运行保留了边缘通过的观察，因为预期的缓解措施缺失。限制：没有成功的源站响应、响应正文，也没有证据表明应用程序获取了元数据。下一步：保留请求以供分类和源站侧验证。
尝试 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 的范畴？ | 某些攻击仅通过 DNS 或网络路径生效，WAF 无法在请求时拦截。 |
工程师能否安全地复现它？ | 修复需要一个具有明确预期结果的稳定测试用例。 |
我们移除了所有未通过上述检查的内容，并合并了重复用例。剩下的内容成为规则、规范化和缓解工作的输入。
发现转化为检测
并非每项发现都需要新规则。有些指向现有 托管规则 覆盖范围的缺口。其他则指向 WAF 如何规范化请求，或属于另一项安全控制。我们重放了每个用例，并决定更改应在何处进行。
我们将相关发现归为四组候选规则，验证了每项发现，并在任何规则能够保护客户流量之前，针对实时流量测试了候选规则。
在新规则或更新后的规则能够保护客户流量之前，我们会检查其对合法流量的影响并评估误报风险。在评估新候选规则时，我们发现的一些问题包括：
---|---|
检测缺失或范围过窄 | 审查现有规则是否覆盖该发现 |
等效输入被以不同方式解释 | 引擎或规范化审查 |
误报风险过高 | 修订或拒绝该候选规则 |
这项工作促成了 Cloudflare 托管规则集中的三项变更：针对 SSRF - 混淆主机 的新检测，以及
SSRF - 受限协议规则的改进。SSRF - 混淆主机检测直接来自那些以非标准数字形式编码内部地址的请求。
SSRF - 云## 我们学到了什么
模型只是测试的一部分。我们用同一模型系列的两个版本运行了相同的场景。它们产生了不同的变体——而相同的底层问题在两者中都出现了。由于请求重放和证据捕获保持一致，我们能够比较这些运行结果，而无需将任一模型的输出视为基准真相。
在一个场景中增加尝试次数并不总能发现更多问题。有些场景在 25 次尝试限制接近尾声时开始重复之前的想法。我们通过测试更多起始请求、攻击类别和输入位置来获得更广泛的覆盖，而不是延长单一序列。
模型生成了请求。我们决定哪些请求是重要的。一个未被拦截的请求仍然需要重放和人工审查，才能成为一项发现、一项缓解措施或一个回归测试。没有这种审查，就不会有任何发现。
客户现在可以做什么
WAF 只是你可以部署的检测层之一。当你部署所有可用的防护措施时，就能提升整体防护体系的有效性。
首先，检查 Managed Rules、WAF Attack Score 是否已在你应用程序前方正确设置。你还可以部署其他工具，包括 API Security、Bots and Fraud detection 以及 Threat Intelligence，以进一步强化你的防护态势。例如，添加一个不同的层：它们不再只查找已知的攻击模式，而是定义应用程序所期望的请求形态，并识别超出该契约范围的输入。这能大幅缩小你的攻击面。
正向安全控制
客户无需复现此实验。为了最大化部署在你应用程序前方的规则数量，我们建议先以日志模式运行 Managed Rules，在Security Events中审查匹配的请求，并在确认合法流量不受影响后，再将规则移至 Block。或者，客户可以联系其客户团队，以便
在其区域上开启。这项新功能简化了审查匹配流量以及部署签名检测的方式。如果你已经在进行应用程序安全测试，请针对一个由与生产环境相同的 Cloudflare 控制措施保护的预发布主机名运行这些测试。
Attack Signature Detection## 后续步骤
通过将自适应 AI 驱动的测试与人工分诊和验证相结合，我们发现了固定测试可能会遗漏的检测缺口，并将这些发现转化为更强的 WAF 防护，从而提高了我们的拦截率。在后续文章中，我们将分享使用白盒方法进行进一步测试的结果，在这种方法中，模型既了解应用程序的漏洞，也了解保护它的 WAF 规则。