Web Cache Poisoning 101

Introduction
In this post, we will discuss the web caching's working mechanism and the security issue related to this technology, where an attacker can change the displayed page temporarily for all visitors. Also, we will discuss the mitigation techniques.

So, what is "Web Caching"?
Web caching is a technique that places a "Caching proxy" between the client and backend server (webserver).

The Caching's benefit
The main benefit of "Caching" is to provide the information in a fast manner without the need to ask the "webserver". For example, a news website that displays the information on a daily basis (24 hours) can put more than one caching proxy to minimize the load on the backend server. Usually, the webmasters configure the "expiry time" before the caching proxy fetches the new information.

Caching's Mechanism
The most important question: How does the "cache" know if it has a saved response for a specific request? Well, there are many key factors to answer this question. For example, "expiry time" if the time is expired the caching server will fetch the response from the webserver and cache it. Another factor is the concept of Caching "keys". For example, Host in HTTP Header and URL path is usually considered as "cache key". There is another important concept which is "unkeyed inputs". These inputs are used on the pages, however, it is not considered as "cache keys".
For example:

First Request

Second Request

Here, the users can choose the website's background color. In case the web cache only considers the Host and URL path and the first response gets cached, all users will see pink background regardless of what color they choose for a specific amount of time.

Another practical example: This website considers the Host and URL path as cache keys. However, Cookie value "fehost" is used in the page but it is "unkeyed"

Here, the attacker visits the page and notices "fehost" value is reflected on the response. Note, the value of "X-Cache: hit". This means the response came from the web cache and not from the webserver.

Now, the attacker visits a random URL path. Note, "X-Cache: miss". Since the web cache doesn't have a response for this URL path. This response came from the webserver!

The attacker waits for some time to increase the chance for cache expiry time. Also, the attacker changes the value of "fehost". Note, "X-Cache: miss". The response came from the web server and it contains the attacker-specified value!

Again, the attacker waits for some time and inject XSS payload in "fehost"

The attacker repeats this request multiple times. Until the response "X-Cache: hit" means the response gets cached!

Visiting the attacker URL results in alert(1)

The attacker repeats the same steps on the main landing page.

Since the web cache is poisoned for a temporary time. any user will visit the website will be a victim.

Web Caching's Danger
Web sites that use users inputs as "unkeyed" may vulnerable for various kinds of attacks such as XSS, phishing .. etc

Conclusion
The best protection is to disable the web cache. Also, the web cache should only cache static pages and not use any user input in its response.

References
1-What-is-web-cache-poisoning
2-Do-you-trust-your-cache-web-cache-poisoning-explained
3-Portswigger-web-cache-poisoning