HTTP 请求走私（HTTP Request Smuggling）是一种通过利用前端代理（如负载均衡器、CDN）和后端服务器在 解析 HTTP 请求时存在不一致性 的漏洞，从而实现 注入恶意请求 的攻击技术。
一、基本原理
HTTP 请求走私主要依赖两个请求头字段的不一致处理：
Content-Length：指明请求体的长度。Transfer-Encoding: chunked：指明请求体是分块传输的。
不一致的场景
当前端和后端服务器对这两个头的解释不一致时，攻击者就能将多个请求“混淆”为一个请求，从而：
绕过认证
注入恶意请求
劫持用户会话
发起缓存投毒
进行 XSS / CSRF 攻击
常见的组合方式：
| 名称 | 条件 |
|---|---|
| CL.TE | 前端使用 Content-Length，后端使用 Transfer-Encoding |
| TE.CL | 前端使用 Transfer-Encoding，后端使用 Content-Length |
| TE.TE | 前端和后端都支持 Transfer-Encoding，但处理方式不同 |
二、CL.TE 类型攻击示例
假设你有以下攻击场景：
前端（比如 Nginx）使用
Content-Length解析请求；后端（比如 Apache）使用
Transfer-Encoding: chunked解析请求。
攻击请求如下：
POST / HTTP/1.1
Host: vulnerable.site
Content-Length: 62
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable.site
解析过程：
前端（Nginx）：
只看
Content-Length: 62，把整段请求当作一个完整请求发送到后端。
后端（Apache）：
看到
Transfer-Encoding: chunked，开始以分块方式解析请求。0\r\n\r\n表示请求体结束。后面的
GET /admin HTTP/1.1...被解释为另一个完整的 HTTP 请求。
→ 后端就会执行这个攻击者构造的请求 GET /admin，可能会绕过权限控制！
三、防御方式
统一前后端解析逻辑
确保前后端对 HTTP 请求头的处理一致。
禁止混合使用
Content-Length和Transfer-Encoding可以在 Web 应用防火墙（WAF）中检测并拒绝。
升级服务器
新版本的服务器通常修复了相关解析不一致的问题。
使用 Web Application Firewall（WAF）
例如 ModSecurity 可以检测这种模糊请求。
启用 Chunked 请求白名单机制
如果应用不需要 chunked 编码，直接禁用该特性。
以下是一个真实的 HTTP 请求走私（HTTP Request Smuggling）攻击案例，展示了其在现实世界中的危害性。
🧪 案例：利用请求走私劫持用户会话
安全公司 Outpost24 在一次渗透测试中发现，某 Web 应用存在 TE:CL 类型的请求走私漏洞。通过精心构造的请求，攻击者成功实现了响应队列的不同步（Response Queue Desynchronization），从而劫持了其他用户的会话。Outpost24+1Outpost24+1
攻击过程：
识别漏洞：使用工具检测到前端服务器使用
Transfer-Encoding解析请求，而后端服务器使用Content-Length，存在解析不一致。构造恶意请求：发送包含两个请求的单个 HTTP 请求，其中第一个请求设置了特定的头部，使后端服务器将两个请求视为一个，从而导致响应队列不同步。
劫持会话：由于响应队列不同步，攻击者能够接收到属于其他用户的响应，其中可能包含敏感信息，如访问令牌。
🔍 案例：Apache Tomcat 中的请求走私漏洞（CVE-2021-33037）
Apache Tomcat 是广泛使用的 Java Web 服务器。在 2021 年，发现其存在一个请求走私漏洞（CVE-2021-33037），影响版本包括 8.5.0 至 8.5.66、9.0.0.M1 至 9.0.46 和 10.0.0-M1 至 10.0.6。该漏洞源于 Tomcat 在某些情况下未正确解析 HTTP 的 Transfer-Encoding 请求头，导致在与反向代理一起使用时可能发生请求走私。QualysPortSwigger+1Qualys+1
攻击者可以利用该漏洞，隐藏恶意请求在正常请求中，绕过安全检查，执行未授权的操作。该漏洞已在后续版本中修复，建议用户升级至最新版本。