What is HTTP Request Smuggling?
HTTP request smuggling is an attack technique that is conducted by interfering with the processing of requests between the front end and back end servers. The attacker exploits the vulnerability by modifying the request to include another request in the first request’s body. This is done by abusing Content-Length and Transfer-Encoding headers. After the attack is successful, the second request in the first request’s body is smuggled and processed.
How does it work and what is its impact?
During the attack, basically two HTTP headers are used:
- Content-Length Header: the size of the request body (in bytes).
- Transfer-Encoding Header: specified as chunked so that the request body will be sent in chunks (separated by newline). 0 is used to end a chunk.
This attack works when the following conditions are met:
- The front-end server forwards multiple requests to the back-end server over the same network connection.
- The back-end doesn’t agree with the front-end about where each message ends.
- The ambiguous message the attacker sends gets interpreted as two separate HTTP requests by the back-end server
- The attacker prepares the second request for the sake of malicious action that cannot be accomplished by the first request
The above request is interpreted as 2 different requests:
 |
|
This vulnerability requires special knowledge on the attack methods. Note that HTTP Smuggling does not exploit any vulnerability in the target web application. This vulnerability can be used for the following impacts by exploiting how web servers interpret HTTP messages:
- Execute Unauthorized Commands
- Gain Privileges
- Bypassing security controls
- Access/Modify Data
- Session Hijacking
- Cache poisoning
How to detect it?
This vulnerability can be detected manually with the guide given below or by using Burp Suite’s smuggler extension. Manual exploitation and detection steps are given below. Please refer to the last section “Portswigger — Automation” of the HTTP Request Smuggling video for more information.
Couple of tips before starting the exploitation:
- Include \r\n\r\n following final 0
- Go to Burp Repeater menu and uncheck “Update Content-Length” option
Attack Types:
Different attack scenarios are given with corresponding PoCs below.
| Front-End | Back-End | |
|---|---|---|
| CL.TE | Content-Length | Transfer-Encoding |
| TE.CL | Transfer-Encoding | Content-Length |
| TE.TE | Transfer-Encoding | Transfer-Encoding |
HTTP request smuggling, basic CL.TE vulnerability
Smuggle a request to the back-end server and observe that the next request processed by the back-end server appears to use the method NEWPOST.
HTTP request smuggling, obfuscating the TE header
Smuggle a request to the back-end server and observe that the next request processed by the back-end server appears to use the method AAAPOST.
HTTP request smuggling, confirming a CL.TE vulnerability via differential responses
Smuggle a request to the back-end server and observe that the next request gives a 404 response code.
Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability
Smuggle a request to the back-end server and observe that it will give access to the admin panel
Smuggle a request to the back-end server and observe that it will delete a user.
Exploiting HTTP request smuggling to deliver reflected XSS
Smuggle a request to the back-end server and observe that the next user’s request will receive a response that executes XSS payload.
For more insights on how to implement this attack check out my new video, HTTP Request Smuggling All-In-One:
In this video, Busra will explore how to exploit HTTP Request Smuggling by using different scenarios such as basic CL.TE and TE.CL vulnerabilities. She will look at confirming via different responses, obfuscating TE headers, bypassing front-end security controls, delivering reflected XSS, automating, and more.
How to Prevent HTTP Request Smuggling
So in theory, this can be prevented by any of these:
- Making front-end server to realize ambiguous requests
- Making the back-end server reject ambiguous requests and close the network connection
More practical prevention methods based on the above explanations can be found below:
- Disable reuse of back-end connections
- Use HTTP/2 for back-end connections
- Use the same web server software for front-end and back-end server
- Prefer a WAF that has built-in mitigation to detect abnormal requests
Explore more on a similar topic with a detailed post on client-side desync attacks.
