HTTP request smuggling is increasingly exploited by hackers in the wild and in bug bounty programs. This post will explain the HTTP request smuggling attack with remediation tips.
What is HTTP request smuggling?
HTTP request smuggling is an attack technique that abuses how two HTTP devices send requests between each other (typically a front-end proxy or a HTTP-enabled firewall and a backend server) or chaining multiple servers together with different configurations.
The attacker is able to modify a request to include two requests within the body of a singular request by telling the server where the request ends by modifying the Content-Length, or Transfer-Encoding header. By abusing these headers, an additional request can be smuggled into the first, leading to the response of the smuggled request being attached to the response of another request.
How is this caused?
HTTP specification allows a server to specify if the request has completed by using two different methods. Using Content-Length or Transfer-Encoding: chunked
The Content-Length header specifies the total size of the request body in bytes, whereas Transfer-Encoding: chunked specifies that the request body will be sent in chunks separated by newline sequences, with each chunk preceded by its size in bytes. The request body ends with a 0-length chunk.
Sending both of these headers in the same request is where the conflict can occur.
Example of how this could be used
An attacker trying to access the admin page of a website which is normally blocked by a front-end server or Web Application Firewall.
example.com/admin
Requesting example.com will result in a 200 response from the server, but when requesting example.com/admin, the server responds with a 403 Forbidden response. The request would look similar to this:
POST /admin HTTP/1.1Host: example.comConnection: Keep-AliveContent-Type: application/x-www-form-urlencodedContent-Length :11
q=givemezepasswords
The front end server which received the request accepts that the request ends with the Content-Length of 11. The front end accepts the request and the Content Security Policy or Web Application Firewall that blocks the request and returns a 403.
If we modify the request to include a smuggled request, we would insert both of the Content-Length and Transfer-Encoding headers, making sure that we include the smuggled request.
POST /admin HTTP/1.1
Host: example.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length :11
Transfer-Encoding: chunked
7POST /admin HTTP/1.1
Host: foo.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length :11
Transfer-Encoding: chunked
q=givemezepasswords
0
Sending this request multiple times will cause the request to go through, with the front end interpreting the first header of Content-Length, with the back end using the Transfer-Encoding header.
This will cause the secondary request to be attached to the response of another request. Being able to see this is dependent on the amount of requests that are being sent backwards and forwards to the server. The two headers can be used interchangeably depending on the server configurations. You can use burp turbo intruder to test and see this in action.
What’s the impact?
By smuggling an additional request into one , you can bypass security controls that are in place and potentially access/modify how the back end will send a response to another request/user. This can be used from anything to fetch etc/passwd, send redirection links, or even takeover accounts which was shown on Slack.
How can I detect it?
There are numerous manual tools that have been made for testing Request Smuggling vulnerabilities, such as Burp Suite’s smuggler extension or Gwendal Le Coguic’s smuggler py.
Detectify can also help. You can test for this directly within Detectify by activating this beta feature within your scan profile settings. The findings will show you where in the application it was found, and provide remediation tips to prevent future HTTP request smuggling attempts.
How can you remediate it?
- Ensure the same server software is used on both the front and back end servers so they agree which header they will use will prevent the conflicts (either Content-Length or Transfer Encoding: chunked).
- Some WAF providers already have built-in mitigation when they detect abnormal requests. Check with your provider if they have support for this
- Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection.
Special thanks to:
More on web browser security and secure headers:
Detectify checks whether your web applications are vulnerable to HTTP request smuggling and other common attacks. Sign up for Detectify with a free trial today and check for 2000+ common vulnerabilities beyond the OWASP Top 10.