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，可能会绕过权限控制！

---

三、防御方式

1. 统一前后端解析逻辑

   • 确保前后端对 HTTP 请求头的处理一致。

2. 禁止混合使用 Content-Length 和 Transfer-Encoding

   • 可以在 Web 应用防火墙（WAF）中检测并拒绝。

3. 升级服务器

   • 新版本的服务器通常修复了相关解析不一致的问题。

4. 使用 Web Application Firewall（WAF）

   • 例如 ModSecurity 可以检测这种模糊请求。

5. 启用 Chunked 请求白名单机制

   • 如果应用不需要 chunked 编码，直接禁用该特性。

---

以下是一个真实的 HTTP 请求走私（HTTP Request Smuggling）攻击案例，展示了其在现实世界中的危害性。

---

🧪 案例：利用请求走私劫持用户会话

安全公司 Outpost24 在一次渗透测试中发现，某 Web 应用存在 TE:CL 类型的请求走私漏洞。通过精心构造的请求，攻击者成功实现了响应队列的不同步（Response Queue Desynchronization），从而劫持了其他用户的会话。Outpost24+1Outpost24+1

攻击过程：

1. 识别漏洞：使用工具检测到前端服务器使用 Transfer-Encoding 解析请求，而后端服务器使用 Content-Length，存在解析不一致。

2. 构造恶意请求：发送包含两个请求的单个 HTTP 请求，其中第一个请求设置了特定的头部，使后端服务器将两个请求视为一个，从而导致响应队列不同步。

3. 劫持会话：由于响应队列不同步，攻击者能够接收到属于其他用户的响应，其中可能包含敏感信息，如访问令牌。

---

🔍 案例：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

攻击者可以利用该漏洞，隐藏恶意请求在正常请求中，绕过安全检查，执行未授权的操作。该漏洞已在后续版本中修复，建议用户升级至最新版本。