HTTP参数污染实战：利用ASP.NET特性绕过WAF的XSS攻击

在一次针对某客户的渗透测试中，国外安全研究团队的扫描引擎发现了一个有趣的跨站脚本（XSS）漏洞。目标是一个运行在配置严格的高端Web应用程序防火墙（WAF）之后的ASP.NET应用。

虽然漏洞本身很简单——攻击者可以突破由单引号分隔的Javascript字符串，但所有常规的XSS攻击载荷都被WAF有效拦截了。这带来了一个经典的安全挑战：当防御机制有效运作时，如何证明漏洞的可利用性？

最终的突破源于对ASP.NET参数污染行为的利用。通过将恶意代码拆分到多个同名参数中，研究人员成功构建了WAF无法识别但浏览器能够正常执行的Javascript载荷。

构建Payload

理解参数污染

HTTP参数污染是一种利用不同技术在处理重复HTTP参数时行为差异的技术。当同一请求中出现多个同名参数时，各Web框架的处理方式各不相同：有些连接所有值，有些只取第一个或最后一个，有些则会创建数组。

ASP.NET 的特定行为对我们非常有利。当遇到多个同名参数时，它会使用 HttpUtility.ParseQueryString() 方法将这些值用逗号连接起来。微软官方文档也明确指出：“同一查询字符串参数的多次出现被列为单个条目，每个值之间用逗号分隔。”

当这种特性与Javascript注入场景结合时，便产生了绕过机会。考虑一个典型的场景，用户输入被直接嵌入到Javascript字符串中：

userInput = 'USER_CONTROLLED_DATA';

常规的攻击思路是尝试用引号跳出字符串并注入代码：'; alert(1); //。然而，WAF很容易检测到这种模式。

Javascript语法 允许使用逗号分隔的表达式，从而顺序执行多个语句。这一语言特性与ASP.NET的逗号连接行为相结合，创造了绕过条件。

当ASP.NET处理如下的查询字符串时：

/?q=1'&q=alert(1)&q='2

它会将这些值连接成：

1',alert(1),'2

当它被嵌入到上面的Javascript上下文中时，最终形成：

userInput = '1',alert(1),'2';

这行Javascript在语法上是有效的，并且会执行alert函数。Javascript中的逗号运算符从左到右求值每个表达式，并返回最后一个表达式的值。

为乐趣与JS注入而绕过WAF

基于以上的想法，研究人员决定测试主流WAF的防御能力。

WAF技术的类型

现代WAF主要采用两种检测方法：

• 基于签名的WAF：维护已知攻击模式数据库，进行精确匹配。优点是误报率低，缺点是无法防御新的攻击手法，需要持续更新规则。
• 基于机器学习的WAF：分析流量模式和用户行为以识别异常。优点是有潜力检测0-day攻击，缺点是在流量样本少的情况下，难以保证低误报率。

WAF为何难以防御参数污染

传统WAF在面对参数污染攻击时面临多重挑战：

• WAF通常孤立地分析单个参数，可能忽略多个参数组合后形成的恶意代码。
• 大多数WAF缺乏对不同Web框架参数解析逻辑的深度理解，不会模拟ASP.NET的逗号连接行为。
• 基于规则的WAF依赖已知攻击模式，而参数污染技术创建的载荷与传统XSS签名不匹配，但功能等效。
• 结合各种混淆技术后，通过静态分析很难检测出真实的恶意意图。

WAF配置测试

评估涵盖了17种不同的WAF配置，包括主要的云提供商和安全厂商。

测试方法 研究人员开发了三种载荷来评估每个WAF：

1. Payload1 - 简单注入：q=';alert(1),' 用于测试基础检测能力。
2. Payload2 - 带分号的参数污染：q=1'+1;let+asd=window&q=def='al'+'ert'+;asd1&q=2;' 引入参数污染和变量操作。
3. Payload3 - 带换行符的参数污染：q=1'%0aasd=window&q=def="al"+"ert"&q=asd1+' 使用换行符开启新的JS表达式。

