HTTP方法覆盖攻击详解

1. 攻击背景与基本概念

HTTP协议定义了多种请求方法（如GET、POST、PUT、DELETE等），但某些Web框架或应用允许客户端通过参数覆盖实际请求方法。例如，应用可能根据_method、X-HTTP-Method-Override等参数而非实际HTTP方法处理请求。这种机制本用于兼容不支持PUT/DELETE等方法的客户端，但若校验不当，攻击者可利用它绕过安全限制。

核心问题：

• 应用信任客户端传入的方法覆盖参数，未验证原始请求方法或来源合法性。
• 可能导致攻击者以低权限请求（如GET）执行高权限操作（如DELETE）。

2. 攻击原理与场景

2.1 常见的覆盖方式

1. 表单参数覆盖：

   <form action="/delete" method="POST">  
     <input type="hidden" name="_method" value="DELETE">  
     <input type="submit" value="删除">  
   </form>  
   

   后端解析_method参数后，将请求视为DELETE方法处理。

2. HTTP头部覆盖：

   POST /api/resource HTTP/1.1  
   X-HTTP-Method-Override: PUT  
   

   后端根据该头部将请求转换为PUT方法。

2.2 攻击场景示例

假设应用对GET/POST请求进行CSRF防护，但对PUT/DELETE仅依赖身份验证。攻击者可构造如下请求：

POST /admin/delete_user/123 HTTP/1.1  
Content-Type: application/x-www-form-urlencoded  
...（身份验证Cookie）...  
_method=DELETE  

若后端未校验原始方法，会直接执行删除操作，而普通CSRF防御可能仅检查GET/POST。

3. 攻击步骤详解

步骤1：探测方法覆盖支持

1. 拦截正常请求（如POST请求修改数据），尝试添加覆盖参数：
   • 参数名：_method、X-HTTP-Method-Override、method等。
   • 值：尝试改为PUT、DELETE、PATCH等。
2. 观察响应是否执行了对应操作（如数据被修改或删除）。

步骤2：绕过权限或CSRF检查

1. 若应用对POST进行CSRF令牌验证，但PUT不需要：
   • 发送POST请求，包含_method=PUT，并移除CSRF令牌。
   • 后端可能因方法覆盖视为PUT请求，跳过CSRF检查。
2. 若权限检查基于HTTP方法（如DELETE仅限管理员）：
   • 普通用户发送POST请求覆盖为DELETE，可能绕过方法级权限控制。

步骤3：组合其他攻击

• 结合参数污染（如同时发送_method=PUT&_method=DELETE），利用后端解析差异执行意外操作。

4. 防御措施

4.1 严格校验原始请求方法

• 仅允许POST请求进行方法覆盖，禁止GET请求覆盖（避免CSRF易利用）。
• 记录原始方法日志，用于审计异常行为。

4.2 限制可覆盖的方法范围

# 示例：仅允许覆盖为PUT/PATCH  
allowed_methods = ['PUT', 'PATCH']  
if params.get('_method') not in allowed_methods:  
    reject_request()  

4.3 强制验证覆盖请求的合法性

• 对覆盖后的请求施加与目标方法相同的安全策略（如CSRF检查、权限验证）。
• 避免依赖客户端输入决定方法，优先使用实际HTTP方法。

4.4 使用标准替代方案

• 禁用方法覆盖，要求客户端直接使用目标HTTP方法。
• 若需兼容，通过API网关或代理层统一转换，而非应用层解析。

5. 总结

HTTP方法覆盖攻击本质是信任边界混淆——应用过度信任客户端输入而偏离协议标准。防御关键在于：

1. 不信任原则：始终验证覆盖参数的合法性与一致性。
2. 最小权限：对覆盖后的方法实施与原方法相同的安全控制。
3. 审计监控：记录方法覆盖行为，及时发现异常模式。

通过严格限制覆盖机制的使用场景与权限，可有效避免此类漏洞被利用。