Listen to this Post
Introduction:
Web cache poisoning is an advanced attack vector where an adversary manipulates a caching server to store and serve a malicious response to multiple users. This exploit hinges on the subtle interplay between unkeyed inputs, application behavior, and cache configuration, allowing a single poisoned request to compromise countless users silently and efficiently.
Learning Objectives:
- Understand the fundamental mechanics of a web cache poisoning attack.
- Learn to identify unkeyed headers and inputs that can be weaponized.
- Master practical commands and techniques for testing, exploiting, and mitigating cache poisoning vulnerabilities.
You Should Know:
1. Identifying Unkeyed Headers with curl
curl -I -H "X-Forwarded-Host: evil.com" http://target.com/`X-Forwarded-Scheme
This command sends a HEAD request to the target with a custom `X-Forwarded-Host` header. The `-I` flag fetches only the HTTP headers of the response.
<h2 style="color: yellow;">Step-by-step guide:</h2>
1. Intercept a Request: Use a tool like Burp Suite to capture a normal request to the target application.
2. Inject Header: Add the `X-Forwarded-Host: evil.com` header. Other common headers to test include,X-Original-URL, andX-Rewrite-URL.evil.com
3. Analyze Response: Check the server's response. If the value from your header (e.g.,) appears in the response headers (likeLocation`) or body (like in a script tag source), you have found an unkeyed input. If this response gets cached, the vulnerability is critical.
- Exploiting Cache Key Flaws with Burp Suite’s Param Miner
Param Miner is a Burp Suite extension essential for discovering cache poisoning vectors.
Step-by-step guide:
- Install Param Miner: Add the extension from the BApp Store in Burp Suite.
- Guess Parameters: Right-click a request, navigate to `Extensions` -> `Param Miner` -> `Guess params` ->
Guess headers. This automatically floods the request with a wide range of esoteric headers. - Identify Differences: Send the original request and the poisoned request to Burp’s Comparer tool. Differences in the response, particularly where your injected header’s value is reflected, indicate a potential poisoning point. The goal is to find a header that influences the response but is not included in the cache key.
3. Web Cache Deception Payload Delivery
http://target.com/account/settings.php/nonexistent.css`settings.php
This URL is a classic Web Cache Deception payload, a cousin of cache poisoning.
<h2 style="color: yellow;">Step-by-step guide:</h2>
1. Craft the URL: Target a sensitive, dynamic page (e.g.,) but append a static-looking extension (e.g.,.css).settings.php
2. Trick the Cache: Some caching mechanisms, upon not finding the resource, will fall back to serving the dynamic page () but store it in the cache under the key for/nonexistent.css`.
3. Exfiltrate Data: If an attacker can trick a user into visiting this URL, the user’s sensitive page (with their session) might be cached. The attacker then visits the same static-looking URL to retrieve the victim’s cached data.
- HTTP Request Smuggling as a Cache Poisoning Vector
`POST / HTTP/1.1
Host: target.com
Content-Length: 61
Content-Length: 0
GET /poisoned HTTP/1.1
Host: target.com
Foo: BAR`
This is a CL.TE (Content-Length vs. Transfer-Encoding) request smuggling payload.
Step-by-step guide:
- Find a Smuggling Vulnerability: First, identify a request smuggling vulnerability between the front-end cache and the back-end server.
- Craft the Poison Payload: The front-end sees the first `Content-Length: 61` and forwards the entire request. The back-end sees the second `Content-Length: 0` and processes the `GET /poisoned` request as a new one.
- Poison the Cache: The response to the smuggled `GET /poisoned` request, which is controlled by the attacker, can be stored in the cache by the front-end. All subsequent users requesting `/poisoned` will receive the malicious response.
5. CloudFront-Specific Cache Poisoning via HTTP/2
An attacker can exploit HTTP/2 request splitting to poison caches on services like AWS CloudFront.
Step-by-step guide:
- Craft an HTTP/2 Request: Use a tool that allows low-level HTTP/2 manipulation.
- Inject Newlines in Headers: Send a request with a header like
X-Forwarded-Host: evil.com\r\nContent-Length: 0\r\n\r\nGET /static/logo.png HTTP/1.1. - Split the Request: If the infrastructure is vulnerable, it might interpret the newlines and process this as two separate requests, caching the response to the second, attacker-controlled request at the path
/static/logo.png. -
Server-Side Code Snippet: Detecting Header Injection in PHP
`
// UNSAFE – Directly using a header without validation
$host = $_SERVER[‘HTTP_X_FORWARDED_HOST’] ?? ‘default.com’;
header(“Location: https://” . $host);
?>`
Step-by-step guide:
- Identify the Sink: The `header()` function is the sink where the unsanitized input (
$_SERVER['HTTP_X_FORWARDED_HOST']) is used. - Understand the Flow: Any header passed by the user as `X-Forwarded-Host` will be directly placed into the `Location` header.
- Mitigation: The secure code must validate and allowlist permitted hosts: `$allowed_hosts = [‘trusted.com’, ‘www.trusted.com’]; if (in_array($host, $allowed_hosts)) { header(“Location: https://” . $host); }`
7. Mitigation: Hardening Cache Keys with Nginx
`proxy_cache_key “$scheme$request_method$host$request_uri$http_cookie”;`
This is an Nginx configuration directive that defines what components form the cache key.
Step-by-step guide:
- Locate Configuration File: Find your Nginx site configuration, typically in
/etc/nginx/sites-available/. - Define a Strict Cache Key: The example key uses the scheme (http/https), method, host, request URI, and user’s cookies. Crucially, it omits unkeyed headers like
X-Forwarded-Host. - Reload Configuration: Test the configuration with `sudo nginx -t` and apply it with
sudo systemctl reload nginx. This ensures that requests with different `X-Forwarded-Host` values are treated as identical by the cache if all other keyed components are the same, neutralizing this specific attack vector.
What Undercode Say:
- The attack surface for web cache poisoning is expanding with modern architectures, moving beyond headers to exploit HTTP/2 protocol nuances and request smuggling.
- Automated discovery with tools like Param Miner is no longer a luxury but a necessity for thorough application security testing, as the vectors are often non-intuitive.
Analysis: The technical write-up referenced in the source post highlights a critical evolution in web attacks. Cache poisoning is no longer just about `X-Forwarded-For` headers. It’s a methodology that requires a deep understanding of the entire request lifecycle—from the browser, through CDNs and reverse proxies, to the application server. Defenders must adopt a zero-trust mindset towards all incoming HTTP requests, rigorously defining what constitutes the cache key and sanitizing every input, including headers that are often considered ‘safe’. The complexity of modern web stacks, combining legacy HTTP/1.1 systems with HTTP/2 and cloud services, creates a fertile ground for these desynchronization attacks, making them a persistent and high-impact threat.
Prediction:
The future of web cache poisoning will increasingly intersect with HTTP/3 and serverless/edge computing platforms (e.g., Cloudflare Workers, AWS Lambda@Edge). As logic moves to the edge, misconfigurations in these environments could lead to novel, large-scale poisoning attacks. Furthermore, the automation of vulnerability discovery through fuzzing and machine learning will make these sophisticated attacks more accessible to less-skilled adversaries, transforming them from a targeted hunter’s tool into a script-kiddie’s weapon of mass compromise. Proactive defense through strict cache key standardization and continuous security testing will be paramount.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ahmed Esmail – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
