Practice
Modern web applications often use chains of HTTP servers between users and the application's back-end logic. Users send requests to a front-end server (sometimes called a load balancer or reverse proxy), and this server forwards requests to one or more back-end servers. This type of architecture is becoming increasingly common, and in some cases unavoidable, in modern cloud-based applications.
When the front-end server forwards HTTP requests to a back-end server, it typically sends several requests over the same back-end network connection, since this is far more efficient. The protocol is very simple: HTTP requests are sent one after another, and the receiving server parses the HTTP request headers to determine where one request ends and the next begins:
In this situation, it is critically important that the front-end and back-end systems agree on the boundaries between requests. Otherwise, an attacker can send an ambiguous request that is interpreted differently by the front-end and back-end systems:
Here, the attacker causes part of their front-end request to be interpreted by the back-end server as the beginning of the next request. It is effectively prepended to the next request and can interfere with the way the application processes that request. This is a request smuggling attack, and it can have devastating consequences.
Most HTTP request smuggling vulnerabilities arise because the HTTP specification provides two different ways to specify where a request ends: the
header and the
header.
The header is straightforward: it specifies the length of the message body in bytes. For example:
The header can be used to indicate that the message body uses chunked encoding. This means the message body contains one or more chunks of data. Each chunk consists of the chunk size in bytes (expressed in hexadecimal), followed by a newline, followed by the chunk's contents. The message ends with a zero-size chunk. For example:
Many security testers are unaware that chunked encoding can be used in HTTP requests, for two reasons:
Since the HTTP specification provides two different methods for specifying the length of HTTP messages, it is possible for a single message to use both methods at once, so that they conflict with each other. The HTTP specification attempts to prevent this problem by stating that, if both the
and
headers are present, then the
header must be ignored. This may be sufficient to avoid ambiguity when only one server is involved, but not when two or more servers are chained together. In this situation, problems can arise for two reasons:
If the front-end and back-end servers behave differently with respect to a (possibly obfuscated)
header, then they may disagree about the boundaries between successive requests, leading to request smuggling vulnerabilities.
Request smuggling attacks involve placing both a
header and a
header in a single HTTP request and manipulating them so that the front-end and back-end servers process the request differently. The precise way this is done depends on the behavior of the two servers:
Here, the front-end server uses the
header, and the back-end server uses the
header. We can perform a simple HTTP request smuggling attack as follows:
The front-end server processes the
header and determines that the request body is 13 bytes long, up to the end of
. This request is forwarded on to the back-end server.
The back-end server processes the
header and processes the message body using chunked encoding. It processes the first chunk, which is stated to be zero length, and so is treated as terminating the request. The following bytes,
are left unprocessed, and the back-end server will treat them as the start of the next request in the sequence.
Here, the front-end server uses the
header, and the back-end server uses the
header. We can perform a simple HTTP request smuggling attack as follows:
To send this request using Burp Repeater, you first need to go to the Repeater menu and make sure the "Update Content-Length" option is unchecked.
You must include the trailing sequence
after the final
.
The front-end server processes the
header and processes the message body using chunked encoding. It processes the first chunk, of length 8 bytes, up to the start of the next line,
. It processes the second chunk, which is stated to be zero length, and so is treated as terminating the request. This request is forwarded on to the back-end server.
The back-end server processes the
header and determines that the request body is 3 bytes long, up to the start of the next line,
. The following bytes, starting with
, are left unprocessed, and the back-end server will treat them as the start of the next request in the sequence.
Here, both the front-end and back-end servers support the
header, but one of the servers can be induced not to process it by obfuscating the header in some way.
There are potentially unlimited ways to obfuscate the
header. For example:
Each of these techniques involves a subtle departure from the HTTP specification. Real code implementing the protocol specification rarely adheres to it with absolute precision, and it is typical for different implementations to tolerate different deviations from the spec. To detect a TE.TE vulnerability, you need to find some variant of the
header that is processed by only one of the front-end or back-end servers, while the other ignores it.
Depending on whether it is the
front-end or back-end server that may fail to process the disguised header, the remainder of the attack takes the same form as for the already-described CL.TE or TE.CL vulnerabilities.
HTTP request smuggling vulnerabilities arise in cases where a front-end server forwards multiple requests to a back-end server over the same network connection, and the protocol used for the back-end connections carries the risk that the two servers will disagree about the boundaries between requests. Below are some general ways to prevent HTTP request smuggling vulnerabilities from arising.
In some cases, vulnerabilities can be avoided by making the front-end server normalize ambiguous requests, or by making the back-end server reject ambiguous requests and close the network connection. However, these approaches are potentially more error-prone than the general mitigations listed above.
Comments