Identifying Web Cache Poisoning and Web Cache Deception: How Tenable Web App Scanning Can Help

Web cache poisoning and web cache deception are two related but distinct types of attacks that can have serious consequences for web applications and their users. Learn how these flaws arise, why some common attack paths are so challenging to mitigate and how Tenable Web App Scanning can help.

Web cache poisoning and web cache deception are attack types that impact modern web applications. These attack vectors take advantage of web caches, which are web server components used to improve performance and reduce server load, and which can be manipulated by attackers to tamper with web applications.

Although they both involve web cache abuse, the two vulnerabilities are quite different. Web cache poisoning enables an attacker to introduce malicious content into the cache, which can then be served up to legitimate users. This can lead to injection attacks, the distribution of fraudulent content and even breaches of users privacy. On the other hand, web cache deception exploits a weakness in the way applications interpret cache settings, allowing attackers to manipulate requests and responses, so that they can perform unauthorized actions or leak sensitive information.

Although these vulnerabilities have not always been ranked in risk lists such as the OWASP Top 10 Web Application Security Risks, their importance is growing as web applications increasingly rely on caching to optimize performance. Careful configuration and constant monitoring of web caches are therefore essential to mitigate these risks.

What are web cache poisoning and web cache deception?

Let’s clearly understand the role of a cache: to temporarily store frequently-used or calculated data so that it can be accessed faster, enhancing the user experience. Caching improves system performance and overall efficiency, particularly by reducing server load and optimizing network traffic.

It is also important to understand that the server relies on a key-entry caching system when deciding whether to cache a page. In a key-entry caching system, data is stored in the cache in association with a unique key. When a request is received, the cache system uses the corresponding key to check whether the associated data is already present in the cache. This system is commonly used with, for example, a language cookie to serve cache data according to the user's language preferences.

Web cache poisoning occurs when an attacker is able to inject malicious data into a web cache, causing the cache to serve the malicious data to other users who request the same resource. This can lead to a variety of attacks, including cross-site scripting (XSS), cross-site request forgery (CSRF) and data exfiltration. 

Cached copies of frequently accessed resources can be located on the server or on a separate caching server. 

Web cache deception occurs when an attacker tricks a web cache into serving stale or incorrect data to a user. This can be achieved through a variety of means, including manipulating cache headers, exploiting cache-timing vulnerabilities, or using other techniques to force the cache to serve out-of-date data. 

When a user requests a resource, the cache may serve sensitive, obsolete or incorrect data instead of the latest version, which can lead to a variety of attacks, including data exfiltration, denial of service or unauthorized access.

Detecting web cache poisoning and web cache deception

Web cache poisoning and web cache deception can be difficult to detect, as the malicious data is often served from a legitimate cache. However, some signs may indicate a cache attack, including unexpected behavior or content on a webpage, unexpected redirects or unexpected errors. Additionally, checking responses and using cache-busting techniques can help detect potential cache attacks. Cache-busting techniques involve adding unique query strings or headers to requests to prevent the cache from serving stale data. 

Below we’ve included screenshots from sample attacks we conducted in our test labs.

The first thing to check is that the server is trying to cache the resource. Response headers are an excellent source of information for this. For example:

• The “Age” header indicates the time in seconds that the resource has been stored in a proxy cache.
• The “Cache-Control” header contains directives for controlling caching.
• The “Pragma” header can return information about the cache server.
• Some caching servers can even add specific headers, such as Varnish.

Exploiting web cache vulnerabilities

To exploit a web cache poisoning vulnerability, once a web application that uses caching has been identified, the attacker can craft a malicious request that includes the desired payload and manipulate the cache control headers to ensure that the malicious data is cached.

In the example below, the user's “User-Agent” is reflected in the page and the page is cached. Although the case seems basic, it has been possible to identify several sites replicating this case.

However, injecting a payload is not the only possible vector for this vulnerability. Other possibilities include :

• A denial-of-service attack through headers like “x-forwarded-scheme”: Using this header generally returns a 302 error to the current page in https. If the response is cached, this causes an infinite loop making the page inaccessible.
• Using an illegal header such as “\”, which means that the server will respond to a 400 error page. If this page is cached, it will be inaccessible to other users.

However, caching and behavior depend on the service used. For example, by default Akamai caches for 10 seconds the error responses with HTTP codes 204, 305, 404, 405, and 501. This does not preclude that an attacker uses a script to automate to enforce caching every 10 seconds.

There are many cases and variants of web-cache poisoning DoS attacks. A site dedicated to several of these cases even exists.

To exploit web cache deception, the most common technique is to exploit the main purpose of a cache server: to distribute static resources.

To determine whether a resource should be cached or not, some services such as Cloudflare rely solely on the URL extension. If the resource is a JavaScript (JS) or Cascading Style Sheets (CSS) file, for example, it will automatically be cached.

The whole idea of the exploitation is to add an extension such as .js or .css to a URL to force caching of the page. This attack is more interesting when it allows access to sensitive information such as a user's personal data or authentication secrets.

Prevention and mitigation recommendations

Web cache poisoning

• Validating all user input can help prevent attackers from injecting malicious data into web caches. Input validation should include checking for unexpected characters, sizes and formats.
• The “Vary” header can be used to allow the server to specify which parts of the HTTP request should be taken into account by the cache.
• Using secure caching mechanisms can help ensure that data stored in caches is not tampered with or modified. Secure caching mechanisms can include using cryptographic signatures or hashes to verify the integrity of cached data.

Web cache deception

• Revalidate caching rules to avoid caching sensitive URLs.
• Don't rely solely on the extension for caching, but also on the resource's “Content-Type”.
• Some services offer dedicated remediation. CloudFlare, for example, offers Cache Deception Armor.

Use Tenable Web App Scanning to detect web cache poisoning and web cache deception flaws

Tenable Web App Scanning can identify web cache poisoning and web cache deception vulnerabilities through the classic scan andAPI scan feature, including the following dedicated plugins:

• Plugin 113580 to detect generic web cache deception
• Plugin 113338 to detect generic web cache poisoning
• Plugin 114006 to detect DoS web cache poisoning

To get more information, visit the Tenable Web App Scanning page.