HTTP Request Smuggling

HTTP Request Smuggling

In this section we explain what HTTP request smuggling is and describe how common smuggling vulnerabilities are created.

What is HTTP Request Smuggling

HTTP request smuggling is a technique that interferes with how a website processes a sequence of HTTP requests. The vulnerability allows an attacker to bypass security controls, gain unauthorized access to sensitive data, and affect other application users.

How Does HTTP Request Smuggling Actually Happen

Modern architectures often use load balancers, reverse proxies, or gateways that forward requests from a front‑end server to a back‑end server over the same network connection, sending multiple requests sequentially for efficiency. The front‑end server parses the request headers to determine where one request ends and the next begins.

If the front‑end and back‑end servers disagree on request boundaries, an attacker can craft an ambiguous request that each server parses differently, causing part of one request to be interpreted as the start of the next request on the back‑end. This is the essence of a request‑smuggling attack and can have devastating consequences.

How HTTP Request Smuggling Vulnerabilities Are Produced

The majority of smuggling bugs stem from the HTTP specification providing two ways to indicate the end of a request body: the Content-Length header and the Transfer-Encoding header.

Content-Length simply specifies the body length in bytes, e.g.:

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

Transfer-Encoding can declare a chunked encoding, where the body is split into chunks, each preceded by its size in hexadecimal followed by CRLF, the chunk data, and another CRLF. The terminating chunk has size zero. Example:

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

Because both mechanisms can appear in the same message, they may conflict. The specification says that if both Content-Length and Transfer-Encoding are present, Content-Length must be ignored. When a single server processes the request this ambiguity can be avoided, but when a front‑end and a back‑end server are chained the ambiguity leads to smuggling. Two main reasons cause the problem:

Some servers do not support the Transfer-Encoding header.

Some servers support Transfer-Encoding but can be tricked into ignoring it.

If the front‑end and back‑end handle Transfer-Encoding differently, they may disagree on request boundaries, creating a smuggling vulnerability.

How to Perform HTTP Request Smuggling Attacks

Attacks require sending both Content-Length and Transfer-Encoding headers so that the front‑end and back‑end interpret the request differently. The three classic variants are:

CL.TE : Front‑end uses Content-Length , back‑end uses Transfer-Encoding .

TE.CL : Front‑end uses Transfer-Encoding , back‑end uses Content-Length .

TE.TE : Both use Transfer-Encoding but the header is obfuscated so that one server ignores it.

CL.TE Vulnerability

Example attack:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0
SMUGGLED

The front‑end reads 13 bytes (the SMUGGLED part) based on Content-Length and forwards the request. The back‑end treats the body as chunked, sees a zero‑length terminating chunk, and interprets SMUGGLED as the start of the next request.

TE.CL Vulnerability

Example attack:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

The front‑end parses the body as chunked, stops at the zero‑length chunk, and forwards the remainder. The back‑end uses Content-Length and treats only the first three bytes as the body, leaving the rest as a new request.

TE.TE Confusing Transfer‑Encoding Header

Both servers use Transfer-Encoding , but the header is obfuscated (e.g., extra spaces, different capitalisation, duplicate headers) so that one server ignores it while the other processes it. Example variations:

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

How to Defend Against HTTP Request Smuggling

When a front‑end forwards multiple requests over a single connection and the two servers disagree on request boundaries, smuggling can occur. General mitigation strategies include:

Disable connection reuse to the back‑end so each request uses a separate network connection.

Use HTTP/2 between front‑end and back‑end, as it eliminates ambiguity about request boundaries.

Ensure the front‑end and back‑end run the same web software version so they interpret boundaries identically.

In some cases, making the front‑end reject ambiguous requests or close the connection can also prevent the vulnerability, though this approach is error‑prone.

Finding HTTP Request Smuggling Vulnerabilities

We now describe techniques for locating smuggling bugs.

Timing Techniques

The most common detection method is to send a crafted request and observe a noticeable response delay if a vulnerability exists.

Using Timing to Find CL.TE Bugs

Send a request like:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

The front‑end treats the body as 4 bytes ("1\r\nA"), ignoring the trailing "X". The back‑end, expecting chunked encoding, waits for the terminating chunk "0\r\n", causing a delay.

Using Timing to Find TE.CL Bugs

Send a request like:

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

0
X

The front‑end stops at the zero‑length chunk and forwards the request; the back‑end waits for six more bytes, again causing a delay.

Using Differential Responses to Confirm Smuggling

After a possible smuggling detection, send an attack request followed by a normal request on a separate connection. If the normal request's response differs (e.g., a 404 instead of expected content), the vulnerability is confirmed.

Confirming CL.TE

Attack request example:

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked

e
q=smuggling&x=
0

GET /404 HTTP/1.1
Foo: x

If successful, the back‑end treats the final two lines as a new request, resulting in a 404 response.

Confirming TE.CL

Attack request example:

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

Successful exploitation also yields a 404 response.

Important notes when confirming smuggling:

Attack and normal requests must be sent over separate connections.

Use the same URL and parameters for both requests to increase the chance they hit the same back‑end.

Send the normal request immediately after the attack request; retries may be needed.

If a load balancer distributes requests, the two requests might reach different back‑ends, requiring multiple attempts.

Be aware that successful smuggling may affect other users; proceed with caution.

Exploiting HTTP Request Smuggling

This section describes several ways to leverage smuggling vulnerabilities.

Bypassing Front‑End Security Controls

When the front‑end enforces access control but the back‑end trusts forwarded requests, an attacker can smuggle a request to a protected resource (e.g., /admin ) after a permitted request (e.g., /home ), effectively bypassing the control.

Front‑End Request Rewrites

Front‑ends often rewrite requests (adding headers like X-Forwarded-For or user‑ID information). If a smuggled request lacks these rewrites, the back‑end may reject it. Understanding the rewrite behavior can be achieved by reflecting request parameters in responses and then smuggling a request to observe the rewritten form.

Capturing Other Users' Requests

By smuggling a request that stores data (e.g., a comment), an attacker can cause the next victim's request—including cookies and other sensitive data—to be stored as comment content, which can later be retrieved.

Using Smuggling for Reflected XSS

If a reflected XSS exists in a header such as User-Agent , an attacker can smuggle a request containing a malicious payload in that header. The next user's request will cause the payload to be reflected back.

Turning In‑Site Redirects into Open Redirects

Many servers issue internal redirects based on the Host header. By smuggling a request with a malicious Host , an attacker can cause a legitimate redirect to point to an attacker‑controlled domain, enabling further attacks.

Web Cache Poisoning via Smuggling

When a front‑end or downstream cache stores responses, a smuggled request that triggers a redirect can cause the cache to store the malicious redirect. Subsequent users requesting the cached URL will be redirected to the attacker’s site.

Web Cache Deception via Smuggling

Similar to poisoning, but the attacker aims to have the cache store a victim’s private content (e.g., private messages) under a static URL. The attacker can later retrieve the sensitive data from the cache.

These techniques illustrate why HTTP request smuggling is a critical security issue and why proper handling of Content-Length and Transfer-Encoding headers, along with consistent parsing across all components, is essential.