What is HTTP Request Smuggling?
Hiding HTTP Request in HTTP Request. That is the main idea. Simple, right?
Well, we can say that HTTP Request Smuggling is a technique to abuse the misconfiguration. An algorithm introduced in reverse proxies or in the back-end servers by not applying the proper RFC standards specifications, to smuggle a whole new HTTP request.
Why?
In order to improve the User’s browsing experience, speed and reduce the burden on the main server, many websites use CDN (Content Delivery Network) like Cloudflare which acts as a reverse proxy and caches the static files, so that they can be loaded instantly without sending a request to the main server.
So, when a user requests a static file, it can be directly loaded from the cache of CDN.
Two different Servers are involved while serving the response to a user’s request.
For example, when we request an HTML webpage, it contains many files like CSS, JavaScript, or images, which are not specific to a particular user, also some user-specific content like user profile details like username, email which is dynamically generated content. A smart CDN grasps this and the static files on its own server are cached. So, when a new user’s request gets to CDN, it serves the static files on its own for dynamic content and then forwards the request to the main back end servers. But here is the fun part, the request forwarded by CDN to the main server, is a modified version of the main user request. The CDN adds some unique headers that help the main server identify the request coming from the CDN.
As these servers are owned by two separate parties, they are bound to be configured differently. So, they will process each HTTP request differently; and that is the main cause behind HTTP smuggling.
HOW?
Before going into “how”, we should get a brief idea about the Content-length and the Transfer-Encoding headers, as these headers are the key elements for this attack.
- Content-length:
Using this specific header, we can define the size of the message (post data) of the HTTP request in bytes.
Syntax
- Transfer-Encoding:
It specifies that the message body is using chunked encoding. Meaning, the message will contain one or more chunks of data.
Syntax
Let’s dive deep into the technicalities, shall we?
As mentioned above, there are two servers involved in handling a user’s HTTP request. So, when a malformed HTTP request comes, both the servers treat that request in different ways. This opens a unique window of opportunity for an attacker.
For example, when an HTTP request is typed in, which has a Content-Length header as well as a Transfer-Encoding header, like the below request, both servers treat it in a different manner.
Now according to the RFC standard, when an HTTP request contains both the CL and TE headers, then the CL header should be ignored. But there are many servers that are not configured according to the RFC. So, by crafting a malicious request and figuring out the server processor of the header, an attacker can smuggle the HTTP request inside the HTTP request.
Umm… seems complicated? Let’s make it simple. Consider the below scenario:
Here we have 2 servers named CDN and main server.
When an HTTP request comes with both the headers, the CDN gives precedence to CL header and the main server gives precedence to TE header.
So, if an attacker sends this request, the CDN will treat the CL headers and will forward the whole request as it is to the main server.
Now the main server will treat only the TE header and will close the TCP link as soon as it receives the terminating chunked. It won’t process the remaining part. So, the highlighted part will be kept hanging in the pipeline.
Pretty Cool huh! But wait. This is just phase 1, the real fun begins now.
Now the smuggled part is hanging in the pipeline and when a new HTTP request comes,
the smuggled part gets directly prepended or prefixed to that request like the below
and the user will receive a response as:
This is the main idea behind HTTP smuggling.
Hope this helps you to understand the core concept of this attack.
Attack Scenario’s?
- CL.TE
This means when a HTTP request containing both the Content-Length and Transfer-Encoding header arrives, the front-end server will process the content-length header and the backend will process the transfer encoding header. And the highlighted part will get smuggled.
- TE.CL
This means when a HTTP request containing both the Content-Length and Transfer-Encoding header arrives, the front-end server will process the Transfer-Encoding header and the backend will process the Content-Length header causing the highlighted part getting smuggled.
TE.TE
This means when a HTTP request containing Transfer-Encoding header comes twice in a request, then one of the headers is obfuscated slightly so that one of the servers can be induced to not process it.
While these are the popular attack scenarios, there are two more scenarios that are rare but can be exploited often.
Hidden Attack Scenario’s
- GET request with CL! = 0
We know that GET requests don’t have a post body, but no such thing is laid out in the RFC standard. It only states that if you send post data along with GET request, then the servers might reject it. But if the server allows such a case due to misconfiguration, then it can be exploited in the wild.
- CL.CL
This is also an interesting case. According to the RFC, if an HTTP request contains 2 Content-Length headers, then the server should give 400 error.
But as we already know, most servers do not implement the specifications strictly. So, the front end will process the first header and the back end will process the second Content-Length header causing the highlighted part to get smuggled.
Exploitation Scenarios?
While giving the PoC for the HTTP Smuggling, we need to show the impact it has. So, we can use the following cases to show the impact of this vulnerability. Let’s not go into the technical details of this exploitation, instead of logic behind those shall interest you. To understand this more deeply you can give a try to PortSwigger’s lab on HTTP Smuggling.
Using HTTP request smuggling to bypass front-end security controls:
Many times, the admin panel is not accessible to normal users. So, if we find the vulnerability, we can use it to hit the admin panel by smuggling requests to the admin endpoint.
Revealing front-end request rewriting
In many applications, the front-end server performs some rewriting of requests before they are forwarded to the back-end server, typically by adding some additional request headers. In places where the POST data is getting reflected, this vulnerability can be used to write the whole request threads.
Capturing other users’ requests
Going one step ahead from the previous scenario, it can be used to reflect authorization specific headers from other users like cookies or tokens.
Using HTTP request smuggling to exploit reflected XSS
If an application is vulnerable to HTTP request smuggling and also contains reflected XSS, you can use a request smuggling attack to hit other users of the application with the reflected XSS.
Using HTTP request smuggling to cause an open redirect
You can use this vulnerability causing site, wide open redirect by smuggling an attacker-controlled domain in the Host header. For reference of this exploitation https://hackerone.com/reports/694604
Using HTTP request smuggling to perform web cache poisoning or web cache deception
If any part of the front-end servers performs caching of the content to improve the speed of content being delivered, then it may be possible to poison the cache with off-site redirect response. Due to which the attack will be persistent, affecting other users who will subsequently request the affected URL and getting served our poisoned caches content. In yet another variant of the attack, you can leverage HTTP request smuggling to perform web cache deception attacks. This works in a similar way to the web cache poisoning attack but with a different purpose.
I tried to simplify the concept of HTTP smuggling as I understood it. I hope this article helps you in some way. If you are getting stuck at some point please feel free to forward any queries to us.
Reference:
1. https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
2. https://i.blackhat.com/USA-19/Wednesday/us-19-Kettle-HTTP-Desync-Attacks-Smashing-Into-The-Cell-Next-Door.pdf
