· 3 min read Sam Verified author

Web-Cache Poisoning

My notes about Cache Poisoning in web applications

Web-Cache Poisoning Vulnerability OWASP

Category: [Server-Side]
Severity: [Medium to Critical]
Impact: [Stored XSS, DoS, arbitrary redirection, Session/Data theft]

1.Concept

It enables an attacker to exploits the behavior of a webserver and cache, so that a harmful HTTP response may serve to other users.

2. Phases

  • Getting a response from back-end server that contains some sensitive or dangerous data or payloads
  • Make sure that the response is cached and served to the intended victim/users.

3. A quick look at web-cache

What is a web-cache? a web-cache is a server which sits between clients and origin servers and saves static and repeated responses. for example: Many users may request for /index.html, so if origin server had to generate a response separately for each user it might lead to high latency and some other issues, web-cache save that specific response and serve it to users instead of origin server.

Cache keys

Web-cache has to decide about whether a request should be cached or it should send the request directly to origin server, this process needs to be recognized using some factors which is called Cache Keys. We call what is not in the cache keys, Unkeyed components. which is being used to exploit this vulnerability. If the cache keys of a request matches the cache key of another request, web-cache consider them to be equivalent, as the result, it’ll serve the cached response to both of them, this is where the attacker exploit the vulnerability.

4. Constructing a web-cache poisoning attack

  • Identify and evaluate unkeyed inputs
  • Get a harmful response from back-end server
  • Get the response from cache

- Identify unkeyed inputs

Any web-cache poisoning attack relies on manipulating unkeyed inputs to get a change back-end server’s behavior and get a harmful response and then serve it to web-cache. For example: If application uses Host header to generate or load some contents in webpage, the attacker might try using X-Forwarded-Host which is an unkeyed header to change it.

- Get a harmful response

For instance:

GET / HTTP/1.1
Host: example.com

Server uses Host to load an image:

<img src="example.com/img.jpg" />

(Changing Host’s value directly doesn’t lead to a web-cache poisoning, because Host is a keyed header)

So attacker may change the request like this and use:

GET / HTTP/1.1
Host: example.com
X-Forwarded-Host: example.com:80" onload="alert(origin)" "

and then, the img tag will be look like this:

<img src="example.com:80" onload="alert(origin)" "/img.jpg" />

which is an XSS, attacker send the request several times, cache saves it and then, we got a Web-Cache Poisoned XSS; each user whom visiting this webpage will get a alert pop-up.

Note: it may not be that easy, we just check an easy example

- Get cached response

After serval requests with the crafted payloads, attacker will see one of these headers on response:

Cache: hit
Cache-Control: public, max-age:3600
X-Cache: HIT

which is mean the response is coming from cache.

5. Preventing

  • Don’t cache sensitive or dynamic data
  • Use strong cache keys
  • Lock down dangerous headers
  • Separate dynamic and static data
  • Validate headers

← Return to OWASP Notes

← Back to blog