An introductory guide to HTTP request smuggling

HTTP request smuggling is a type of security vulnerability that takes advantage of the logic how a sequence of requests processed at different components used in the application such as proxies or servers. This inconsistent behavior of the components can lead to the smuggling of attacker defined requests that could allow them to bypass security implementations and perform unauthorized actions. HTTP request smuggling vulnerability is mostly tested and present in HTTP/1 requests. However we can also try this on HTTP/2 request depending upon the backend architecture of the application.

HTTP request smuggling in general means hiding a malicious requests/payload inside the legitimate requests that would be processed by the components of the application in subsequent request.

There are two headers namely Content-Length and Transfer-Encoding that we need to understand before moving to the exploitation part of this vulnerability. Lets go through these headers together.

When the length of the content that is already known then Content-Length header can be used in the request to represent the size of the message/payload in the body. Recipient utilizes Content-Length header to determine the exact length of the content and that helps server in proper parsing and processing of the content sent by the user.

POST /userinfo.php HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
Connection: close

uname=mayank

It is often used when the content length is unknown or when there is a requirement to transfer the content in chunks. It can consist of multiple values in the form of chunk. Each chunk consist of size of the chunk followed by the content. Message termination is determined if the chunk size in request set to 0.

POST /userinfo.php HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

6
mayank

As we can denote the length of the content in request using two methods namely Content-Length and Transfer-Encoding, what will happen if these both headers are present in the same request??

If this is the case then by default Content-Length approach would be ignored and Transfer-Encoding is preferred.

Identifying and exploitation of this vulnerability involves sending both of the headers in a single request and then analyze the behavior of front-end and backend server. We can test this vulnerability by keeping the given below behavior in mind.

CL.TE: Front-end server utilizes the Content-Length and backend server use Transfer-Encoding.TE.CL: Front-end server utilizes the Transfer-Encoding while backend server use Content-Length.TE.TE: Both front-end and backend server support Transfer-Encoding

Below is the approach that can be followed to exploit first case mentioned above.

POST / HTTP/1.1
Host: www.example.com
Content-Length: 14
Transfer-Encoding: chunked

smuggling

In above example, the front-end server supports Content-Length and hence it would consider it as a single request, however when this request would be forwarded to backend Transfer-Encoding would come into picture.

In Transfer-Encoding request would be processed in chunks. We have specified the length of first chunk as 0, hence it would be considered as termination of the request and “smuggling” would be considered as start of next request.

It is called HTTP request smuggling as we have poisoned the subsequent request that would be processed by the backend server.

It can be used to bypass various security controls implemented on frontend, sometimes even client authentication.

HTTP/2 can be used to prevent HTTP request smuggling attack along with this we need to disable downgrading of HTTP/2 to HTTP/1

Hope you enjoyed reading this writeup🙂😇