Web安全之业务安全：参数污染漏洞原理与防护详解

一、漏洞描述
参数污染（Parameter Pollution）是一种业务逻辑漏洞，攻击者通过向同一参数名提交多个值（如?id=1&id=2），利用服务端解析参数的差异性，绕过验证或触发异常逻辑。例如，某些系统可能解析第一个id值进行权限校验，但使用最后一个id值执行操作，导致越权。

二、漏洞原理

1. 参数解析差异：

   • 不同技术栈（如PHP/Apache、Java/Tomcat、Node.js/Express）对同名参数的处理方式不同。例如：
     • PHP默认解析最后一个值（id=2）。
     • Java Spring可能解析为数组（id=[1,2]）。
     • Node.js Express默认解析第一个值（id=1）。
   • 若业务代码未规范处理多值参数，可能依赖错误的值进行逻辑判断。

2. 典型场景：

   • 权限绕过：

     GET /delete?id=1&id=2  
     

     权限校验使用id=1（用户有权限），但删除操作使用id=2（其他用户数据）。
   • 输入校验绕过：
     校验逻辑检查第一个参数（如格式合法），但业务使用第二个参数（含恶意载荷）。

三、漏洞复现与测试

1. 测试方法：

   • 使用Burp Suite等工具重复添加同名参数：

     POST /update HTTP/1.1
     Content-Type: application/x-www-form-urlencoded
     user=alice&user=admin&role=user
     

   • 观察响应是否因参数顺序变化而产生差异。

2. 案例模拟：

   • 假设用户修改邮箱的接口：

     // 错误代码示例（Express框架）
     app.post('/change-email', (req, res) => {
       const userId = req.body.userId; // 默认取第一个值
       const newEmail = req.body.newEmail; 
       // 权限校验：检查userId是否匹配当前会话用户
       if (checkPermission(req.session.userId, userId)) {
         updateEmail(userId, newEmail); // 实际使用第一个userId
       }
     });
     

   • 攻击载荷：

     POST /change-email  
     userId=123&userId=456&newEmail=attacker@evil.com
     

     权限校验使用userId=123（合法用户），但更新操作使用userId=123（仍为第一个值），此处需结合框架特性调整攻击方式。

四、防护策略

1. 参数规范化：

   • 强制只取第一个或最后一个值，避免解析歧义：

     // Express中明确取第一个值
     const userId = Array.isArray(req.body.userId) ? req.body.userId[0] : req.body.userId;
     

   • 使用严格的数据类型转换（如parseInt()）拒绝数组参数。

2. 输入验证：

   • 拒绝包含同名参数的请求，或返回错误提示。
   • 使用中间件过滤多值参数：

     app.use((req, res, next) => {
       for (let key in req.body) {
         if (Array.isArray(req.body[key])) {
           return res.status(400).json({ error: "Multiple values for parameter not allowed" });
         }
       }
       next();
     });
     

3. 安全编码实践：

   • 避免直接使用请求参数进行敏感操作，优先从会话中获取用户身份。
   • 对参数进行白名单验证，确保符合预期格式（如单值、数字类型）。

五、总结
参数污染漏洞源于技术栈差异与开发人员对参数处理的疏忽。防护核心在于统一参数解析逻辑、严格校验输入类型，并遵循“从可信源获取数据”的原则（如会话信息优于客户端参数）。