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请求）的一部分执行，实现请求走私。
检测方法
防御措施
- 统一解析：确保前端和后端服务器使用相同品牌、版本的HTTP解析器，并配置一致。
- 禁用歧义头：在前端代理处规范化请求，例如始终优先使用Transfer-Encoding，或完全禁用分块编码。
- 升级协议：使用HTTP/2，因其具有严格的分帧机制，能从根本上消除请求走私的解析歧义。同时需注意防范HTTP/2降级攻击。
- 纵深防御：在后端应用层实施额外的安全校验，不依赖前端代理传递的请求边界信息。
参考来源
- HTTP请求走私实战 | 从零解析PortSwigger靶场漏洞（CL.TE篇）
- CDN与负载均衡器混用埋雷？解密HTTP请求走私的4种攻击场景及防御方案
- 终极 h2cSmuggler 教程：如何利用 HTTP/2 走私攻击绕过安全防护 [特殊字符]
- 2025年渗透测试面试题总结-240（题目+回答）
- HTTP请求走私漏洞原理与利用手段分析
