HTTP参数污染
HTTP参数污染（HPP）的形成原因
HTTP参数污染（HPP，HTTP Parameter Pollution）是指攻击者通过向Web应用程序发送多个同名的HTTP参数，利用服务器或中间件处理这些参数的差异性，导致应用程序逻辑被篡改的安全漏洞。其形成原因主要包括以下方面：
-
参数解析差异
不同服务器、框架或中间件对同名参数的处理方式不同。例如：-
PHP/Apache：默认取最后一个同名参数。
-
ASP.NET/IIS：合并同名参数（例如：
param=value1,value2）。 -
Java/Tomcat：取第一个同名参数。
-
Node.js/Express：同名参数会被解析为数组。
-
-
多层架构处理不一致
在多层架构（如反向代理+应用服务器）中，不同层级可能对参数的处理逻辑不同。例如前端代理可能取第一个参数，而后端服务器取最后一个。 -
缺乏输入验证
应用程序未对参数的数量和来源进行严格校验，导致攻击者可以注入额外参数。 -
框架或库的默认行为
某些框架（如Spring、Django）的默认参数解析逻辑可能被攻击者利用。
HPP漏洞复现方法与过程
复现步骤
-
发现参数注入点
找到目标应用中接受用户输入的参数（如URL参数、POST表单字段、HTTP头）。 -
测试参数解析逻辑
发送多个同名参数，观察服务器如何处理：
-
GET /user/profile?username=alice&username=bob HTTP/1.1
观察响应结果，判断是取第一个、最后一个、合并还是其他行为。
-
分析业务逻辑影响
-
覆盖关键参数：篡改身份验证、权限控制参数。
-
绕过输入过滤：通过多个参数绕过WAF或黑名单检查。
-
触发逻辑错误：例如传递数组参数导致SQL注入或代码执行。
-
-
根据参数处理差异，构造攻击场景：
复现实例：篡改用户身份
场景
某应用通过URL参数user_id查询用户信息，后端使用最后一个user_id参数。
攻击步骤：
-
正常请求：
-
GET /profile?user_id=123 HTTP/1.1
返回用户123的信息。
-
攻击者构造污染参数：
-
GET /profile?user_id=123&user_id=456 HTTP/1.1
后端解析最后一个参数
user_id=456，返回用户456的信息，导致越权访问。
复现实例：绕过WAF检测
场景
某登录接口的密码参数被WAF检测，阻止password=admin' OR 1=1--。
攻击步骤：
-
污染参数注入：
-
POST /login HTTP/1.1 ... username=admin&password=legit&password=admin' OR 1=1--
-
若后端取最后一个
password参数，恶意SQL绕过WAF检测，实现注入。
防御措施
-
严格校验参数
限制参数数量，禁止同名参数。 -
参数白名单
只允许必需参数，忽略冗余参数。 -
统一解析逻辑
明确选择首个或末尾参数，避免依赖框架默认行为。 -
安全配置中间件
例如Nginx配置merge_slashes off防止路径混淆。
验证部分：
例：输入?keyword=9897&keyword=9898页面返回9897
1. 初步验证参数解析行为
在你的测试案例中，提交 ?keyword=9897&keyword=9898 后返回了关键字 9898 的结果，说明后端可能：
-
取最后一个同名参数（如PHP/Apache默认行为）。
-
但需进一步验证是否为漏洞，需结合业务场景判断是否可被利用。
验证步骤：
-
重复参数覆盖测试
尝试在不同功能点提交多个同名参数，观察是否覆盖预期值：-
例如修改用户ID、权限参数、跳转URL等。
http
-
-
GET /profile?user_id=normal_user&user_id=admin
-
若返回管理员数据，说明存在越权漏洞。
-
-
参数位置测试
测试参数在 URL、POST Body、HTTP Headers 中的行为差异：http
-
POST /update_info HTTP/1.1 ... username=alice&username=evil
-
观察后端是否解析POST中的重复参数。
-
-
参数拼接测试
测试服务器是否合并参数（如ASP.NET/IIS）：http
-
GET /search?query=hello&query=world
-
若返回结果包含
hello,world，说明参数被合并。
-
2. 业务场景利用验证
仅参数解析差异不构成漏洞，需验证是否影响业务逻辑：
测试场景示例：
-
身份篡改
尝试覆盖身份标识参数（如user_id、email）：http
-
GET /dashboard?user_id=1001&user_id=1002
-
若返回用户1002的数据，存在越权漏洞。
-
-
WAF/SQL注入绕过
通过污染参数绕过安全检测：http
-
POST /login HTTP/1.1 ... password=aaa&password=' OR 1=1--
-
若后端取最后一个参数且未过滤，可能触发SQL注入。
-
-
URL跳转劫持
篡改重定向URL参数：http
-
GET /redirect?url=trusted.com&url=evil.com
-
若跳转至
evil.com，存在开放重定向漏洞。
-
3. 自动化辅助检测
-
工具扫描
使用Burp Suite、OWASP ZAP等工具的 HPP插件 自动检测参数解析差异。 -
流量重放
在Burp中右键请求 -> Extensions -> Param Miner，自动探测参数污染点。
4. 你的案例具体分析
根据你的测试结果 ?keyword=9897&keyword=9898 返回 9898：
-
初步结论
后端解析了最后一个参数，可能存在HPP漏洞。 -
进一步验证
-
测试关键业务参数：如支付接口的
amount、权限校验的role。 -
尝试逻辑覆盖：
例如添加参数?is_admin=0&is_admin=1，观察是否提升权限。
-
-
漏洞评级
-
若仅影响搜索关键字，风险较低（需结合业务敏感性）。
-
若可篡改身份、绕过认证，则为高危漏洞。
-
5. 防御方案
若确认漏洞存在，需修复方案：
-
强制单一参数
后端代码中明确取第一个或最后一个参数，禁止冗余参数：python
-
# Django示例：只取最后一个参数 keyword = request.GET.get('keyword', '') -
输入过滤
使用安全框架（如Spring Security）过滤重复参数。 -
WAF规则
配置Web应用防火墙拦截包含多个同名参数的请求。