HTTP Request Smuggling
HTTP Request Smuggling / HTTP Desync Attack
This vulnerability occurs when a desyncronization between front-end proxies and the back-end server allows an attacker to send an HTTP request that will be interpreted as a single request by the front-end proxies (load balance/reverse-proxy) and as 2 request by the back-end server. This allows a user to modify the next request that arrives to the back-end server after his.
Tools
Burp extension : HTTP Request Smuggler
Particularities
Remember that in HTTP a new line character is composed by 2 bytes:
Content-Length: This header uses a decimal number to indicate the number of bytes of the body of the request. The body is expected to end in the last character, a new line is not needed in the end of the request.
Transfer-Encoding: This header uses in the body an hexadecimal number to indicate the number of bytes of the next chunk. The chunk must end with a new line but this new line isn't counted by the length indicator. This transfer method must end with a chunk of size 0 followed by 2 new lines:
0
Basic Examples
So, request smuggling attacks involve placing both the Content-Length header and the Transfer-Encoding header into a single HTTP request and manipulating these so that the front-end and back-end servers process the request differently. The exact way in which this is done depends on the behaviour of the two servers:
CL.TE: the front-end server uses the
Content-Lengthheader and the back-end server uses theTransfer-Encodingheader.TE.CL: the front-end server uses the
Transfer-Encodingheader and the back-end server uses theContent-Lengthheader.TE.TE: the front-end and back-end servers both support the
Transfer-Encodingheader, but one of the servers can be induced not to process it by obfuscating the header in some way.
Finding CL.TE vulnerabilities using timing techniques
If an application is vulnerable to the CL.TE variant of request smuggling, then sending a request like the following will often cause a time delay:
Since the front-end server uses the Content-Length header, it will forward only part of this request, omitting the X. The back-end server uses the Transfer-Encoding header, processes the first chunk, and then waits for the next chunk to arrive. This will cause an observable time delay.
Confirming CL.TE vulnerabilities using differential responses
To confirm a CL.TE vulnerability, you would send an attack request like this:
If the attack is successful, then the last two lines of this request are treated by the back-end server as belonging to the next request that is received.
Since the next request now contains an invalid URL, the server will respond with status code 404, indicating that the attack request did indeed interfere with it.
Finding TE.CL vulnerabilities using timing techniques
If an application is vulnerable to the TE.CL variant of request smuggling, then sending a request like the following will often cause a time delay:
Since the front-end server uses the Transfer-Encoding header, it will forward only part of this request, omitting the X. The back-end server uses the Content-Length header, expects more content in the message body, and waits for the remaining content to arrive. This will cause an observable time delay.
Confirming TE.CL vulnerabilities using differential responses
To confirm a TE.CL vulnerability, you would send an attack request like this:
To send this request using Burp Repeater, you will first need to go to the Repeater menu and ensure that the "Update Content-Length" option is unchecked.
You need to include the trailing sequence \r\n\r\n following the final 0.
If the attack is successful, then everything from POST /404 onwards is treated by the back-end server as belonging to the next request that is received.
Since the next request now contains an invalid URL, the server will respond with status code 404, indicating that the attack request did indeed interfere with it.
TE.TE behavior: obfuscating the TE header
The front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.
Tools
Last updated
