HTTP 参数污染检查清单

要解决什么问题

当你在 Web 应用中测试参数处理逻辑时，往往会遇到一个棘手问题：同一个参数名被提交多次，不同技术栈的解析结果完全不同。ASP.NET/IIS 取第一个值，PHP/Apache 取最后一个值，Python/Flask 把所有值组装成数组——这种不一致正是 HTTP 参数污染（HPP）攻击的立足点。

更麻烦的是，现代应用通常经过多层处理：CDN、API 网关、WAF、Web 框架、后端服务。每一层都可能以不同方式处理重复参数。比如 API 网关可能只检查第一个 id 参数，而后端 Lambda 函数处理的是最后一个，这就产生了 IDOR 漏洞。

这个技能要解决的，就是在安全测试中系统性地发现这类跨层参数处理缺陷。

技能如何工作

核心能力：

• 内置完整的 HPP 测试方法论，从参数发现到利用验证全流程覆盖
• 覆盖多种污染场景：URL 参数、表单字段、JSON 重复键、GraphQL 别名与变量、WebSocket 升级请求与消息负载
• 针对不同框架的解析行为差异，提供针对性的测试策略（如数组表示法 param[]=a&param[]=b 与索引写法 param[0]=a 的混合测试）
• 收录真实 CVE 案例（如 CVE-2021-41773、CVE-2018-8033）和 Bug Bounty 典型目标场景
• 附带修复建议，从参数校验、框架配置到网关层去重

关键步骤：

1. 识别目标应用的所有参数入口（URL、表单、Cookie、Header）
2. 对每个参数提交重复值，观察应用行为
3. 判断各组件使用的是第一个值、最后一个值，还是拼接结果
4. 结合具体场景（访问控制绕过、WAF 绕过、CSRF Token 失效、OAuth 重定向操纵）验证可利用性
5. 记录已完成的检查项，提出下一步测试建议

适用边界与注意点

• 这是一份测试方法论，不是自动扫描工具。需要你结合目标上下文手动执行，并根据响应结果判断。
• 不同框架、中间件版本的行为可能不同。例如 Node.js/Express 默认取第一个参数，但设置 app.set('query parser', 'extended') 后行为会改变。测试前先确认目标的技术栈。
• API 网关（Kong、APIGEE、NGINX、Cloudflare）的参数归一化逻辑与后端框架可能不一致，这是 HPP 的高价值测试点，但需要分别验证每一层的行为。
• JSON 重复键在大多数解析器中采用"后者优先"策略，但部分网关会拒绝重复键而后端接受，这种优先级差异值得重点关注。
• 实际测试中建议配合 Burp Suite、OWASP ZAP 或 Param Miner 等工具，通过 Burp Repeater 的并行请求功能快速验证跨层优先级。