Cache Me
If You Can
Web Cache Poisoning & Deception
- What is a Web Cache?
- Web Cache Poisoning
- Web Cache Deception
- Poisoning vs. Deception: Key Differences
- How they work
- Anatomy of an Attack
- Live Demos (PortSwigger Labs)
- How to Prevent These Attacks
Agenda
-
Sits between users & servers
-
Stores copies of web content (static or sometimes dynamic)
-
Uses "cache keys" to decide where to store and what to serve
-
Speeds up response, reduces server load
What is a Web Cache?
-
Attacker tricks the cache into storing a malicious response
-
When users visit the cached page, they get the attacker’s payload
-
Amplifies the reach of attacks like XSS, redirects, etc.
Web Cache Poisoning
What Is It?

-
Exploits differences in cache and server URL handling
-
Attacker tricks the cache into storing someone else’s private data
-
Cache serves up sensitive info to anyone who requests the crafted URL
Web Cache Deception: What Is It?

Poisoning vs Deception
What’s the Difference?
| Web Cache Poisoning | Web Cache Deception | |
|---|---|---|
| Goal | Inject malicious data | Expose private/sensitive data |
| Who’s Affected | Many users | Usually individual users |
| How | Manipulate cache keys | Exploit cache rule discrepancies |
| Impact | Mass distribution | Data leakage |
-
Find unkeyed input: Headers or parameters ignored by cache, but used by server
-
Inject payload: Craft request so server includes attacker’s content in response
-
Get it cached: Cache stores the poisoned response
-
Victims visit: All users get the attacker’s response until cache expires
How Does Web Cache Poisoning Work?

-
Find dynamic endpoint: Returns private data (e.g., profile info)
-
Craft static-looking URL: Add .css, .js, or other static extension
-
Victim visits URL: Their sensitive response is cached
-
Attacker fetches: Requests the same URL, gets cached private data
How Does Web Cache Deception Work?

- Step 1: Identify unkeyed input
- Step 2: Craft payload that server will reflect or process
- Step 3: Force cache to store your payload
- Step 4: Wait for users to hit the poisoned cache
Anatomy of a Web Cache
Poisoning Attack

- Step 1: Identify endpoint serving private data
- Step 2: Append static extension or delimiter to URL
- Step 3: Victim visits and triggers caching of their private response
- Step 4: Attacker grabs the cached response from the crafted URL
Anatomy of a Web Cache
Deception Attack

{Lab Demo}
Web Cache Poisoning
{Lab Demo}
Web Cache Deception
-
Exclude unkeyed headers/params from responses
-
Sanitize anything that's reflected in the response
-
Make sure you are including all relevant headers/params in the cache key
-
Disable/limit caching on dynamic pages
Preventing Web Cache Poisoning

-
Set
Cache-Control: no-store, privateon all dynamic or sensitive content -
Review cache/CDN rules for static extensions, directories, or file names
-
Ensure cache and origin server treat URLs and delimiters the same way
-
Use CDN features like “Cache Deception Armor” (e.g. Cloudflare)
Preventing Web Cache Deception


Code
By Francisco Ramos
Code
- 9