Http Request Smuggling

Hello everyone, I have learned about HTTP Request Smuggling from various blog post, videos and many more ways. Today, I’m gonna write about it.

Let’s begin.

What is HTTP Request Smuggling ?

HTTP request smuggling is a technique for interfering with the way a web site processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users.

~https://portswigger.net/web-security/request-smuggling

HTTP request smuggling is also called as HTTP DESYNC ATTACK because the request sent is treated differently by Front-end and Back-end server due to which we receive unexpected outcome or error in the Response, and it can lead to HTTP Request Smuggling.

# Core Concept

RFC Specification (2161)

If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

Content-Length

The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

Transfer-Encoding: chunked

The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.
Chunked means that large data is sent in a series of chunks

# Working

When a request is sent then front-end server process the content-length and back-end server process the transfer-encoding and hence both the servers are treating the same request differently and due to which the request doesn’t synchronise and give us an unexpected outcome or error in the Response which cause the HTTP Request smuggling.

# This Vulnerability can be Exploited by 3 ways.

1. CL.TE (Content-length.Transfer-encoding)-

Here, the front-end server uses Content-Length header and the back-end server uses Transfer-Encoding header.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

HERE, the front-end server processes the content-length then it’ll check the Content-Length header of the Request which is equal to 13. (0+(CRLF characters)+SMUGGLED) = 13

The back-end server processes the Transfer-Encoding header, and so treats the message body as using chunked encoding. It processes the first chunk, which is stated to be zero length, and so is treated as terminating the request. The following bytes, SMUGGLED, are left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence.

2. TE.CL (Transfer-Encoding.Content-Length)-

Here, the front-end server uses Transfer-Encoding header and the back-end server uses Content-Length header.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

Here you can see that Malicious request, It has Transfer-Encoding: chunked & Content-Length: 3. Now analyse the request: content-length is 3 Because it’s the length of 8 (plus CRLF character).The following bytes, starting with SMUGGLED, are left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence.

3. TE.TE (Transfer-Encoding.Transfer-Encoding)-

Here, the front-end server as well as back-end both uses Transfer-Encoding header. but one of the servers can be induced not to process it by obfuscating the header in some way.

There are potentially endless ways to obfuscate the Transfer-Encoding header. For example:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

To uncover a TE.TE vulnerability, it is necessary to find some variation of the Transfer-Encoding header such that only one of the front-end or back-end servers processes it, while the other server ignores it.

# Vulnerabilities exploited via Request Smuggling:

• XSS
• Unauthenticated Access
• Web Cache Poisoning
• Web Cache Deception

# Prevention for HTTP Request Smuggling vulnerabilities

Some generic ways to prevent HTTP request smuggling vulnerabilities arising are as follows:

• Disable reuse of back-end connections, so that each back-end request is sent over a separate network connection
• Use HTTP/2 for back-end connections, as this protocol prevents ambiguity about the boundaries between requests.
• Use exactly the same web server software for the front-end and back-end servers, so that they agree about the boundaries between requests.