Security Cipher

Menu
Contact Us

Security Resources

⌘K
  2. Home
  4. Security Resources
  6. Vulnerability Explain
  8. HTTP Request Smuggling

HTTP Request Smuggling

This Vulnerability Explain post tackles HTTP Request Smuggling, an advanced but high-impact flaw. It exploits subtle disagreements between servers about where one HTTP request ends and the next begins. The payoff for attackers can be huge – hijacked requests, bypassed controls, and mass user compromise. Let’s unpack it.

What is HTTP Request Smuggling?

HTTP Request Smuggling abuses inconsistencies in how chained servers (typically a front-end proxy and a back-end server) parse request boundaries, especially the Content-Length and Transfer-Encoding headers. When they disagree, an attacker can smuggle a hidden request inside a normal one.

Imagine a front-end that uses Content-Length and a back-end that uses Transfer-Encoding to decide where a request ends. By crafting a message that each interprets differently, the attacker leaves part of their payload in the back-end’s buffer, where it prepends to the next user’s request – effectively hijacking it.

How does HTTP Request Smuggling work?

Request smuggling relies on parser disagreement and unfolds like this:

  • Two Servers In a Chain
    • A front-end proxy forwards requests to a back-end server over a reused connection.
  • Ambiguous Length Headers
    • The request includes both Content-Length and Transfer-Encoding, or malformed versions, that the two servers handle differently.
  • Desync
    • One server thinks the request ended earlier than the other, leaving leftover bytes in the connection.
  • Smuggled Request
    • Those leftover bytes are treated as the start of the next request on the shared connection.
  • Impact
    • The smuggled prefix can hijack other users’ requests, bypass security controls, poison caches, or steal credentials.

Request smuggling is dangerous because it weaponizes the gap between two correct-ish parsers. Consistent, strict handling of message boundaries is the only real cure.

HTTP request smuggling diagram showing a front-end and back-end server disagreeing on request boundaries

How request smuggling works: front-end and back-end servers disagree on where a request ends.

Tools and Techniques for HTTP Request Smuggling Testing

Testing is timing-sensitive and benefits strongly from specialized tooling.

Manual Testing Methodologies

  • CL.TE and TE.CL Probing – Craft requests with conflicting Content-Length and Transfer-Encoding headers and observe desync via timing or response differences.
  • Obfuscated TE Headers – Test variations like spacing, casing, and duplicate Transfer-Encoding to bypass front-end normalization.
  • Differential Timing – Use response delays to confirm a back-end is waiting for smuggled bytes.
  • Impact Validation – Carefully demonstrate impact (for example capturing another request) only within authorized scope.

Automated Scanning Tools

HTTP Request Smuggling Protection Mechanisms

Best Practices for Secure Coding

  • Reject Ambiguous Requests
    • Description: Treat a request with both Content-Length and Transfer-Encoding as invalid.
    • Benefits: Removes the core ambiguity smuggling depends on.
    • Implementation Tip: Configure servers to reject conflicting length headers.
  • Normalize at the Edge
    • Description: Have the front-end normalize and validate requests before forwarding.
    • Benefits: Ensures both tiers see the same boundaries.
    • Implementation Tip: Strip unexpected headers and reject malformed chunking.
  • Prefer HTTP/2 End to End
    • Description: Use a consistent, modern protocol across the chain.
    • Benefits: HTTP/2 length handling avoids many classic desync issues.
    • Implementation Tip: Avoid downgrading to HTTP/1.1 between tiers where possible.

Best Practices for Organizations

  • Consistent Server Stack
    • Keep front-end and back-end HTTP parsers aligned and patched.
    • Avoid mismatched proxy and server combinations known to desync.
  • Connection Hygiene
    • Disable or limit back-end connection reuse where appropriate.
    • Monitor for unusual request boundaries.
  • Testing
    • Run smuggling scans against edge infrastructure.
    • Re-test after proxy or load-balancer changes.

Top HTTP Request Smuggling payloads used by Security Researchers

As a security researcher, knowing the most common payloads helps you detect and prevent these attacks. Use this knowledge ethically and only on systems you are authorized to test. Some sample payloads are shown below.

// CL.TE desync (front-end uses Content-Length, back-end uses Transfer-Encoding)
POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked

0

G
// TE.CL desync (front-end uses Transfer-Encoding, back-end uses Content-Length)
POST / HTTP/1.1
Host: target.com
Content-Length: 4
Transfer-Encoding: chunked

5c
GPOST /admin HTTP/1.1
...
// Obfuscated Transfer-Encoding to bypass normalization
Transfer-Encoding: chunked
Transfer-Encoding:  x
Transfer-Encoding:	chunked
// Header smuggling to prepend to the next request
POST / HTTP/1.1
Content-Length: 0
Transfer-Encoding: chunked

0

GET /private HTTP/1.1
Foo: x

Real-World Example: Hijacking Requests Behind a Proxy

A site placed an HTTP/1.1 back-end behind a caching proxy. The proxy honored Content-Length while the back-end preferred Transfer-Encoding, a classic CL.TE mismatch.

A researcher sent a crafted request that the proxy saw as complete but the back-end left partially buffered. The leftover bytes prepended to the next visitor’s request, letting the researcher capture that victim’s request including their session cookie.

The fix configured both tiers to reject requests carrying both length headers and aligned the HTTP stack. Request smuggling is advanced, but the principle is simple: every server in the chain must agree, exactly, on where a request ends.

Vulnerable and secure code of HTTP Request Smuggling

The following example shows the contrast between vulnerable and secure code for HTTP Request Smuggling. It helps you see how the flaw creeps into real code and the changes that shut it down.

🥺 Vulnerable Code:

# Vulnerable: front-end and back-end disagree on message length
# Front-end (proxy) trusts Content-Length: 6  -> forwards "0\r\n\r\nG"
# Back-end trusts Transfer-Encoding: chunked   -> request ends at "0"
# The leftover "G" starts the NEXT request on the reused connection.

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

0

G
  • Both Content-Length and Transfer-Encoding are present and conflict.
  • The desync leaves bytes that hijack the following request on a shared connection.

😎 Secure Code:

# Secure: edge configuration rejects ambiguous requests
# Example NGINX-style hardening concept:
#  - Reject requests containing both Content-Length and Transfer-Encoding
#  - Do not forward unknown/obfuscated Transfer-Encoding values
#  - Prefer HTTP/2 to the back-end

if ($http_transfer_encoding != "") {
    # if Content-Length is also set, return 400 Bad Request
    return 400;
}
# Forward only normalized, unambiguous requests to the back-end
  • Requests with conflicting length headers are rejected before forwarding.
  • Normalizing at the edge ensures both tiers agree on request boundaries.

Conclusion

HTTP Request Smuggling weaponizes tiny disagreements between servers about where a request ends, and the impact – hijacked requests and mass compromise – is anything but tiny. Reject requests that carry both Content-Length and Transfer-Encoding, normalize and validate at the edge, keep your HTTP stack aligned and patched, and prefer modern protocols end to end. When every server agrees on boundaries, there is nothing to smuggle.

How can we help?