-
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:X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net -
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 thegeolocate.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. -
Remove the
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 payloadalert(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.
Register for free to track your learning progress
-
Practise exploiting vulnerabilities on realistic targets.
-
Record your progression from Apprentice to Expert.
-
See where you rank in our Hall of Fame.
Already got an account? Login here
