Context

Cache poisoning is an advanced technique used by attackers to exploit the behavior of a web server and cache, which results in harmful HTTP responses being sent to unsuspecting users. This technique involves two phases. Firstly, the attacker must find a way to obtain a response from the main server that contains dangerous content. Once successful, they need to ensure that their response is cached and served to their intended targets. This attack method can be used to distribute various types of attacks, including XSS, JavaScript injection, open redirect, etc. A poisoned web cache has the potential to cause significant damage.

How

To comprehend the origin of web cache poisoning vulnerabilities, it's crucial to have a fundamental understanding of how web caches function. Caching is used to decrease the burden on servers, which would otherwise have to send a new response for each separate HTTP request, resulting in latency issues and a poor user experience, mainly during peak periods.

The cache, which stores (caches) responses to particular requests for a predetermined period, sits between the server and the user. If another user sends an equivalent request subsequently, the cache serves a copy of the cached response directly to the user, without any interaction from the back-end. This reduces the number of duplicate requests the server must handle, significantly lightening its load.

When the cache receives an HTTP request, it must determine if there is a cached response it can serve directly or if it needs to forward the request to the main server for processing. Caches compare a predefined subset of the request components, collectively known as the "cache key," to identify equivalent requests. This typically includes the request line and the Host header. Request components not included in the cache key are considered "cache-blind."

If the cache key of an incoming request matches that of a previous request, the cache considers them equivalent, and it serves a copy of the cached response generated for the original request. This applies to all subsequent requests with the corresponding cache key until the cached response expires.

It's essential to note that other components of the request are entirely ignored by the cache, which we'll examine in more detail later. The impact of this behavior heavily depends on two key factors: the precise caching that an attacker can accomplish and the volume of traffic to the affected page. As the poisoned cache is more of a distribution method than a standalone attack, the impact of web cache poisoning is linked to the harmfulness of the injected payload. Additionally, web cache poisoning can be used in combination with other attacks to increase the potential impact.

The impact of the poisoned response served to users who visit the affected page while the cache is poisoned is determined by the number of users visiting the page. As such, the impact can range from non-existent to massive, depending on the page's popularity. If, for example, an attacker manages to poison a cached response on the homepage of a major website, the attack could affect thousands of users without any further interaction from the attacker. Note that the duration of a cache entry does not necessarily impact the web cache poisoning attack's impact, as an attack can be scripted to re-poison the cache indefinitely.

Building an Attack

In general, creating a basic web cache poisoning attack entails several steps:

Identifying and evaluating cache-blind entries.

To carry out a web cache poisoning attack, one needs to manipulate cache-blind entries like headers, which web caches overlook when determining whether to serve a cached response. These entries can be used to inject a payload and obtain a "poisoned" response that, if cached, will be served to all users with the corresponding cache key. To build such an attack, the initial step is to identify the cache-blind entries that the server supports.

One way to identify these entries is by manually adding random entries to requests and checking if they affect the response. The effects may be obvious, such as reflecting the entry directly in the response or triggering a completely different response, but sometimes they are more subtle and require investigation. While tools like Burp Comparer can help compare responses with and without the injected entry, identifying cache-blind entries still demands a significant manual effort.

Obtaining a harmful response from the main server.

After identifying a cache-blind entry, the next crucial step is to assess how the website processes it. This is vital for triggering a harmful response effectively. If the entry is not filtered correctly and is reflected in the server's response or is utilized to generate other data dynamically, it can become an entry point for web cache poisoning.

Obtaining the cached response.

Manipulating entries to cause a harmful response is only half the battle, as it is not useful unless the response can be cached. Caching the response can sometimes be challenging as it depends on various factors such as file extension, content type, route, status code, and response headers. Therefore, it is necessary to spend time experimenting with requests on different pages and studying cache behavior to identify how to obtain a cached response containing the malicious entry. Once this is achieved, one can deliver the exploit to potential victims.

Exploiting Vulnerabilities

The outlined process is applicable for identifying and exploiting various web cache poisoning vulnerabilities. Such vulnerabilities can stem from general flaws in cache design or unexpected quirks introduced by the implementation of a specific website's cache.

The subsequent sections will cover the most typical instances of these scenarios, along with interactive labs that illustrate these vulnerabilities and how to exploit them.

How to Prevent

Web cache poisoning can be prevented by disabling caching, which is the most effective method, but may not always be feasible for all websites. For instance, if you adopted a Content Delivery Network (CDN) that has caching enabled by default, you might consider evaluating whether this option suits your website's requirements.

Limiting caching to purely static responses can be another effective approach to prevent web cache poisoning. However, you must be careful about what you define as static, and ensure that attackers cannot trick the main server into fetching their malicious version of a static resource instead of the authentic one.

Third-party technologies are common in web development, and although you may have a robust internal security posture, you still rely on the security of third-party technology developers. Therefore, it is crucial to understand the security implications of any third-party technology before integrating it, as it may expose vulnerabilities that attackers can exploit.

In the case of web cache poisoning, you should assess which headers are supported by your CDN and disable any unnecessary ones, as attackers can manipulate obscure request headers to expose vulnerabilities. Excluding something from the cache key for performance reasons is not recommended, and instead, you should rewrite the request. You should also avoid accepting large GET requests and fix client-side vulnerabilities, as they may become exploitable due to unpredictable quirks in cache behavior.

Overall, the prevention of web cache poisoning requires a thorough understanding of potential vulnerabilities and careful evaluation of caching options and third-party technologies used on your website.