HTTP走私漏洞详解与防御
·
HTTP请求走私是一种利用前端服务器（如反向代理、负载均衡器、CDN）与后端服务器对HTTP请求解析不一致，从而将恶意请求“走私”到正常请求流中的攻击技术。其核心危害在于绕过安全控制、劫持用户会话、访问未授权API、进行Web缓存投毒等。
漏洞成因与分类
漏洞的根本原因是前端和后端服务器对Content-Length (CL) 和 Transfer-Encoding (TE) 这两个HTTP请求头处理方式不同，导致对请求体结束位置的判断出现分歧。主要分为以下四类：
| 攻击类型 | 前端服务器解析依据 | 后端服务器解析依据 | 关键特征 |
|---|---|---|---|
| CL.TE | Content-Length |
Transfer-Encoding |
前端根据CL确定请求体长度，后端期待TE分块编码。 |
| TE.CL | Transfer-Encoding |
Content-Length |
前端处理分块请求，后端根据CL读取请求体。 |
| TE.TE | Transfer-Encoding（处理特定值） |
Transfer-Encoding（处理不同值） |
前后端均声明支持TE，但对TE头的值（如chunked、xchunked）或格式（如空格、大小写）的解析存在差异。 |
| CL.CL | 第一个Content-Length头 |
第二个Content-Length头 |
请求中包含两个具有不同值的CL头，前后端选择了不同的值进行解析。 |
攻击示例与利用
以最常见的CL.TE型攻击为例，攻击者构造一个包含冲突头部的请求，使前端认为的请求结束位置与后端不同，从而将后续请求的一部分“走私”为当前请求的一部分。
POST /vulnerable-endpoint HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
- 前端视角：看到
Content-Length: 13，认为请求体是0\r \r SMUGGLED（共13字节），并将整个请求转发给后端。 - 后端视角：看到
Transfer-Encoding: chunked，按分块编码解析。0\r \r表示一个长度为0的块，即请求体在此结束。而后面的SMUGGLED会被视为下一个请求的开始。
当攻击者连续发送两个这样的请求时，SMUGGLED就可能被后端当作第二个独立请求（如GET请求）的一部分执行，实现请求走私。
检测方法
- 时间延迟检测：发送一个可能造成走私的请求，如果服务器处理异常（如等待超时），则可能存在漏洞。
- 响应差异检测：发送两个请求，观察第二个请求的响应是否受到第一个请求中“走私”内容的影响。
- 工具自动化：使用Burp Suite的 HTTP Request Smuggler 插件或 h2cSmuggler（针对HTTP/2）等工具进行高效扫描。
防御措施
- 统一解析：确保前端和后端服务器使用相同品牌、版本的HTTP解析器，并配置一致。
- 禁用歧义头：在前端代理处规范化请求，例如始终优先使用
Transfer-Encoding，或完全禁用分块编码。 - 升级协议：使用HTTP/2，因其具有严格的分帧机制，能从根本上消除请求走私的解析歧义。同时需注意防范HTTP/2降级攻击。
- 纵深防御：在后端应用层实施额外的安全校验，不依赖前端代理传递的请求边界信息。
参考来源
- HTTP请求走私实战 | 从零解析PortSwigger靶场漏洞（CL.TE篇）
- CDN与负载均衡器混用埋雷？解密HTTP请求走私的4种攻击场景及防御方案
- 终极 h2cSmuggler 教程：如何利用 HTTP/2 走私攻击绕过安全防护 [特殊字符]
- 2025年渗透测试面试题总结-240（题目+回答）
- HTTP请求走私漏洞原理与利用手段分析
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
8
0- 0
已为社区贡献1条内容
所有评论(0)