HTTP 参数污染

先说清楚要解决的问题

当一个参数在请求里出现两次，比如 ?id=1&id=2，服务端和客户端（以及中间的代理、WAF）给出的答案常常不一致。浏览器可能只保留第一个，框架可能取最后一个，ASP.NET 甚至会把两个值拼成 1,2。这种解析差异就是 HTTP 参数污染（HPP）的立足点：参数值到底是从哪里被读出来的，往往决定了漏洞能不能打穿。

具体表现通常是这几类：

• 取值来源不确定：同一参数名，入口点和后端组件各取各的，攻击者可以喂给其中一个组件一个自己可控的值。
• 过滤被绕过：WAF 只检查第一个出现的参数值，业务代码却使用了第二个。
• 逻辑判断被改写：像 isAdmin=false&isAdmin=true 这类校验，前端校验被绕过后逻辑分支完全改变。

这个技能如何工作

它把 HPP 测试拆成一份按顺序执行的 checklist，核心覆盖：

• 重复参数注入：在同一参数名上叠加多个值，观察取值优先级和拼接行为。
• 解析差异探测：比较后端框架、前端脚本、网关代理对重复参数的处理方式，定位取值环节。
• WAF 绕过：通过 HPP 构造前后端视图不一致的请求，验证过滤规则是否只在单一视图生效。
• 服务端 / 客户端 HPP 分类：区分污染值被后端组件读取（server-side）与被前端脚本读取（client-side）两种场景。
• 实战利用模式：结合 SQL 注入、命令注入、SSRF 等，把被污染的参数值作为注入载体。

使用方式是把它当作操作清单：载入后按顺序执行步骤，逐项记录哪些 checklist 项已完成，再根据发现建议下一步动作。在每一项技术落地前，需要先判断当前目标和上下文是否适用，而不是无差别套用。

适用边界与注意点

• 这是主动测试技能，只应在有授权的目标上使用，测试前明确范围和回退条件。
• HPP 本身只是信号，真正的危害取决于污染值最终流向何处。没有下游组件读取，污染只是无害的重复参数。
• 不同框架和语言的取值规则差异很大，q=a&q=b 在 PHP 里取最后一个，在 ASP.NET 里取逗号拼接结果，结论不能跨技术栈直接套用。
• 分清 server-side 与 client-side 很关键：前者危害通常更高，后者常依赖前端脚本的信任边界，评估时要分别对待。