Keeping up with new vulnerabilities and attack vectors is essential in the always changing world of web application security. Recent years have seen an increase in HTTP Request Smuggling as one such risk. An attacker may modify HTTP requests using this advanced attack method, get around security measures, and potentially risk the integrity and confidentiality of web applications.
In this article, we’ll look at the many attack methods used in HTTP Request Smuggling and analyze the risks they bring to modern web applications.
Refer to the following Blog for additional information on HTTP Request Smuggling Basics.
How are HTTP Request Smuggling Vulnerabilities Identified?
There are two methods we can use to find http request smuggling vulnerabilities.
Differential responses and timing techniques.
• Timing Techniques
Sending requests that will delay the application’s response if a vulnerability exists will usually allow you to quickly identify HTTP request smuggling vulnerabilities. This method is used by Burp Scanner to automatically identify smuggling vulnerabilities.
Using Timing Techniques to Find CL.TE Vulnerabilities
If an application is vulnerable to the CL.TE variant of request smuggling, a request like this will usually result in a delay:
The front-end server will only forward a portion of the request since it uses the ContentLength header, skipping out the N. The Transfer-Encoding header is used in the backend server, and the first chunk and the next chunk are processed. There is a significant delay as a result.
Utilizing Timing Techniques to Find TE.CL Vulnerabilities
Sending a request like the one below will frequently result in a time delay if an application is vulnerable to the TE.CL form of request smuggling:
The front-end server will only forward a part of this request, leaving out the X, because it uses the Transfer-Encoding header. The Content-Length header in the back-end server expects the extra content in the message body and waits for it to arrive. There is a distinct time delay as a result.
Differential Responses
If you detect a potential request smuggling vulnerability, you can use it to their gain to trigger variations in the contents of the application’s responses and obtain additional information of the vulnerability. You can execute this by immediately sending the application two requests:
An “attack” requeST attempts to delay the processing of the subsequent request.
A “normal” request.
If the response to the normal request contains the expected impact, the vulnerability is confirmed.
Consider this standard request as an illustrative example:
The typical response to the request is an HTTP response with a status code of 200 that contains some search results.
A particular attack request, such as CL.TE or TE, is needed to obstruct this request.
The type of request smuggling present determines CL.
Attack Scenarios of Smuggled HTTP Requests.
Utilizing HTTP Request Smuggling for Front-end Security Measures
Some applications implement security measures by determining whether to approve or reject specific requests on the front-end web server. Requests that have been forwarded are delivered to the back-end server, where they are acknowledged as have being processed by the front-end controls.
Consider an application that forwards requests only if the user has permission to view the URL and implements access control controls using the front-end server. All requests are accepted by back-end servers without additional review. In this case, submitting a request to a restricted URL can be used to get around the access restrictions due to a vulnerability in HTTP request smuggling.
The current user may access /search but not /admin. A request smuggling attack like the one below can get around this restriction:
Two requests for /search are seen by the front-end server in this example, and as a result, the requests are sent to the back-end server. There is just one request for /search and one for /admin, according to the back-end \server. As always, it assumes that the requests have successfully navigated the front-end controls and been granted access to the restricted URI.
Taking Requests from Other Users
If the application allows textual data to be stored and retrieved, HTTP smuggling can be used to intercept the requests of other users. They may consist of session tokens, tools for preventing session hijacking attacks, or other private information provided by the user.
You must smuggle a request that sends data to the storage function, with the parameter containing the data placed last in the request, in order to carry out the attack. As a result, the succeeding request handled by the back-end server will be added to the previous request, storing the original request made by the other user.
The following requests for blog post comments will be processed, and the applicant’s comment will be saved and posted on the blog:
You can use the following request smuggling exploit to smuggle the data storage request to the back-end server:
The smuggled request will be processed along with another user’s request through the back-end server, resulting in the storage of the victim user’s request and its session cookie.
Then, by retrieving the stored data in the typical manner, you can obtain the details of the other user’s request.
Bypassing Client-Side Authentication
Using certificates, servers authenticate with clients (often browsers) during the TLS handshake. Common names (CN) in certificates should correspond to the hosted domain names. This can be used by the client to confirm they are communicating with an authorised domain server.
Extra mile websites use mutual TLS authentication, which requires that the client also provide the server with a certificate. In the back-end application logic, for instance, CN is frequently used as a login or some similar access control method.
The component that authenticates the client typically provides one or more nonstandard HTTP headers to the application or backend server. For instance, front-end servers occasionally add the following header to all incoming requests:
Because these headers are intended to be hidden from users, back-end servers often implicitly trust them. If you submit the correct set of headers and values, you might be able to get around access controls.
Since front-end servers often replace these headers if they already exist, this behaviour is typically not exploitable. All headers in smuggled requests are forwarded to the back end unchanged because they are completely hidden from the front end.
Exploiting Reflected XSS by Using HTTP Request Smuggling
On an application that contains both reflected XSS and HTTP request smuggling, you can use an HTTP request smuggling attack to target other application users. It differs from typical reflected XSS exploitation in two ways:
It doesn’t require for victim engagement. Giving them a URL to visit is not necessary. You only need to send a request with the XSS payload, and the following request that the backend server processes will be affected.
This can be used to take advantage of XSS behavior in request components such
HTTP request headers that are difficult to manage in a typical reflected XSS attack. Think about an application that has a User-Agent header mirrored XSS vulnerability. You can use this in a request smuggling attack by doing the following:
The smuggled request will therefore be combined with the next user’s request, and the reflected payload will be returned.
Converting an On-site Redirect into an Open Redirect Using HTTP Request Smuggling
The host name from the request’s Host header is often included in the redirect URL when performing on-site redirects from one URL to another. When a request for a folder without a following slash is made, the Apache and IIS web servers by default forward the request to the same folder with the trailing slash:
Normally, this behavior is regarded as harmless, but it can be used in a request smuggling attack to lead other users to an outside site. For instance:
The next user’s request will be affected by the redirect if the previous request causes one to the attacker’s website. For instance:
A website page imported the JavaScript file that the user was requested. The attacker can completely compromise the target by sending back their own JavaScript in the response.
Web Cache Poisoning Using HTTP Request Smuggling
If any component of the front-end architecture caches the content, a poisoned cache could impact the server’s response.
When the poisoned request requests /static/include.js, the server can respond with the contents of /index.html. When the client caches the contents of /index.html, this will prevent the client from accessing /static/include.js.
If you discover an Open Redirect or some on-site redirect to an Open Redirect, the scenario becomes much more curious. Considering that you may change the cache values in /static/include.js to ones set by a script you have authority on.
This example shows how to use a cache poisoning + on-site redirect to open redirect to change the /static/include.js cache’s contents and serve attacker-controlled JS code:
Take note of the embedded request’s /post/next request? postId=3 The URL for this request will be changed to /post?postId=4. and will identify the domain using the Host header’s value. In this case, you would alter the Host header to direct traffic to the attacker’s server and utilise the attacker’s domain in the redirect (on-site redirect to open redirect).
You must make a GET request to /static/include.js once the socket has been poisoned. The on-site redirect will poison this, causing it to open a redirect request and obtain the script’s contents from the attacker.
The server will deliver the attacker’s script’s cached content if you request /static/include.js.
How to Prevent Vulnerabilities Caused by Smuggled HTTP Requests
The ambiguities in server protocol interpretation and configuration are taken advantage of by a sophisticated HTTP smuggling attack.
IT professionals have a few options to choose from in order to decrease their risk to this security vulnerabilities:
On front-end and back-end servers, consistently interpret HTTP headers is the best solution for prevention. However, because load balancers are typically hardware appliances that handle backend servers running on several platforms, it is not always a choice. At the very least, you should be aware of how each server handles HTTP headers and make sure they consistently interpret HTTP requests if you are unable to run the same software on both the front-end and the back end.
Disable vulnerable performance enhancements—if you are unable to update the backend configuration, turn off any enhancements that make use of the Transfer Encoding or Content-Length headers. Although it may decrease the effectiveness of the online environment, this is a very effective way to stop this attack.
If they are not required for your configuration, load balancers, content delivery networks (CDNs), and reverse proxies should not be used.
Use HTTP/2 to ensure that only HTTP/2 is used for communication between the front-end and back-end servers to thwart the majority of this attack’s variations.
If connection reuse is possible in your environment, disable it on the back-end server. This will completely stop HTTP request smuggling.
Before delivering ambiguous queries to the back-end server, the front-end server should be configured to normalize them.
Avoid making logged HTTP traffic available to consumers since doing so could reveal undesired components of an HTTP request to attackers.
Use a web application firewall (WAF); the majority of WAFs have technology that can recognize and filter out HTTP traffic, such as requests for smuggling directives, before blocking or allowing it through. Users of WAFs should check with the vendor to make sure the degree of security has been turned on. It’s critical to determine whether any WAF configuration changes are required to protect against an HTTP request smuggling vulnerability.
Conclusion
Due to compatibility issues between front end and back-end servers, HTTP request smuggling has returned in the online world. Therefore, we can effectively prevent http request smuggling if we combine all the prevention strategies, which include using HTTP2, using a firewall, and disabling reuse on the back-end server. Rest assured that we will always be updating and upgrading our server with the most recent security techniques!
Contributor: Prajyot Chemburkar
