Using Cache Deception Techniques to Discover Cache Poisoning Vectors

To find cache poisoning vulnerabilities, the first step is to identify a cache-busting technique. Without a cache-busting method, it is not possible to safely verify whether a site is vulnerable. I have experienced cases where, after reporting cache poisoning attacks, developers removed the ability to perform cache busting as a mitigation. This prevented further testing because, without cache busting, testing could impact live users.

When common cache-busting techniques, such as query parameters or headers, do not work on a target, there are other ways to identify cache-busting techniques. These methods are well known in the context of cache deception attacks but are not widely known as cache-busting techniques.

Deception vs Poisoning

For shared caches:

• If a single URL can produce multiple responses, it may be vulnerable to cache poisoning. Example: The same URL is requested twice, but one request includes a header that triggers an error page. This can lead to CPDoS. There is only one URL (no variations), but multiple possible responses.
• If multiple URLs return the same response, it may be vulnerable to cache deception. Example: An admin page is accessible via multiple URL variations such as /admin and /%61dmin. An attacker can trick a victim into visiting /%61dmin, causing the response to be cached.

To identify cache deception issues, it is necessary to find multiple URLs that map to the same page. This is similar to identifying cache-busting techniques for cache poisoning, where the goal is to discover different URLs for the same endpoint in order to test unique request variations.

Deception technique for busting

Consider a website with a parser differential where the application decodes the URL before routing it to the endpoint, while the cache proxy does not normalize it and instead treats it as-is.

URL: /%41bout

Cache proxy: /%41bout

Backend: /about

This behavior can be used for cache deception attacks if the endpoint returns sensitive information. It can also be leveraged for cache busting.

The word “about” contains 5 characters: a, b, o, u, t. Each character has two possible representations in a URL:

1. Literal form (e.g., a)
2. Percent-encoded form (e.g., %61 or %41)

Since each of the 5 positions has 2 independent possibilities, the total number of combinations is:

2⁵ = 32

This produces 32 variations of the word “about.” Excluding the original literal form, there are 31 alternative URLs that can be used to test a single endpoint.

More chances

This technique limits testing to 31 variations for a specific path in this scenario. Therefore, instead of relying on arbitrary headers, it is more effective to focus on the most likely headers or other exploitable primitives. Identifying additional parser differentials further expands the variation space by increasing the number of possible combinations.

Additionally, the same root cause may exist across multiple endpoints, which allows us to increase the available testing space. We can test the 31 URL variations with different headers against one endpoint. After completing the tests for one endpoint, we can move to another endpoint and test the same set of URL variations with remaining headers. This increases the overall testing space and the chance of identifying a cache poisoning condition.

In some cache deception cases, such as /contact versus /contact.html, the opportunity may be limited to a single variation. In these scenarios, a low cache duration can be used as an advantage, although it introduces constraints. For instance, if the cache duration is 10 seconds, it is possible to test /contact.php within that time window. After the cache expires, the server processes a new request, and since the primary URL is /contact, testing /contact.php does not impact real users.

Low cache durations are uncommon. As cache duration increases, testing time also increases. Even when a low cache duration is present, the impact of attacks like denial-of-service is limited because the effect only lasts for a short period. Despite this limitation, such conditions can still be useful for exploiting issues like XSS.