It is a technique of interfering with a website processing a sequence of HTTP requests.
Most of today’s web application frequently uses a chain of HTTP servers between the user and the application. users usually send requests to frontend servers such as load balancers or reverse proxies and the requests are processed by various backend servers
This vulnerability arises as the frontend server sends several requests over the same backend network connection. HTTP requests are sent one after the other and receiving server parses the HTTP request headers to identify where the headers begin and ends
how does HTTP request vulnerability arise??
HTTP provides 2 ways to specify the end of the request by content length and Transfer-encoding header
POST /search HTTP/1.1
Host: dummy.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smugglingThis shows the example of the Content-Length header. It specifies the length of the request body.
POST /search HTTP/1.1
Host: dummy.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
9
r=request
0This shows the example of the Transfer-Encoding header. This sounds a bit complex but it’s really easy to understand.
The b in the response body indicates the body length of 11 (in hexadecimal notation) followed by the next request of size 9.
The request is terminated with a chunk size of 0
we use chunked encoding and the syntax for chunks is as follows.
<chunk size in hexadecimal>
<body of the request>
...
...
0 //for terminationsince we have two main specifications, it is possible for a server to use both headers or any one of them and not care about the others. The HTTP specification attempts to prevent this problem by stating that if both the Content-Length and Transfer-Encoding headers are present, then the Content-Length header should be ignored.
Some servers do not support the Transfer-Encoding header in requests.
Some servers that do support the Transfer-Encoding header can be induced not to process it if the header is obfuscated in some way.
How to prevent HTTP request smuggling vulnerabilities
- Using HTTP/2 and disabling HTTP downgrading
- 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
sources: portswigger
stay tuned for more content about how to exploit vulnerabilities of these types!!!!
