This HTTP Request Smuggling attack can affect different computers and services:
- Web server.
- Firewall.
- Proxy server.
As for the origin, it dates back to the year 2005 in which this attack was demonstrated by a group of Watchfire researchers, among which are Klein, Ronen Heled, Chaim Linhart and Steve Orrin. However, a number of improvements have been made in recent years that expand the attack surface and allow maximum privilege access to internal APIs and cache poisoning.
How this attack occurs
Today’s web applications frequently employ HTTP server strings between users and ultimate application logic. In this way, users send requests to a front-end server, and the front-end server then sends the requests to one or more back-end servers. It should be noted that this architecture is becoming more frequent and in some cases unavoidable, such as cloud-based applications.
When a front-end server forwards HTTP requests to a back-end server, it typically sends multiple requests over the same back-end network connection. This is done because it is more efficient and provides higher performance. The way of acting is simple, first the HTTP requests are sent one after the other. The receiving server then parses the headers of each HTTP request to determine where one request ends and when the next begins.
A very important aspect is that front-end and back-end systems they must be agree on application limits. This is relevant because, otherwise, a cybercriminal could send an ambiguous request to the front-end and back-end systems and they could understand it differently.
Here, the attacker causes part of his front-end request to be interpreted by the back-end server as the start of the next request. What happens then is that it precedes the next request, which causes interference with the way the application processes that request. We would encounter an HTTP Request Smuggling attack and it can have disastrous results for the owner of that server.
Why these attacks occur
A large portion of HTTP Request Smuggling vulnerabilities occur because the HTTP specification provides two different ways to specify where a request ends. A header is simple, it specifies the length of the message body in bytes. This can be used to indicate that the body of the message uses chunk encoding. This means that the body of that message contains one or more pieces of data. Some security administrators are unaware that chunked encryption can be used in HTTP requests and this is a problem.
In case you don’t know, HTTP provides two different methods to determine the length of HTTP messages. It should also be noted that it is possible for a single message to use both methods at the same time, in which case they would conflict with each other. The HTTP protocol attempts to solve this problem by stating that if both the Content-Length and Transfer-Encoding headers are present, then the Content-Length header should not be used. This formula may be enough to avoid ambiguity when we only have one active server, but not when we have two or more servers chained.
Therefore, if the front-end and back-end servers behave differently in relation to a Transfer-Encoding type header that is possibly obfuscated, then they may disagree on the limits between successive requests. This would lead to vulnerabilities and an HTTP Request Smuggling attack.
How to prevent this dangerous attack
HTTP Request Smuggling attacks involve placing both the Content-Length header and the Transfer-Encoding header in the same HTTP request, and then manipulating them so that the front-end and back-end servers process the request differently.
Klein, whom we mentioned earlier, calls for the normalization of outgoing HTTP requests from proxy servers and highlights the need for a robust and open source web application firewall solution that is capable of handling these types of attacks. To solve this problem, Klein has published a C ++-based project that will ensure that all incoming HTTP requests are fully valid, compliant, and unambiguous. This work is published on GitHub and you can check it out here.
On the other hand, some other things we could do to avoid an HTTP Request Smuggling attack would be these:
- Disable reuse of back-end connections, so that each back-end request is sent through a separate network connection.
- Use HTTP / 2 for back-end connections, as this protocol avoids ambiguity in the boundaries between requests.
- The exact same and identical web server software must be used for the front-end and back-end servers. This ensures that they agree on the boundaries between requests.
As you have seen, the HTTP Request Smuggling attack is very important due to its severity, it is quite dangerous, however, we have different ways to prevent this attack and mitigate it correctly.
