绕过Cloudflare WAF的反射型XSS漏洞挖掘实战

1. 项目概述：当XSS遇上Cloudflare WAF

在Web安全领域，跨站脚本攻击（XSS）算得上是“元老级”的漏洞了，但时至今日，它依然是漏洞赏金计划（Bug Bounty）和渗透测试中的常客。原因很简单，只要应用存在动态内容渲染且对用户输入处理不当，XSS就有机可乘。然而，随着Cloudflare这类云安全服务商的普及，直接、赤裸的XSS Payload往往在到达服务器之前就被其Web应用防火墙（WAF）无情地拦截了。这给漏洞挖掘者带来了新的挑战：你的对手不再仅仅是开发者的代码逻辑，还有一个时刻在云端分析流量特征的“智能守卫”。

我最近在一次针对某个远程协作平台（为保护项目隐私，我们姑且称之为“RDP项目”）的授权测试中，就遇到了这个经典的攻防场景。目标主站防护严密，但在对其一个用于文档预览的子域名进行测试时，我嗅到了一丝机会。最终，我不仅发现了一个反射型XSS漏洞，更关键的是，成功绕过了Cloudflare WAF的检测规则。这个过程，与其说是一次简单的漏洞发现，不如说是一场与WAF规则引擎的“猫鼠游戏”。今天，我就把这次挖掘之旅的完整思路、技术细节和绕过技巧拆解开来，希望能给同样在WAF“铜墙铁壁”下寻找突破口的同行们一些启发。

2. 核心思路：从信息收集到WAF特性分析

2.1 目标锁定与攻击面测绘

任何有效的漏洞挖掘都始于精准的信息收集。对于RDP项目，我的第一步是进行全面的子域名枚举。使用像subfinder、amass这样的工具，配合多个公共DNS数据集和证书透明度日志，我很快拉出了一张目标资产清单。在快速浏览和初步访问后，一个名为preview.rdp-project.com的子域名引起了我的注意。它的功能很明确：接收一个文档ID或URL参数，然后渲染一个预览页面。这类“参数化内容渲染”的功能点，天生就是反射型XSS的温床。

注意：在进行任何测试前，确保你拥有目标的明确授权。未经授权的测试是违法的。本文所有技术讨论均在合法授权的安全评估范围内进行。

初步的手工测试很快印证了我的猜想。我在URL参数中尝试插入经典的<script>alert(1)</script>，页面原样输出了这段字符串，但并没有弹窗。查看页面源代码，发现我的输入被直接放在了HTML正文的某个<div>里。这是一个典型的反射点，但为什么没执行？检查响应头，果然看到了X-XSS-Protection: 0（现代浏览器已弃用此头，但这是一个线索），更重要的是，没有明显的输出编码痕迹。问题可能出在WAF上——我的Payload在到达应用逻辑前就被过滤了。

2.2 Cloudflare WAF行为初探

为了验证是Cloudflare在起作用，我设计了几次探测请求：

1. 基础探测：发送<script>标签。结果：请求被正常响应，Payload被原样显示，无弹窗。这说明应用本身没有过滤，但浏览器未执行。
2. WAF触发探测：发送更明显的恶意Payload，如<script>prompt(1)</script>或包含javascript:协议。结果：有时会收到Cloudflare的拦截页面（HTTP 403），有时则不会。这种不一致性很有趣，说明WAF规则并非铁板一块，它有触发阈值和上下文判断。
3. 大小写与混淆测试：尝试<ScRiPt>、<script >（多余空格）。发现大小写变异通常能绕过基础检测，但复杂的标签事件（如onerror=）很容易触发拦截。

通过这一系列探测，我初步总结了该Cloudflare WAF策略的几个特点：

• 基于正则和语义：它不仅仅匹配<script>字符串，还会解析HTML标签结构，识别常见的事件处理属性。
• 有状态检测：单个可疑参数可能放行，但请求中多个参数同时存在恶意特征时，触发拦截的概率大增。
• 对某些上下文不敏感：当Payload出现在特定的HTML标签属性内，或者被某些字符分割时，WAF的检测可能会失效。

基于这些观察，我的绕过策略从“硬碰硬”改为“迂回渗透”，核心思路是：寻找WAF规则集与浏览器HTML解析器之间的差异。

3. 漏洞挖掘与绕过实战：一场解析差异的博弈

3.1 寻找脆弱的反射上下文

反射型XSS的成功利用，高度依赖于用户输入被嵌入到HTML文档的哪个位置（即“上下文”）。常见的上下文有：

• HTML正文：<div>用户输入</div>
• HTML标签属性值（未引号或引号闭合）：<input value=用户输入>或<input value="用户输入">
• JavaScript字符串内：<script>var a = '用户输入';</script>
• URL上下文：<a href="用户输入">链接</a>

通过仔细分析preview子域名的页面，我确认用户控制的参数被直接插入到了一个<div>标签的内部，即HTML正文上下文。这看起来是最容易利用的，因为我可以直接注入HTML标签。但Cloudflare WAF正是针对这种直接注入做了强力防护。

我的突破口来自于对响应内容的进一步审视。我注意到，页面为了展示预览信息，会动态生成一些包含数据的<span>标签。那么，我的输入有没有可能被嵌入到某个标签的属性里呢？我尝试了如下Payload：" onmouseover="alert(1)。如果输入点在一个属性值内，并且属性没有正确用引号闭合，这个Payload就能逃出属性范围，创建一个新的onmouseover事件处理器。

发送请求后，WAF没有拦截。查看页面源码，发现我的输入被放在了类似<div>