Chapter 6.HTTP request smuggling

1.

Chapter 6.HTTP request
smuggling

2.

Chapter 6.Sections and sectors
HTTP request smuggling
1.1 Definition
1.2 Procedure
1.3 Types of the HTTP request smuggling

3.

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).

4.

HTTP request smuggling
Since HTTP/1.1 there's been widespread support for sending multiple HTTP
requests over a single underlying TCP or SSL/TLS socket. The protocol is extremely
simple - HTTP requests are simply placed back to back, and the server parses
headers to work out where each one ends and the next one starts. This is often
confused with HTTP pipelining, which is a rarer subtype that's not required for the
attacks described in this paper.
However, modern websites are composed of chains of systems, all talking over
HTTP. This multi-tiered architecture takes HTTP requests from multiple different
users and routes them over a single TCP/TLS connection:

5.

HTTP request smuggling
This means that suddenly, it's crucial that the back-end agrees
with the front-end about where each message ends. Otherwise,
an attacker might be able to send an ambiguous message which
gets interpreted as two distinct HTTP requests by the back-end:

6.

HTTP request smuggling
Let's imagine that the front-end prioritises the first
content-length header, and the back-end prioritises
the second. From the back-end's perspective, the TCP
stream might look something like:
In this example, the injected 'G' will corrupt the green user's request and
they will probably get a response along the lines of "Unknown method
GPOST".

7.

HTTP request smuggling
Since the specification implicitly allows processing requests using both Transfer-Encoding:
chunked and Content-Length, few servers reject such requests.
In a chunked message, the body consists of 0 or more chunks. Each chunk consists of the
chunk size, followed by a newline (\r\n), followed by the chunk contents. The message is
terminated with a chunk of size 0. Here's simple desynchronization attack using chunked
encoding:

8.

HTTP request smuggling
If it's the back-end that doesn't support chunked encoding,
we'll need to flip the offsets around:

9.

HTTP request smuggling
This can be achieved using discrepancies in servers' HTTP parsing. Here's a
few examples of requests where only some servers recognise the TransferEncoding: chunked header. Each of these has been successfully used to exploit
at least one system during this research:

10.

How HTTP request smuggling works

11.

HTTP request smuggling
The HTTP header offers two distinct ways
of specifying where the request ends:
The Transfer-Encoding header
The Content-Length header

12.

What Is the Impact of HTTP Request
Smuggling Attacks?
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

13.

HTTP Request Smuggling Examples
The three main attack techniques are known as
“CL.TE”
(Content-Length.Transfer-Encoding),
meaning the attack exploits content length on the
front end and then transfer encoding on the back
end
“TE.CL”
(Transfer-Encoding.Content-Length) for
the opposite
“TE.TE”
(Transfer-Encoding. Transfer-Encoding)
for a double exploitation of transfer encoding, on
both front and back end.

14.

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.

15.

CL.TE (Content-Length.Transfer-Encoding)
Vulnerabilities
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.

16.

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.

17.

TE.CL (Transfer-Encoding.Content-Length)
Vulnerabilities
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.

18.

TE-TE Behavior (Transfer-Encoding)
Vulnerabilities
Here, both the front-end and back-end
servers correctly prioritize the TransferEncoding header. However, the
attacker can obfuscate the header in
order to trick one of the servers.

19.

TE-TE Behavior (Transfer-Encoding)
Because this code only slightly
departs from the HTTP specification, many
Vulnerabilities
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.

20.

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.

21.

Advanced HTTP Request Smuggling
Attacks
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.

22.

Advanced HTTP Request Smuggling
Attacks
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.

23.

How to Mitigate an HTTP Request
Smuggling 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 TransferEncoding or Content-Length header. This might hurt the efficiency of the web
environment but is highly effective at preventing this attack.

24.

How to Mitigate an HTTP Request
Smuggling Vulnerability
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.

25.

How to Mitigate an HTTP Request
Smuggling Vulnerability
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.

26.

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.

27.

HTTP Request Smuggling with
Imperva
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 clientside attacks.

28.

How to prevent HTTP request smuggling
vulnerabilities
To prevent HTTP request smuggling vulnerabilities, we recommend the following
high-level measures:
Use HTTP/2 end to end and disable HTTP downgrading if possible. HTTP/2 uses a
robust mechanism for determining the length of requests and, when used end to
end, is inherently protected against request smuggling. If you can't avoid HTTP
downgrading, make sure you validate the rewritten request against the HTTP/1.1
specification. For example, reject requests that contain newlines in the headers,
colons in header names, and spaces in the request method.
Make the front-end server normalize ambiguous requests and make the back-end
server reject any that are still ambiguous, closing the TCP connection in the
process.
Never assume that requests won't have a body. This is the fundamental cause of
both CL.0 and client-side desync vulnerabilities.
Default to discarding the connection if server-level exceptions are triggered when
handling requests.
If you route traffic through a forward proxy, ensure that upstream HTTP/2 is enabled
if possible.