portswigger-all-labs

Complete PortSwigger Web Security Academy Lab Writeups Detailed, categorized solutions for every lab — from APPRENTICE to EXPERT — covering all 30 vulnerability types.

View on GitHub

What is HTTP Request Smuggling?

HTTP request smuggling is a web security vulnerability that allows attackers to manipulate HTTP requests in a way that exploits differences in how front-end and back-end servers interpret them. By sending ambiguous requests, attackers can disrupt the normal processing of request sequences, potentially leading to serious consequences such as bypassing security controls, accessing sensitive data, or interfering with other users’ interactions. This issue is particularly prevalent in HTTP/1 setups, though HTTP/2 systems can also be affected when downgraded to HTTP/1 for back-end communication. It’s a critical concern because it undermines the integrity of web application traffic, making it a powerful tool for attackers.

image

What Happens in an HTTP Request Smuggling Attack?

Modern web applications often rely on a chain of servers to process incoming requests. A front-end server—like a load balancer or reverse proxy—receives requests from users and forwards them to a back-end server for processing. To improve efficiency, the front-end typically sends multiple requests over a single persistent connection, requiring both servers to agree on where one request ends and the next begins.

In an HTTP request smuggling attack, the attacker crafts a request that is interpreted differently by the two servers:

For example, an attacker could “smuggle” a portion of their request past the front-end server, attaching it to the next legitimate request processed by the back-end. This desynchronization can enable:

The root of the problem lies in the servers’ disagreement on request boundaries, which attackers exploit to manipulate the flow of traffic.

How Do HTTP Request Smuggling Vulnerabilities Arise?

HTTP request smuggling vulnerabilities stem from the HTTP/1 specification, which provides two methods to define the length of a request’s body:

  1. Content-Length Header
    Specifies the exact length of the body in bytes.
    Example: 
    POST / HTTP/1.1
Host: example.com
Content-Length: 11
Hello World

    Here, the body (Hello World) is 11 bytes long.

  2. Transfer-Encoding Header
    Uses chunked encoding to send the body in segments, with each chunk’s size given in hexadecimal, ending with a zero chunk.
    Example: 
    POST / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
5
Hello
6
World!
0

    The body is sent in two chunks (Hello and World!), terminated by 0.

According to the HTTP/1 standard, if both Content-Length and Transfer-Encoding headers are present, Transfer-Encoding takes precedence, and Content-Length is ignored. However, problems arise in chained server setups due to inconsistent handling:

When the front-end and back-end servers process these headers differently—one using Content-Length and the other Transfer-Encoding—they disagree on where the request ends, creating an opportunity for smuggling.

HTTP/2 Context: HTTP/2 uses a frame-based mechanism to define request lengths, making it resistant to classic smuggling when implemented end-to-end. However, if an HTTP/2 front-end downgrades requests to HTTP/1 for back-end communication, the same vulnerabilities can resurface.

Types of HTTP Request Smuggling Attacks

HTTP request smuggling attacks exploit discrepancies in how front-end and back-end servers interpret the Content-Length and Transfer-Encoding headers. There are three primary types:

1. CL.TE (Content-Length to Transfer-Encoding)

2. TE.CL (Transfer-Encoding to Content-Length)

3. TE.TE (Transfer-Encoding to Transfer-Encoding)

How to Perform an HTTP Request Smuggling Attack

Attackers perform HTTP request smuggling by crafting requests that exploit mismatches in header processing. Here’s how the three attack types are executed:

  1. CL.TE (Content-Length to Transfer-Encoding)
    • Setup: Front-end uses Content-Length, back-end uses Transfer-Encoding.
    • Execution: The request includes both headers, with Content-Length set to a value shorter than the chunked body.
    • Example: 
      POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
      • Front-end: Sees a 13-byte request.
      • Back-end: Ends at the 0 chunk, treating SMUGGLED as a new request.
  2. TE.CL (Transfer-Encoding to Content-Length)
    • Setup: Front-end uses Transfer-Encoding, back-end uses Content-Length.
    • Execution: A chunked request includes a small Content-Length.
    • Example: 
      POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
      • Front-end: Processes all chunks.
      • Back-end: Stops after 3 bytes, smuggling SMUGGLED.
  3. TE.TE (Transfer-Encoding to Transfer-Encoding)
    • Setup: Both servers support Transfer-Encoding, but one is tricked by obfuscation.
    • Execution: The attacker manipulates the header (e.g., Transfer-Encoding: chunked ) to exploit parsing differences.

Conditions for Success:

Detection and Exploitation

Detecting Vulnerabilities

  1. Timing Techniques
    • Send a request that causes the back-end to wait for additional data, leading to a noticeable delay.
    • CL.TE Example: 
      POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Transfer-Encoding: chunked
0
X
      • The front-end sends 4 bytes, but the back-end expects more chunks, causing a timeout.
  2. Differential Responses
    • Send an attack request followed by a normal one; observe if the normal response is altered.
    • CL.TE Example: 
      POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Length: 49
Transfer-Encoding: chunked
e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: x
      • The back-end prepends GET /404 to the next request, changing its response.

Exploiting Vulnerabilities

Advanced Techniques