HTTP request kolaiadipu (HTTP request smuggling)

Hi guyzu… I was kinda bored. So, I thought why not post what we learn in a fun way. Adhanala indha mari post podalamanu yosichitu irukan. Idha padichitu neenga interested na kaiya thookunga 🙋‍♂️

Atleast 5 votes vandhuchuna nan indha mari posts daily poduran, also maybe idhuku dedicated aa oru sub or discord server panalamanu solunga.

Indha post la I am going to explain HTTP request smuggling which is a vulnerability which allows an attacker to control what response the next user/request receives.

First uh I will start with what are HTTP requests. Reference: https://bytebytego.com/guides/what-happens-when-you-type-a-url-into-your-browser/

What happens when you type a url into your browser?

Neenga ipo unga browser la codeforces.com nu type panringanu vachikonga, codeforces.com ngra indha domain name ku nu oru ip address irukum which is nothing but the phone number of a server (basically a PC) which has the contents of codeforces stored. Assume a DNS resolver is black box which converts the domain name you type into it's appropriate ip address (can't explain any further in this post otherwise it'd get way too long). Your browser will now get the phone number of the PC which has the website's contents (HTML, CSS, JS, JSON, static data….) from the DNS resolver. Now your browser will call the server and ask "thambi enaku codeforces.com oda main page kaatupa", the server arranges all the requested data and sends them one by one. Once all the data is received by your browser, it will parse them and run the DOM and will display the web interface.

This is basically how http request and responses work. Your browser calling the server is called a HTTP request and the return call from the server is called a HTTP response.

Now lemme explain about how this vulnerability works

HTTP request smuggling

Generally you won't be directly connected to the main server which has the actual content. There'll almost always be a frontend server (CDN, reverse proxy, load balancer,…) which is used to avoid overload on the main server and bosst efficiency and response times.

Like you thousands of people would be sending http requests to the domain at the same time. The frontend server should identify where your HTTP request ends and the next one begins. For this purpose, there is 2 HTTP headers which is the root cause of this vulnerability – Content-Length and Transfer-Encoding.

You can manipulate these 2 headers to differ. If the frontend server and backend server has any difference in handling these headers (CL.TE, TE.CL, TE.TE), that's when this vulnerability arises.

Idhu elathaiyum indha post la explain panna mudiyadhu. So nan oru type matum explain panran, the other two are similar.

CL.TE vulnerabilities

In this vulnerability, the frontend server uses Content-Length header and the back-end server uses the Transfer-Encoding header to decide where each HTTP request ends.

Example:

POST / HTTP/1.1

Host: vulnerable-website.com

Content-Length: 13

Transfer-Encoding: chunked

0

SMUGGLED

The front-end server uses the Content-Length header and thinks that the request is 13 bytes long and believes this is a single whole request and forwards this to the backend server.

The back-end server uses the Transfer-Encoding header to decide the end and thinks it ends at 0 because when the Transfer-Encoding header is used, it means 0 is the end of the request of that request and the remaining bytes (SMUGGLED) is left unprocessed in that shared connection. This gets attached to whoever's request comes next in that shared connection.

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

What can be done with this vulnerability?

Instead of "SMUGGLED" you can use a self-contained in-place. If you do so, the next user will get the response what smuggled request you inserted instead of what they actually asked for and the next user after the victim will get the response of the victim. If the victim requested anything sensitive, he's fucked up as the next person even without any authentication receives the response of the victim.

The same way you can also absorb the HTTP headers of the next users request along with all the authenticated cookies using the same technique allowing you to do a no-click full account takeover.

Crazy right?

Ok guyzu.. indha posta idhoda mudichikuran, epdi irunchunu solunga. If I sense enough interest for such posts, I will continue.