Lion Cipher Lab
Steal a victim's private data with web cache deception — then fix the path-mapping mismatch
- AppSec / DevSecOps
- Advanced
- ~80 min
- Free · no account required
Why it matters
Web cache deception has leaked real users' account pages, API keys, and CSRF tokens on major sites, and it needs no XSS and no injected payload — just a URL a victim clicks while logged in. It hides in the seam between two systems that each behave 'correctly' on their own: a CDN/cache that caches by file extension, and an app framework that ignores the extension and serves the private page anyway. Once you have seen the mismatch with your own eyes, you will spot it in architecture reviews and know the handful of configuration choices that close it for good.
What you'll learn
- the path-mapping-mismatch model that makes web cache deception possible (cache rules vs origin routing)
- building a caching reverse-proxy + authenticated origin lab with Docker to test cache behavior safely
- crafting a deception URL so a victim's private response gets stored in a shared cache
- reading a victim's cached secret back as an unauthenticated attacker, proven with X-Cache/Age
- fixing it: cache by Cache-Control/content-type not URL suffix, normalize/verify the path mapping, and never cache authenticated responses
- distinguishing web cache DECEPTION (steal private data) from web cache POISONING (serve harmful data)
Steps in this lab
- Deception vs poisoning — get the direction straight
- Build the lab: a caching proxy in front of an authenticated app
- Wire up the cache and start it
- Confirm the honest behaviour first
- Craft the deception URL and have the victim load it
- Steal it back with no cookie at all
- Fix it — and know why the cheap fixes are traps
- Re-prove the fix, then tear it down