Unlock enhanced API scanning with Burp Suite Enterprise Edition  –  Learn more

Lab: Web cache poisoning via an unkeyed query string

PRACTITIONER

This lab is vulnerable to web cache poisoning because the query string is unkeyed. A user regularly visits this site's home page using Chrome.

To solve the lab, poison the home page with a response that executes alert(1) in the victim's browser.

Hint

  • If you're struggling, you can use the Pragma: x-get-cache-key header to display the cache key in the response. This applies to some of the other labs as well.
  • Although you can't use a query parameter as a cache buster, there is a common request header that will be keyed if present. You can use the Param Miner extension to automatically add a cache buster header to your requests.

Solution

  1. With Burp running, load the website's home page. In Burp, go to "Proxy" > "HTTP history". Find the GET request for the home page. Notice that this page is a potential cache oracle. Send the request to Burp Repeater.
  2. Add arbitrary query parameters to the request. Observe that you can still get a cache hit even if you change the query parameters. This indicates that they are not included in the cache key.
  3. Notice that you can use the Origin header as a cache buster. Add it to your request.
  4. When you get a cache miss, notice that your injected parameters are reflected in the response. If the response to your request is cached, you can remove the query parameters and they will still be reflected in the cached response.
  5. Add an arbitrary parameter that breaks out of the reflected string and injects an XSS payload:

    GET /?evil='/><script>alert(1)</script>
  6. Keep replaying the request until you see your payload reflected in the response and X-Cache: hit in the headers.
  7. To simulate the victim, remove the query string from your request and send it again (while using the same cache buster). Check that you still receive the cached response containing your payload.
  8. Remove the cache-buster Origin header and add your payload back to the query string. Replay the request until you have poisoned the cache for normal users. Confirm this attack has been successful by loading the home page in the browser and observing the popup.
  9. The lab will be solved when the victim user visits the poisoned home page. You may need to re-poison the cache if the lab is not solved after 35 seconds.

Community solutions

nu11 secur1ty