Web Cache Poisoning

In this blog we will be learning about Cache, caching headers and the basics of Web Cache Poisoning.

Cache Functionality

A web cache, often referred to simply as a cache, is a mechanism used to store copies of resources that is accessed frequently. Web caches sit between servers and users, storing responses to requests for a fixed time.

When a similar request is made, the cache serves the stored response directly, reducing server load.

Cache Keys

Caches identify equivalent requests using cache keys, which typically consist of the request line and Host header. However, some headers or cookies that are not included when generating the cache key can be manipulated by attackers or users to contaminate the cache with controllable inputs. Only components included in the cache key are considered, while others are ignored. When a cache key matches a previous request, the cached response is served until it expires.

Cache Specific Http Headers

For detecting and understanding the caching mechanisms of web servers we can look for certain cache related headers. Let’s see a response header to understand caching.

Here, the Cache-Control header holds value for max-age which holds the value for how long before the chache must be revalidated here the value is 604800 seconds. Other value may be no-cache which says that the response may be cached but it must be revalidated after each use. Other header such as no-cache states that no part of response is cached in the server. These headers, helps us understand the basic cache control mechanisms used by web applications.

How does Web Cache Poisoning Works?

Web cache poisoning is an advanced attack where an attacker manipulates a web server and cache to serve harmful responses to users. This technique involves two phases: eliciting a dangerous response from the server and ensuring it is cached and served to victims.

This vulnerability majorly focuses on exploiting weaknesses in caching systems used by web servers, proxies, and content delivery networks (CDNs).

Demonstration

Let’s see a small demonstration of how web cache poisoning could be detected and exploited in a web application. For the demonstration i will be using portswigger academy’s lab about Web cache poisoning.

1. Detecting Web Cache Poisoning Vulnerability

Firstly, to detect Cache Poisoning we must see how cache control mechanisms have been implemented in the web application.

Let’s navigate through the application and see the Http request sent from the application.

This was the request and response to access the “/” root page of the website.

Also, we can see that caching was implemented in the application where, the X-Cache header had value hit and miss indicating that the request was served from cache or not. So, now we know that we have a potential web cache poisoning target.

To create an impact, we must identify an unkeyed header that is ignored by the caching mechanism. If we can inject input into the header and have it reflected in the client’s browser, the impact can be significant. For testing the unkeyed header we can use tools to find hidden Headers used in the application. Let’s use param miner to detect such headers.

Select the Header Poison option and fuzz the request.

Here, we identified that the web cache server was using an unkeyed header x-forwarded-host. This can become our sink to poison the cache. Now let’s exploit.

2. Exploiting Web Cache Poisoning Vulnerabilities

Now, let’s enter any value in the header x-forwarded-host and see where it reflects. For the demo let’s enter value doesItReflect? .

The value is being reflected in the domain and gets appended in the front of the path to access a javascript file. This can be used to change the source of the js itself, we can poison the cache and add a malicious link serving that particular js file. Also, we can inject javascript breaking the script tags. Let’s break the script tag and inject a javascript code.

Here, I have injected alert(document.domain) javascript code and sent the request multiple times to save it in cache. The header X-Cache also notified that the cache is hit and the response is served from the cache. Now, if a random user tries to access the home page before the expiration of the cache, the javascript is injected in user’s web application. For confirmation let's try to access the page from a new private window.

Now, opening the website from a private window triggers the javascript which was injected from the unkeyed header that we sent to poison the cache. So, we have exploited the Web cache poisoning vulnerability to explicitly inject javascript in the victim’s application.

Remedies

• Cache key normalization: Normalizing cache keys can help prevent variations due to input formatting or case sensitivity.
• Cache-control headers: Using headers like “no-store” and “no-cache” can prevent the caching of sensitive data.
• Use web application firewalls (WAF): Deploying a robust WAF can help detect and block cache poisoning attempts.

In this blog we discussed about the basics of web cache poisoning.