HTTP Request Smuggling in Plain English.

Hello everyone, this is the topic in which I’ve really struggled learning it. So I decided to understand it from the various blog post, videos and many more ways. Today, I’m gonna write is down in Plain English and in the end will attach the references and some tools also ;)

Let’s Begin and try to finish it in one article.

# 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

HTTP request smuggling is also called as HTTP DESYNC ATTACK because the request sent is treated distinctly by Front-end and Back-end server on account of which we get an unexpected outcome or error in the Response and this can be considered as the base explanation of request smuggling.

To understand deeply about request smuggling behaviour we have to know the major key specs of its happening.

# 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

Front-End Server (Load Balance | Reverse Proxy)

Process the content-length

Back-End Server

Process the transfer-encoding

Carriage Return Line Feed (CRLF) \r\n

You check out my previous blog about CRLF if any confusion in what is CRLF.
But here CRLF characters play vital role in request smuggling as they append in end and they are also not visible in the request.
\r = 1 byte, \n = 1 byte

Size: (in bytes)

Will come into play when performing it manually [It can be tricky]:)

# How this Issue is caused? (Laymen-term)

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 distinctly and due to which the request doesn’t synchronise and give us an unexpected outcome or error in the Response which cause the Request smuggling.

Vulnerabilities exploited via Request Smuggling:

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

# Understanding Transfer-Encoding

We’ll understand it with the help of an Image.

Here in this above image Transfer encoding is used and you can see chunked is also used which sends the large data into chunk series.
Key Points:
5: tells that Hello has 5 character in Hexa-Decimal (5 Decimal = 5 Hex)
1E: tells that hetroublemaker-from-cyberverse has 30 character in Hexa-Decimal
0: in the end it tells to terminate the request( Termination-Point)

#Understading Content-Length

We’ll understand it with the help of an Image.

As you can see content-length = 6, and you get confused HOW? that’s what happened with me in starting stage. In real case you won’t see CRLF characters but they are appened after each line are also counted in the content-length of the request and hence 0 + \r + \n + \r + \n + G = 6 content-length.

# Now, it’s time to Understand the Actual Vulnerability.

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

Let’s take an example here and understand with an Image:

As you can see in the above image Content-Length & Transfer-Encoding both are used and According to RFC specifications if both the headers are present in a single request then they will conflict each other and then the Content-Length header should be ignored.

Now, let’s suppose if the front-end server processes the content-length then it’ll check the Content-Length header of the Request which is equal to 6. (0+(CRLF characters)+F) = 6

After front-end, the request will go to back-end server and here Transfer-Encoding comes into play; As you know back-end processes the T.E, So it’ll check for Transfer-Encoding header and also we have mentioned 0 ‘Zero’ (which means Termination Point). And If back-end supports T.E it’ll not forward the rest of data after it’s termination point and “F” will remain unprocessed until next request. And will append with the Next Request as you can see in the above image [Request in red in the next request]

DEMO:

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

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

Let’s understand it with an Image.

Here you can see that Malicious request, It has Transfer-Encoding: chunked & Content-Length: 4. Now analyse the request: content-length is 4 Because it’s the length of 5c (plus CRLF character) which is hex-number of 92 decimal number and After that, there is some data which is going to be our junk data which will get left unprocessed, and the back-end server will treat these as being the start of the next request in the sequence.

DEMO:

#There is also TE.TE vulnerability which I expect you can do it on your own :D

# Some Automation

1. Burp suite’s extension: HTTP Request Smuggler

GitHub - PortSwigger/http-request-smuggler

2. This is a tool created by Gwendal Le Coguic

gwen001/pentest-tools

DEMO:

THE END

Before ending it here, I’m gonna share some amazing blog post and some HackerOne reports about the HTTP request smuggling Vulnerability.

• Help you understand HTTP Smuggling in one article
• Escalating reflected XSS with HTTP Smuggling
• Slack disclosed on HackerOne: Mass account takeovers using HTTP...
• Lob disclosed on HackerOne: HTTP Request Smuggling on vpn.lob.com
• New Relic disclosed on HackerOne: Password theft login.newrelic.com...
• Write up of two HTTP Requests Smuggling

This is all about the basics of Request smuggling. I hope you have learnt something from this blog.

So, Until Next Blog

Best of luck everyone. Keep-Hacking!

Feedbacks and edits are welcome

Twitter, Linkedin, Youtube

If you enjoyed this blog, please click the 👏 button and share it to help others find it.