Notice that the home page is a suitable cache oracle and send the
GET /request to Burp Repeater.
- Observe that any changes to the query string are always reflected in the response. This indicates that the external cache includes this in the cache key. Use Param Miner to add a dynamic cache-buster query parameter. This will allow you to bypass the external cache.
Observe that the
X-Forwarded-Hostheader is supported. Add this to your request, containing your exploit server URL:
Send the request. If you get lucky with your timing, you will notice that your exploit server URL is reflected three times in the response. However, most of the time, you will see that the URL for the canonical link element and the
analytics.jsimport now both point to your exploit server, but the
geolocate.jsimport URL remains the same.
Keep sending the request. Eventually, the URL for the
geolocate.jsresource will also be overwritten with your exploit server URL. This indicates that this fragment is being cached separately by the internal cache. Notice that you've been getting a cache hit for this fragment even with the cache-buster query parameter - the query string is unkeyed by the internal cache.
X-Forwarded-Hostheader and resend the request. Notice that the internally cached fragment still reflects your exploit server URL, but the other two URLs do not. This indicates that the header is unkeyed by the internal cache but keyed by the external one. Therefore, you can poison the internally cached fragment using this header.
Go to the exploit server and create a file at
/js/geolocate.jscontaining the payload
alert(document.cookie). Store the exploit.
Back in Burp Repeater, disable the dynamic cache buster in the query string and re-add the
X-Forwarded-Hostheader to point to your exploit server.
- Send the request over and over until all three of the dynamic URLs in the response point to your exploit server. Keep replaying the request to keep the cache poisoned until the victim user visits the page and the lab is solved.
Lab: Internal cache poisoning
This lab is vulnerable to web cache poisoning. It uses multiple layers of caching. A user regularly visits this site's home page using Chrome.
To solve the lab, poison the internal cache so that the home page executes
alert(document.cookie) in the victim's browser.