测试结果

测试结果（✅ = 被拦截，❌ = 绕过/未检测到）如下：

WAF配置	Payload1	Payload2	Payload3
AWS WAF - AWS托管规则集	❌	❌	❌
Google Cloud Armor (ModSecurity规则)	✅	✅	✅
Azure WAF (默认规则集 2.1)	✅	✅	✅
FortiWeb - 内联标准防护	✅	❌	❌
Cloudflare WAF	✅	❌	❌
open-appsec (各敏感度配置)	✅	✅	✅
... (其他配置结果)	...	...	...

关键发现：

1. 仅 Google Cloud Armor、Azure WAF 和 open-appsec 成功拦截了全部三个手动构造的载荷。
2. 随着载荷复杂性增加，被绕过的WAF比例显著上升：简单载荷(Payload1)绕过率为17.6%，而复杂参数污染载荷(Payload3)绕过了70.6%的已测试配置。
3. 数据表明，传统基于签名的WAF难以应对参数污染技术。

#黑客机器人能做得更好吗？

在手动测试后，研究人员部署了全自动的“黑客机器人”去攻击那些成功拦截了所有手动载荷的WAF（Google Cloud Armor, Azure WAF 和 open-appsec）。

1. 攻破Azure WAF

黑客机器人发现了一个令人惊讶的简单绕过方法：

test\\';alert(1);//

这个载荷利用了Azure WAF与Javascript解析器在处理转义字符时的细微差异，绕过了之前坚不可摧的防御。

2. 挑战Google Cloud Armor

黑客机器人未能找到直接绕过严格配置的Google Cloud Armor的方法，但在探测过程中揭示了应用层的一些有趣行为（例如参数解析不区分大小写），并尝试利用这些特性进行突破。

3. 快速攻克open-appsec

最令人惊讶的结果来自对基于机器学习的open-appsec的测试。在“仅关键敏感度”配置下，黑客机器人在短短30秒内就找到了有效绕过载荷。

当研究人员生成足够流量使基于alert的载荷开始被屏蔽后，黑客机器人几乎瞬间就适应了，转而使用confirm函数作为替代方案。

对于其他敏感度配置，黑客机器人同样快速发现了更多载荷变体。

这些发现凸显了一个重要原则：自动化是对手动测试的有力补充。人类的创造力用于发现新的攻击技术，而自动化工具可以高效、系统地探索可能被忽略的变体。

最终思考

参数污染的威力

手动研究中最惊人的发现是参数污染技术对传统WAF的极高有效性。绕过率从17.6%飙升至70.6%，这清晰表明依赖模式匹配的WAF难以防御那些利用底层解析差异的攻击。这源于一个根本性挑战：WAF必须在未完全模拟应用程序解析行为的情况下做出安全决策。

机器学习的优势与局限

基于机器学习的WAF（如open-appsec）在测试中展现出更高的检测率，表明行为分析相比纯规则方法具有显著优势。然而，黑客机器人证明这些模型仍然存在缺陷，能够快速适应并找到新的绕过路径。

复杂性悖论

一个颇具讽刺意味的发现是：复杂的攻击技术（参数污染）与极其简单的绕过方法（如转义字符滥用）可以共存。这意味着企业可能部署了昂贵的WAF，却依然暴露在利用基础实现缺陷的攻击之下。这也再次提醒我们：绝不能将WAF用作修复不安全代码的“创可贴”。

自动化渗透测试的价值

本次测试也展示了自动化安全评估工具的力量。一方面，研究人员的引擎能够在完全不触发WAF警报的情况下检测此类XSS漏洞，体现了极高的隐蔽性。另一方面，通过黑客机器人的系统化攻击，对那些手动测试中看似坚固的WAF进行了更深入、更彻底的评估。

参考资料

[1] HTTP Parameter Pollution - PayloadsAllTheThings [2] HTTP Parameter Pollution - Intigriti Hackademy [3] HTTP Parameter Pollution - whitepaper