HTTP Request Smuggling is often left behind in bug bounty findings. But with the right extension, you can automate the task of finding HTTP request smuggling in your next bug bounty program.

Modern websites often deploy multiple proxy servers to forward the user request to the actual server which hosts the web application. These front-end or proxy servers with the actual back-end server are most common architecture in cloud applications.

The front-end server gets the requests from multiple users and forwards them to the back-end servers. These two servers must agree on the boundaries between the two different user requests. Sometimes these servers do not agree on the boundaries and an attacker can exploit this by modifying the HTTP request to cause HTTP Request Smuggling.

when front-end and back-end server does not agree on the boundary between user requests, HTTP Request Smuggling arises.

Boundaries (i.e) the end of the HTTP Request is defined by the “Content-Length” or “Transfer-Encoding” HTTP header. Some servers do not support “Transfer-Encoding” and some servers take the “Content-Length” header as the default one if both are present in the request. If the front-end and back-end servers of the application are not configured properly, they will take different boundary values, leading to a request smuggling vulnerability.

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Content-Length: 4

A Sample request with both header present.

An attacker can include both the headers with different values for a boundary in the HTTP request. If the front-end server accepts the “Transfer-Encoding” while the back-end server accepts the “Content-Length” header, it will lead to contamination in the request processing as the boundary value is different in each header. This can also happen vice-versa, where the front-end server accepts “Content-length” and the back-end server accepts “Transfer-Encoding”. The former is called TE.CL and the latter is CL.TE HTTP request smuggling vulnerability.

This ambiguous processing by the front-end and back-end server leads to HTTP Request Smuggling. It could lead to gaining unauthorized data, compromising applications, and more.

I could talk about this vulnerability more but that’s not the intention of this post.

Before automating the task using burp extension, let’s see how to detect it manually, so you can understand more about this vulnerability.

You just have to send a modified HTTP request with both Content-Length and Transfer-Encoding Header. The server will take more time than normal to request this contaminated request. If there is a time delay, then you have got yourself an HTTP request smuggling vulnerability.

Example Request:

POST / HTTP/1.1Host: vulnerable-website.comTransfer-Encoding: chunkedContent-Length: 40Y

If the front-end server only accepts Transfer-Encoding Header, then it will omit everything after ‘0’ and sends the above request without ‘Y’ to the back-end server.

If the back-end server only uses the Content-Length header, then it will take the length of the request as only 4. But the actual length of the request is less than 4 as the front-end server has omitted some data. So the back-end server will wait for some time to receive the remaining data. This will cause time delay, thus the detection of Request Smuggling Vulnerability.

You can modify the same request to find a vulnerability with the front-end server using Content length and the back-end server using the Transfer-Encoding header.

HTTP Request Smuggler

The HTTP Request Smuggler is a burp extension that helps you to automate the above manual task in finding this vulnerability. Manually finding this vulnerability is possible but highly tedious, so you can leverage this existing extension in burp to find it.

After installing the extension, you can start using it right away. Right-click on an intercepted request on Burp Proxy and click HTTP Request Smuggler -> Smuggle Probe. It will then automatically modify the intercepted request and send it to find the vulnerability. It sends many modified request to check for both the types of this vulnerability — CL.TE & TE.CL. If there are any findings related to this, you will find them on the scan issues activity page.

Default Burp Suite Active Scan

If you Active Scan a target, the Burp Suite will actually look for HTTP Request Smuggling. You can check for this in the Active Scan configuration of your Burp Suite. It will also report the finding on the issue activity page after completing the Active scan. Just do not leave it if you encounter this issue. Work on it and confirm this vulnerability by the HTTP Request Smuggler extension.

HTTP Request Smuggling is a severe vulnerability that is often overlooked. I have actually found a bug on a real system using the Active Scan and Request Smuggler extension. Hope this post gave you an idea about this vulnerability and how to detect it. If you want to learn more about this vulnerability, you can take a look at the Port Swigger website, which has a detailed explanation about it.

Pro Tip: You can clap up to 50 times a post to show how much you have liked it.