25.5 Lab: Web cache poisoning via an unkeyed query string

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 | Karthikeyan Nagaraj

Karthikeyan Nagaraj
2 min readMay 24, 2024

Description

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.

  • 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 like /?a=test. 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. Add an arbitrary parameter that breaks out of the reflected string and injects an XSS payload:
  4. GET /?a=test'/><script>alert(1)</script>
  5. Keep resending the request until you see your payload reflected in the response and X-Cache: hit in the headers.
  6. If lab is not solved, then try resending again and again
  7. 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.

--

--

Karthikeyan Nagaraj

Entrepreneur | Writer | Cyber Security Consultant | AI Researcher