What Is HTTP Request Smuggling?
HTTP request smuggling exploits the inconsistency in parsing non-RFC-compliant HTTP requests via two HTTP devices (generally a backend server and HTTP-enabled firewall or a front-end proxy). The HTTP request smuggling process is carried out by creating multiple, customized HTTP requests that make two target entities see two distinct series of requests.
The HTTP header offers two distinct ways of specifying where the request ends: the Transfer-Encoding header and the Content-Length header. An HTTP request smuggling vulnerability occurs when an attacker sends both headers in a single request. This can cause either the front-end or the back-end server to incorrectly interpret the request, passing through a malicious HTTP query.
Request smuggling vulnerabilities let cybercriminals side-step security measures, attain access to sensitive information, and directly compromise various application users. It can also be used for secondary exploits, including bypassing firewalls, partial cache poisoning, and cross-site scripting (XSS).
How HTTP request smuggling works
What Is the Impact of HTTP Request Smuggling Attacks?
When an attacker succeeds in performing a request smuggling attack, they inject a malicious HTTP request into the web server, bypassing internal security controls. This can allow the attacker to:
- Gain access to protected resources, such as admin consoles
- Gain access to sensitive data
- Hijack sessions of web users
- Launch cross-site scripting (XSS) attacks without requiring any action from the user
- Perform credential hijacking
HTTP Request Smuggling Examples
Most HTTP request smuggling attacks exploit a content length (CL) weakness, a transfer encoding (TE) weakness, or both. The three main attack techniques are known as “CL.TE”, meaning the attack exploits content length on the front end and then transfer encoding on the back end, “TE.CL” for the opposite, and “TE.TE” for a double exploitation of transfer encoding, on both front and back end.
CL.TE (Content-Length.Transfer-Encoding) Vulnerabilities
A CL.TE HTTP request smuggling attack assumes that the front-end server prioritizes the Content-Length header, while the back-end server prioritizes the Transfer-Encoding header.
The attack is performed as follows. The first part of a request declares a short chunk length, typically 0. The front-end server reads only the first part of the request and passes the second part to the back-end server.
In the following example, the text starting with “MALICIOUS REQUEST” is passed through to the back end server, which treats it as the next request, and processes it.
POST / HTTP/1.1 Host: website.com Content-Length: 13 Transfer-Encoding: chunked 0 MALICIOUS-REQUEST
TE.CL (Transfer-Encoding.Content-Length) Vulnerabilities
A TE.CL HTTP request smuggling attack assumes that the front-end server prioritizes the Transfer-Encoding weakness, while the back-end server prioritizes the Content-Length weakness.
In this type of attack, the attacker declares the length of the first chunk up to and including the malicious request. The second chunk is declared as having 0 length, so the front-end server assumes the request is complete. It passes the request to the back-end server, which receives and processes it.
This is what the request could look like:
POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 3 Transfer-Encoding: chunked 15 MALICIOUS-REQUEST 0
When the backend server receives the request, it sees that the request body is very short, only 3 bytes in length. It does not process the request from MALICIOUS-REQUEST and onwards. Instead, it considers this as the next request. This causes the server to start processing the malicious request as is.
TE-TE Behavior (Transfer-Encoding) Vulnerabilities
Here, both the front-end and back-end servers correctly prioritize the Transfer-Encoding header. However, the attacker can obfuscate the header in order to trick one of the servers.
Here are a few ways in which the header can be obfuscated. Most methods involve a pair or Transfer-Encoding headers, one of which does not follow the usual convention.
Transfer-Encoding: xchunked Transfer-Encoding: chunked Transfer-Encoding: chunked Transfer-Encoding: x X: X[\n]Transfer-Encoding: chunked Transfer-Encoding: xchunked Transfer-Encoding : chunked Transfer-Encoding : chunked
Because this code only slightly departs from the HTTP specification, many server implementations will still accept them as legitimate. To succeed in the attack, the attackers need to find a variation of the Transfer-Encoding header that will be processed by one of the servers but ignored by the other.
The impact of the attack will depend on whether the front-end or back-end server is the one tricked into not processing the Transfer-Encoding header. The rest of the attack will be similar to CL.TE or TE.CL.
Advanced HTTP Request Smuggling Attacks
Bypassing Security Filters
This type of attack involves passing a malicious query directly to a back-end server in such a way that it is not detected by middleware security filters. The query is then executed on the back-end server.
Replacement of Regular Response
This type of attack can be used when the middleware is a cache server. The attacker attempts to perform cache poisoning, where invalid responses are stored in cache entries. After the initial attack succeeds, future use requests will return the malicious query, now stored in the cache. This can result in denial of service on the server.
Credentials Hijacking
In this type of attack, the attacker injects part of the query into the query stream and waits for a legitimate end-user query. The attacker takes the user’s query and appends it to their partial request, using the same connection. The proxy is not aware that these are two separate requests, treating them as one.
This is complex to achieve, but if successful, the attacker manages to “piggyback” on top of the user’s valid session, including their cookie and HTTP authentication details. They can leverage these valid connection details to smuggle their malicious query.
This is a form of credential hijacking. When used in combination with HTTP request smuggling, it can be very dangerous, because the attacker can make POST actions on behalf of the user, using their credentials and level of privileges.
How to Mitigate an HTTP Request Smuggling Vulnerability
HTTP smuggling attacks are sophisticated because they exploit the ambiguities of server protocol interpretations and configurations.
There are several options IT professionals can consider to reduce their exposure to this vulnerability:
- Interpret HTTP headers consistently on front-end and back-end servers—clearly this is the best option for prevention. However, it is not always an option, as load balancers are generally hardware appliances that support backend servers, which are run on distinct platforms. If you cannot run the same software on both front-end and back-end, you should at least be aware of how each server deals with HTTP headers, and ensure they consistently interpret HTTP requests.
- Disable vulnerable optimizations—if you cannot change backend configuration, disable any performance optimizations that use the Transfer-Encoding or Content-Length header. This might hurt the efficiency of the web environment but is highly effective at preventing this attack.
- Avoid use of load balancers, content delivery networks (CDNs), or reverse proxies—if these components are not required in your setup, you are usually safe from HTTP request smuggling.
- Use HTTP/2—ensuring that front-end and back-end servers only communicate using the HTTP/2 protocol can prevent most variants of this attack.
- Disable connection reuse on the back-end server—if this is technically possible in your environment, it can completely prevent HTTP request smuggling.
- Configure the front-end server to normalize ambiguous requests—this can prevent passing malicious requests to the backend server.
- Do not expose logged HTTP traffic—HTTP logs should only be available to administrative users, to avoid exposing unintended parts of an HTTP request to potential attackers.
- Use a web application firewall (WAF)—a lot of WAFs feature technology that identifies and blocks or sanitizes HTTP traffic, such as to request smuggling directives. Organizations that currently use a WAF should confirm with the vendor that the level of protection is activated. It is also important to check whether any changes to the WAF configuration are required to safeguard against an HTTP request smuggling vulnerability.
HTTP Request Smuggling with Imperva
Imperva provides a Web Application Firewall, which can prevent HTTP Request Smuggling attacks and many other application-layer attacks, with world-class analysis of web traffic to your applications.
Beyond HTTP request smuggling protection, Imperva provides comprehensive protection for applications, APIs, and microservices:
Runtime Application Self-Protection (RASP) – Real-time attack detection and prevention from your application runtime environment goes wherever your applications go. Stop external attacks and injections and reduce your vulnerability backlog.
API Security – Automated API protection ensures your API endpoints are protected as they are published, shielding your applications from exploitation.
Advanced Bot Protection – Prevent business logic attacks from all access points – websites, mobile apps and APIs. Gain seamless visibility and control over bot traffic to stop online fraud through account takeover or competitive price scraping.
DDoS Protection – Block attack traffic at the edge to ensure business continuity with guaranteed uptime and no performance impact. Secure your on premises or cloud-based assets – whether you’re hosted in AWS, Microsoft Azure, or Google Public Cloud.
Attack Analytics – Ensures complete visibility with machine learning and domain expertise across the application security stack to reveal patterns in the noise and detect application attacks, enabling you to isolate and prevent attack campaigns.
Client-Side Protection – Gain visibility and control over third-party JavaScript code to reduce the risk of supply chain fraud, prevent data breaches, and client-side attacks.
