HTTP Request Smuggling: A Primer

Published in

ShiftLeft Blog

5 min readSep 8, 2020

One of the security issues you might face with your website or web app is request smuggling.

HTTP request smuggling is a security vulnerability that allows an attacker to interfere with the way a server processes the HTTP requests it receives. It allows attackers to bypass security controls and gain access to data that they shouldn’t have access to.

In this article, we will cover:

How someone can engage in HTTP request smuggling
How you can protect yourself and minimize the likelihood that an attacker can engage in this type of attack against you

Background: Server Infrastructure for Websites and Applications

Before we talk more about HTTP request smuggling, let’s take a look at a typical server infrastructure for modern websites and applications:

The end-user sends requests to a front-end server
The front-end server forwards the requests to back-end servers; this utilizes the concepts of keep-alive and pipelining and is typically done by sending multiple requests using the same network connection to improve efficiency and performance
The back-end servers process the requests; to distinguish one request from another, the server parses the HTTP request headers to determine where one request end and where the next begins

As you can see, the front- and back-end servers need to agree on where the start and the end of requests are, otherwise parts of one message may be mistakenly included with another request (and where the term request smuggling comes from).

How Servers Understand Where Requests Start and End

HTTP request smuggling works by using the headers of the request to “trick” the server into misinterpreting where a request ends. The HTTP specification provides you with two ways to specify where a request ends:

The Content-Length header
The Transfer-Encoding header

The Content-Length Header

The Content-Length header allows you to specify the length of the message body in bytes:

POST / HTTP/1.1Host: shiftleft.ioContent-Type: application/x-www-form-urlencodedContent-Length: 23

The Transfer-Encoding Header

The Transfer-Encoding header lets you specify that your message body utilizes chunked encoding (or that the message body contains one or more data chunks). They include the following:

The chunk size in bytes
A newline
The contents of the chunk

To indicate the end of a message, you would include a chunk of zero bytes.

POST / HTTP/1.1Host: shiftleft.ioContent-Type: application/x-www-form-urlencodedTransfer-Encoding: chunked14\r\nHelloShiftLeft\r\n0\r\n\r\n

The Use of Two Methods to Specify the Length of an HTTP Message

The HTTP specification allows the use of both the Content-Length and the Transfer-Encoding headers, which means that an attacker could include both methods in a single message, making sure that the information contained in the two headers contradict one another.

Though the HTTP specification states that the Content-Length header should be ignored in favor of the Transfer-Encoding header if both are present, there can still be ambiguity, especially if multiple servers are handling requests.

More specifically, depending on how the front-end server and the back-end server handle such a request, there may be conflict in interpreting where the message ends and the next one starts, leading to the possibility of smuggling and hence security vulnerabilities.

Performing an HTTP Request Smuggling Attack

To perform an HTTP request smuggling attack, the malicious party needs to send both the Content-Length header and the Transfer-Encoding header in a single request, making sure that the request is handled differently by the front- and back-end servers.

As you can see, implementing a successful attack does require that the attacker knows how the individual servers operate.

HTTP Request Smuggling Attack Example #1

Let’s take a look at what happens when the front-end server uses the Transfer-Encoding header and the back-end uses the Content-Length header.

Our request is as follows:

POST / HTTP/1.1Host: shiftleft.ioContent-Length: 2Transfer-Encoding: chunked23UnauthorizedInformation0

This is what happens when the two servers process the request:

The front-end server, using the Transfer-Encoding header, processes the first chunk (which is UnauthorizedInformation) because it was told the chunk is 23 characters long
The front-end server then processes the next chunk, which is 0; it then terminates the request and forwards everything to the back-end server
The back-end server, which is using the Content-Length header, sees that the body is only 2 bytes long; as such, it only processes the first two bytes, ignoring the subsequent information and including it with the following request it handles

HTTP Request Smuggling Attack Example #2

Let’s take a look at the reverse situation, where the front-end server uses the Content-Length header and the back-end uses the Transfer-Encoding header. We can send a request that looks like:

POST / HTTP/1.1Host: example.comContent-Length: 24Transfer-Encoding: chunked0UnauthorizedInformation

Regarding this request:

The front-end server, using the Content-Length header, acts as if the body is 24 characters long
The back-end server, however, uses the Transfer-Encoding header and sees that the message body is chunked encoded. It processes the first chunk (which you can see from the sample above is size zero) and terminates the request without processing the UnauthorizedInformation portion. This information is then included as part of the next request that it handles

HTTP Request Smuggling Attack Example #3

One final example that we’ll go over involves both the front- and the back-end using Transfer-Encoding header. Depending on how it is used and how the attacker chooses to deviate from what is called for by the HTTP specification, you can find some variation so that one of the servers ignores it:

Transfer-Encoding: chunkedTransfer-Encoding: xchunkedTransfer-Encoding: chunked #note the space at the beginning of the header

The variations on how to pass in the Transfer-Encoding header possible are endless, but depending on which server is the one not processing the header appropriately, you’ll see behavior similar to one of the examples mentioned above.

How to Protect Against HTTP Request Smuggling Vulnerabilities

In short, HTTP request smuggling vulnerabilities are a possibility if:

The front-end server forwards two or more requests to back-end servers over the same network connection (remember, this is done in the name of performance and efficiency)
The protocol for the back-end connection means that it’s possible the front- and back-end servers disagree about how a specific request should be handled

So, what can you do to prevent these issues? Well, you can:

Require the use of the HTTP/2 protocol (especially on the back-end) to prevent ambiguity about where a request starts and ends; the Transfer-Encoding header (available in HTTP 1.1 only; it is unsupported by HTTP/2
Require separate connections for each request (though this may have a negative impact on performance)
Use the same web server for both front- and back-end servers so that they interpret requests identically, reducing ambiguity about where a message starts/ends

Conclusion

HTTP smuggling attacks are a way for malicious parties to influence the behavior of your servers by selectively altering requests that your server handles. This can be as simple as requesting information to which they shouldn’t have access, but it can also be used to force redirects, change hostnames, and more. Protecting yourself is a fairly simple process, even if there are some trade-offs to be had.