Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions src/pentesting-web/cache-deception/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -461,6 +461,57 @@ Validation checklist
- Confirm the authenticated header is present on the retargeted request (e.g., in a proxy or via server-side logs) and that the CDN caches the response under the traversed path.
- From a fresh context (no auth), request the same path and confirm the secret JSON is served from cache.


### Authenticated HTML cache entries targeted with query cache busters

Not every WCD requires path confusion or static extensions. A very common variant is: **authenticated HTML response + shared cacheability + attacker-controlled cache key + user-specific secret in the body**.

Typical indicators:

- The authenticated page returns **`X-Cache: MISS`** on first load and **`X-Cache: HIT`** when replayed.
- **`Cache-Control`** allows shared caching (for example, it lacks **`private`** / **`no-store`**).
- The HTML source contains **victim-specific data** such as JWTs, CSRF tokens, email addresses, account settings, or bootstrapped session objects inside inline JavaScript.

Minimal validation flow:

1. Authenticate and request a page that should be user-specific (homepages are still interesting if they bootstrap session state).
2. Replay the exact request in Burp Repeater.
3. Compare **`X-Cache`**, **`Age`**, and **`Cache-Control`**.
4. Inspect the cached body, not just the headers: if secrets are embedded in the HTML/JS, another user hitting the same cache key may receive them.

If many users constantly overwrite the shared entry, add an **attacker-chosen query parameter** to isolate the cache key:

```http
GET /?cacheBuster=1 HTTP/1.1
Host: target.com
Cookie: session=<victim-session>
```

If the cache keys on the full URL, forcing the victim to visit that exact URL stores their authenticated response under a predictable entry that the attacker can later request anonymously. This is especially useful on homepages that are globally cacheable but still inject per-user state into the DOM.

### SameSite=Lax delivery constraints in WCD campaigns

When the victim must seed the cache from an attacker-controlled site, remember that **default `SameSite=Lax` cookies are usually not sent on cross-site subresource requests** such as **`<img>`**, **`<script>`**, or XHR/fetch. Therefore, a payload like the following often primes the cache with an **unauthenticated** response only:

```html
<img src="https://target.com/?cacheBuster=1">
```

To seed the cache with the victim's authenticated HTML, use a **top-level navigation** primitive instead, because `SameSite=Lax` still allows cookies on cross-site navigations such as links and many GET redirects:

```html
<meta http-equiv="refresh" content="0; url=https://target.com/?cacheBuster=1">
<p>If not redirected, <a href="https://target.com/?cacheBuster=1">open target</a>.</p>
```

Practical checklist:

- First confirm that the **subresource** version does **not** include cookies.
- Then switch to a **top-level navigation** and verify that the cacheable response now contains victim-only data.
- Re-request the exact cache-buster URL from a clean context and confirm the secret is returned from cache.

This turns a noisy, random WCD into a **targeted account-takeover primitive** whenever the cached HTML exposes reusable session material.

## Automatic Tools

- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.
Expand All @@ -482,6 +533,7 @@ Validation checklist
- [CSPT presentation by Maxence Schmitt](https://www.youtube.com/watch?v=O1ZN_OCfNzg)
- [PortSwigger: Web Cache Deception](https://portswigger.net/web-security/web-cache-deception)
- [Cache Poisoning Case Studies Part 1: Foundational Attacks Behind a $100K+ Vulnerability Class](https://herish.me/blog/cache-poisoning-case-studies-part-1-foundational-attacks/)
- [Cracking SameSite for a $2,000 Web Cache Deception](https://medium.com/@tinopreter/cracking-samesite-for-a-2-000-web-cache-deception-746972278412)



Expand Down