When you can trick the front and the back of your application causing it to behave unexpectedly.
Vulnerability, that could allow malicious actors to leverage specific features of the HTTP/1.1 protocol in order to bypass security protections and obtain sensitive information from requests other than their own.
The HTTP request smuggling vulnerability was first discovered by Watchfire in their 2005 whitepaper entitled “HTTP Request Smuggling”. Then the work was later expanded by researcher Regis Leroy which was further discussed by James Kettle from Portswigger security during BlackHat USA 2019.
Some Important Terms
Before diving into what HTTP Request Smuggling is and how it operates, there are some important terms we need to know. I have listed some here.
- Keep-Alive Header: By default, HTTP connections closes after each request. That means when someone visits your site, the browser needs to create new connections to request each of the files that make makes up the web pages. The HTTP keep-alive header maintains a connection between a client and your server, reducing the time needed to load the files.
- Pipelining: This feature allows a web server to process requests asynchronously rather than processing each request individually. It sends a request without waiting for a previous response to arrive.
- Content-Length and Transfer-Encoding Header: These headers are used for message framing, informing a server where a message ends and another begins. The content-length header indicates the size of the entity-body of the request which is commonly seen in the HTTP Post request. Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
What is Request Smuggling?
Most of the modern web stack consists of multiple web servers along with load balancers.
HTTP Request Smuggling is a type of attack where malicious actor abuses how two HTTP devices send requests between each other by modifying a request to include two requests within the body of a singular request. This informs the server where the request ends by modifying the Content-Length and Transfer-Encoding header.
How does it occur?
Whenever the front end server sends an HTTP request to the backend server to make it more efficient, it sends several requests over the same back-end network connection. The 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 one begins.
This is where malicious actor, causes part of the front-end request to be interpreted by the backend server as the start of the next request. Effectively, prepended to the next request, and so can interfere with the way the application processes that request. And this how the HTTP Request Smuggling attack occurs.
Most of the HTTP specification provides two different ways to specify where a request ends. They are Content-Length and Transfer-Encoding header. Because of there two methods, it is possible for a single message to use both methods at once, such that they conflict with each other. However, we need to keep in mind that some servers do not support the transport-encoding header. While some do not do support the transfer-encoding header can be induced not to process it if the header is obfuscated in some way.
Some Attack Techniques
There are several different attack methods using HTTP Request Smuggling. Among them, some of them are Cross-Site Scripting (XSS). In this kind of attack, the attacker does not target the specific user but targets any users of the application.
There are also different types of Request Smuggling, which are:
TE: TE- Both the frontend and the backend servers support the Transfer-Encoding header.
CL: TE- Here, the frontend supports content-length whereas, the backend supports transfer-encoding header
TE: CL — The frontend supports transfer-encoding header while the backend supports content-length
CL: CL- Double content length attack technique
TE: TE — Both the back and the frontend supports transfer-encoding header.
In this article, I will demonstrate two of the attack techniques- CL: CL &CL: TE
- CL: CL ( Double Content-Length)
GET / HTTP/1.1
Host: example.comGET /reqexample HTTP/1.1
In the above request, you can see that two content-length headers are sent to a target that has a proxy or a load balancer as a frontend. The proxy will prioritize the first one and view the smuggled request as part of the request body. However, the GET method shouldn’t have a request body but here two Content-Length headers have been provided. Now, this is processed by the backend processes the second Content-Length header ignoring the first content-length header.
Since the second Content-Length has the value zero, the backend will expect no request body, and the /reqexample request is treated as another pipelined request. As a result, the response of this smuggled request could be received by another user.
2. CL: TE ( Content-Length: Transfer-Encoding)
POST /login HTTP/1.1
0GET /404 HTTP/1.1
When the above request gets processed by proxies, the content-length header will be prioritized rather than the transfer-encoding header. However, the backend prioritizes just the opposite which is the transfer-encoding header. And, the backend will process the request ending at character 0. As a result, the 404 GET request gets treated as a separate pipelined request.
Some ways to remediate HTTP Request Smuggling
- Make sure that the same server software is used on both the front and back end servers so they agree on which header they will use will prevent the conflicts.
- Disable reuse of backend connections. Ensure that each back-end request is sent over a separate network connection.
- Use HTTP/2 for back-end connections, since the protocol prevents ambiguity about the boundaries between requests.
- Prioritize Transfer-Encoding header over a content-length header by both backend and frontend.
- Disallow requests that consist of both Content-length and Transfer encoding or double Content-Length headers.