HTTP Request Smuggling

HTTP request smuggling is a method of interfering with how a website processes sequences of HTTP requests sent by one or more users. It is also known as HTTP Desync attack.

Request smuggling vulnerabilities allow an attacker to overcome security controls, obtain unauthorized access to sensitive data, and directly compromise other application users.

HTTP request smuggling vulnerabilities occur because the HTTP specification provides two alternative ways to specify where a request ends: the Transfer-encoding header and the Content-length header.

Transfer-encoding header

Transfer-encoding field indicates the type of encoding that will be used to send the payload body to the user.

The Transfer-encoding header can be used to define chunked encoding for the message content. This indicates that the body of the message contains one or more data chunks.

Each chunk starts with the chunk size in bytes (in hexadecimal), then a newline, and finally the chunk contents. The message ends with a zero-sized chunk. For example:

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

    b
    q=smuggling
    0

    

Content-length header

The Content-length header field specifies the length of the entity-body provided to the recipient in bytes in decimal number of octets. Content length is used when no Transfer encoding is provided in a request. For example:

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

    q=smuggling

    

Impact of HTTP Request Smuggling Vulnerability

According to RFC Specification (2161), if a message has both a Transfer-encoding and a Content-length header field, the latter must be ignored.

Request smuggling attacks occur as a result of the presence of both the Content-length and Transfer-encoding headers in a single HTTP request.

When a request is sent, the front-end server processes the content length and the back-end server processes the transfer-encoding; both servers treat these requests differently.

This causes the request to fail to synchronize, resulting in an unexpected result or error in the response, thereby leading to request smuggling.

The vulnerabilities that are exploited are:

1. CL.TE (Content-length.Transfer-encoding) vulnerabilities

A simple HTTP request smuggling attack with CL.TE (Content-length. Transfer-encoding) vulnerabilities where the Content-length header is used by the front-end server, while the Transfer-encoding header is used by the back-end server can be exploited as in this example.

The attack is carried out as follows:

The Content-length header is processed by the front-end server, which finds that the request body is 13 bytes long, up to the end of SMUGGLED. The back-end server receives this request and processes it.

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

    0

    SMUGGLED


    

The Transfer-encoding header is processed by the backend server, which considers the message body as chunked encoding.

It processes the first chunk, which is claimed to be of zero length, and so considers the request complete. The SMUGGLED bytes are left unprocessed, and the back-end server will treat them as the beginning of the next request in the sequence.

2. TE.CL (Transfer-Encoding.Content-length) vulnerabilities

Consider TE.CL vulnerability where the front-end server uses the Transfer-encoding header and the back-end server uses the Content-length header. The smuggling attack can be performed as follows:

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

    8
    SMUGGLED
    0


    

The Transfer-encoding header is processed by the front-end server, which considers the message body as chunked encoding.

It goes through the first chunk, which is said to be 8 bytes long, up to the beginning of the line after SMUGGLED. It processes the second chunk, which is claimed to be zero in length, and so considers the request complete. The back-end server receives this request and processes it.

The back-end server examines the Content-length header and finds that the request body is 3 bytes long, up to the beginning of line 8. Starting with SMUGGLED, the following bytes are left unprocessed, and the back-end server interprets them as the start of the next request in the sequence.

Cross-site scripting (XSS), unauthenticated access, web cache poisoning, and web cache deception are the vulnerabilities that can be exploited via request smuggling.

How to prevent HTTP request smuggling vulnerability

HTTP request smuggling vulnerabilities occur when a front-end server sends several requests to a back-end server over the same network connection, and the protocol used for the back-end connections puts the two servers in conflict about where requests should be separated.

The vulnerability can be prevented by following the below mitigation techniques:

1. Back-end connections should not be reused, such that each back-end request is made over a distinct network connection.

2. For back-end connections, use HTTP/2, as this protocol eliminates ambiguity about request bounds.

3. Use the same web server software for the front-end and back-end servers to ensure that they agree on request bounds.

Written by

Rejah Rehim

Co-founder, Director