Web cache deception

Tags: cache-deception, cdn, session

Level: advanced

Method

1. Name the cache

   Read Age, X-Cache, CF-Cache-Status, or the vendor header on the host you are testing. No cache header means you do not yet know a shared cache is involved.

   Tools: Burp Suite

2. Record the cache key

   See whether path, query, cookie, and Authorization change the stored object. A private URL that ignores the session cookie is the lead.

   Tools: Burp Suite

3. Compare a static-looking path

   Request an authenticated page you own, then the same path when the suffix looks like a static file. Different cache status on the same account data is the signal.

   Tools: browser, Burp Suite

4. Second client

   Load that URL in a clean session that never authenticated. Your own replay is not proof that someone else receives the body.

   Tools: browser

5. Say what was stored

   Use an account you own. Email, object ids, or tokens in the cached body are the impact. Stop if the body is not yours.

   Tools: browser

6. Clean up

   Do not leave a private response in a shared cache. Purge if you can, wait out the stated lifetime, or use a path only your test user can request.

   Tools: browser

Field notes

• The existing cache-poisoning playbook is a different bug. Do not file them as one report.
• A HIT that still carries a private Set-Cookie is part of the evidence.
• Normalization differences between the cache and the origin are the usual cause. Describe the two URLs, not a wordlist.

References

• https://portswigger.net/web-security/web-cache-deception
• https://owasp.org/www-project-web-security-testing-guide/