Contents:
Introduction
Background Concept of Request Smuggling
Types of Request Smuggling
Identification of HTTP Request Smuggling
Mitigation for Request Smuggling
Conclusion
References
Introduction:
HTTP Request Smuggling is one of the critical web application vulnerabilities that often go unnoticed by many security researchers and penetration testers due to its complexity. HTTP request smuggling is a technique for interfering with the way a website processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users.
Background Concept of Request Smuggling:
Modern Web Applications use multiple web servers to separate users’ HTTP requests and carry out the application’s logic. Users send requests to a front-end like Load Balancer and this server forwards requests to one or more back-end servers. The front end server receives requests from the user end and forwards the request to one or more backend servers one after another and the receiving server parses the HTTP request headers to determine where one request ends and the next one begins.
If the front and backend servers didn’t check the boundary between requests coming from the user end, it might be possible for an attacker to send a malicious request that would be parsed differently by front and backend servers.
Here the attacker causes part of the front end request to be interpreted as the start of the next request by the backend server. This would result in changing the application’s logic.
HTTP request smuggling exists because HTTP specification provides 2 types of Headers to specify where the request ends
- Content-Length Header
- Transfer-Encoding Header
Content-Length header specifies the length of the message body in bytes. Transfer-Encoding header specifies the message body uses chunked encoding, which means the message body contains one or more chunks of data.
Types of Request Smuggling
Request smuggling attacks rely on placing content-length and Transfer-Encoding headers in the HTTP requests and modifying them to make the request parsed differently by the front and backend server. Based on this, we can classify request smuggling into 3 types,
- CL-TE – In this type, the front end uses Content-Length and the backend uses Transfer-Encoding header.
- TE-CL – In this type, the front end uses a Transfer-Encoding header and the backend uses a Content-Length header.
- TE.TE – Both front and backend server uses Transfer-Encoding header. By obfuscating one of the headers we can induce one of the servers to not use the TE header.
Identification of HTTP Request Smuggling
We have used a test webserver to demonstrate the identification of HTTP request smuggling vulnerabilities.
1. CL-TE Request Smuggling Detection:
In CL-TE type of Reqest smuggling, the front end server uses content-length and the backend server uses Transfer-Encoding headers to specify HTTP message body.
.png)
In the above example, the front end server processes the Content-Length header and determines the request message is 10 bytes and process up to the value G in the request body.
The backend server processes the Transfer-Encoding header and checks the message body chunks which ends with value 0 and terminate the request. The following byte G is unprocessed and the backend server will treat that as the start of the next request in the sequence. Because of this, we are getting an error saying unknown method GPOST as shown in the above image.
2. TE-CL Request Smuggling Detection:
In TE-CL type of Request smuggling, the front end server uses Transfer-Encoding header and the backend server uses Content-Length headers to specify HTTP message body.
.png)
In this example, the front end server of the application processes the Transfer-Encoding header and treats the message of the HTTP request as chunks. It processes the first chunk which gives the length of the body in bytes, in this example it is 5c (92 bytes). The server processes the 92 bytes data chunks to value 0 and terminates the request.
The backend server processes the Content-Length header and finds that the request is 4 bytes long as mentioned in the header. Hence the 4 bytes of the message body is processed till 5c and the remaining data are left unprocessed. This unprocessed data will be considered as the start of the next request sequence by the backend server.
Note: In the burp suite repeater tab, uncheck auto-update content-length header to avoid content-length header value changes to successfully test for TE-CL based request smuggling attacks.
3. TE-TE Request Smuggling Detection:
In this method, both the front end and backend servers use Transfer-Encoding to process the http message body. It is possible to induce one of the servers to not process the data using Transfer-Encoding to carry out request smuggling.
Below are some examples of obfuscating Transfer-Encoding headers to induce one of the servers to not process the message body.
Transfer-Encoding: xchunked
Transfer-encoding : cow
Transfer-Encoding: x
Transfer-Encoding: chunked
.png)
In this example, we have obfuscated one of the Transfer-Encoding headers to induce one of the servers not to process it. Due to this, only one of the servers is going to process the remaining Transfer-Encoding header and the rest of the attack will be the same as TE.CL or CL.TE method.
Mitigations for HTTP Request Smuggling
- Configure the front-end request to normalize any ambiguous request data in the HTTP message body.
- Configure backend server to reject remaining HTTP data that are left unprocessed. This will enable the server to close the TCP connection instead of processing the data at the start of the next request.
- Deploy web application firewall for both front and backend servers or load balancers.
- Use HTTP/2 protocol which uses a strict mechanism to determine the length of the request end to end which will avoid request smuggling attacks.
Conclusion
HTTP request smuggling vulnerabilities can be complex to identify due to the nature of the attack, but it may help an attacker to compromise the request flow of the application. It is recommended that organizations should carry out application security assessments to identify and rectify these kinds of vulnerabilities.
