25.1 Lab: Web cache poisoning with an unkeyed header
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 aler t(document.cookie) in the visitor’s browser | Karthikeyan Nagaraj
3 min readMay 21, 2024
Description
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.
Hint
This lab supports the X-Forwarded-Host
header.
Solution
- With Burp running, load the website’s home page
- In Burp, go to “Proxy” > “HTTP history” and study the requests and responses that you generated. Find the
GET
request for the home page and send it to Burp Repeater. - Add a cache-buster query parameter, such as
?cb=1234
. - Add the
X-Forwarded-Host
header with an arbitrary hostname, such asexample.com
, and send the request. - Observe that the
X-Forwarded-Host
header has been used to dynamically generate an absolute URL for importing a JavaScript file stored at/resources/js/tracking.js
. - Replay the request and observe that the response contains the header
X-Cache: hit
. This tells us that the response came from the cache. - Go to the exploit server and change the file name to match the path used by the vulnerable response:
/resources/js/tracking.js
- In the body, enter the payload
alert(document.cookie)
and store the exploit. - Open the
GET
request for the home page in Burp Repeater and remove the cache buster. - Add the following header, remembering to enter your own exploit server ID:
X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net
- Send your malicious request. Keep replaying the request until you see your exploit server URL being reflected in the response and
X-Cache: hit
in the headers. - To simulate the victim, load the poisoned URL in the browser and make sure that the
alert()
is triggered. Note that you have to perform this test before the cache expires. The cache on this lab expires every 30 seconds. - If the lab is still not solved, the victim did not access the page while the cache was poisoned. Keep sending the request every few seconds to re-poison the cache until the victim is affected and the lab is solved.
A YouTube Channel for Cybersecurity Lab’s Poc and Write-ups
Telegram Channel for Free Ethical Hacking Dumps
Thank you for Reading!
Happy Ethical Hacking ~
Author: Karthikeyan Nagaraj ~ Cyberw1ng