Do you trust your cache? – Web Cache Poisoning explained

As we are all currently confined to a life at home during the pandemic, it has become more important than ever that our favorite web applications stay fast and reliable. Many modern web applications use web caches to keep up with these demands. While this works wonders from a performance perspective, it also opens up new attack vectors. One of these new attack vectors is called Web Cache Poisoning. 

Web cache poisoning is the act of tricking the web cache to store malicious content that will in turn be served to other users. The three most common ways of poisoning web caches are request smuggling, request splitting and poisoning using unkeyed inputs (also known as practical web cache poisoning). This article will only focus on cache poisoning using unkeyed inputs as it is the most popular way of conducting web cache poisoning at the moment of writing much thanks to the brilliant research done by James Kettle.

How does caching work?

In order to understand what web cache poisoning is and what its consequences are, we need to first take a look at how web caches work. Caching means that you store frequently accessed content in order to speed up subsequent requests to access that content. Some examples of caches include memory caches, DNS caches and web caches. 

A web cache works by storing HTTP responses for a certain amount of time based on a set of rules. The main way a web cache keeps track of what response content to cache, is through something called cache keys. 

Cache keys are parts of a HTTP request that the cache will use to uniquely identify a response. Typically a cache key consists of the values of one or more response headers as well as the whole or part of the URL path. A typical request can look like this:

GET /totally/real/site?isItForReal=true HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0...
Accept: */*
Cookie: language=en;

The parts of the request that are marked in red represent the cache key. If the cache can match the cache key to an existing record in the cache it will respond with that record instead of passing the request along to the origin. This reduces the amount of requests that the origin has to handle, which leads to lower cost for the application owner and often faster response times for users. Web caches can either be implemented locally or through a CDN.

The idea is that cache keys are supposed to reflect any changes to the response. Issues start to happen when parts of the request other than the cache keys can modify the response content. 

Unkeyed and used inputs

It turns out that many applications allow inputs such as query strings, header values and cookie values that aren’t part of the cache key to be reflected in the response. Inputs that aren’t part of the cache key are called unkeyed inputs. Inputs that affect the response are called used inputs. 

The issue becomes clear when you look at these two requests. The application uses a header called X-User-Background to determine what background color the page should have. The problem is that the X-User-Background header is not cached but it is still being used to determine what the response should look like. The unkeyed and used inputs are marked in blue.

First Request
GET /my/vulnerable/page?isVulnerable=true HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: */*
X-User-Background: pink
Cookie: ASP.NET_Session=23131;
Second Request
GET /my/vulnerable/page?isVulnerable=true HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: */*
X-User-Background: blue
Cookie: ASP.NET_Session=31313;

Assuming that the first request gets cached, both requests will receive a page with a pink background even though they have different X-User-Background headers. All because the X-User-Background header was used but not cached. Now in this case it would be more of a nuisance to users than anything else, but what if someone discovered the unkeyed input could be used for more malicious things than changing the background for other people.

Why does this happen?

This often happens when you set a cache layer in front of an application that has previously worked without a cache. If those who implement the web cache are unaware of how the inputs affect the responses of the application, there is a risk that they may leave some used inputs unkeyed.

Furthermore, a lot of different frameworks use request headers to generate responses that most are not aware of. Since these frameworks often abstract away low level logic such as handling request headers, these types of issues often fly under the radar.

An example of Web Cache Poisoning

So how would an attacker abuse this behaviour? This is best illustrated with an example. Let’s say that there is a website that has a header, called X-Who-Made-This, whose value is reflected in the HTML response body. A normal request looks like this:

GET /my/vulnerable/site?background=pink HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
X-Who-Made-this: Imadethis
Accept: html/text
Cookie: ASP.NET_Session=23131;

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
...

As we can see in the response, we are getting a Cache-Control header back, indicating that the application is behind a cache. Furthermore, the X-Who-Made-This header is reflected in the response. If the X-Who-Made-This header value is not properly sanitized it means that the page could be susceptible to a reflected XSS. Even better, if the X-Who-Made-This header value is unkeyed it means that web cache poisoning may be performed. We can confirm this by sending a second request right after the first. If the response is identical to the response of the first request, the endpoint is likely to be vulnerable to web cache poisoning.

GET /my/vulnerable/site?background=pink HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
X-Who-Made-this: Youmadethis
Accept: html/text
Cookie: ASP.NET_Session=23131;

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
...

Once the vulnerability is confirmed an attacker will be able to inject a malicious script tag into the page and have the page stored in the cache. This can be accomplished by sending the request below.

GET /my/vulnerable/site?background=pink HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
X-Who-Made-this:
Accept: html/text
Cookie: ASP.NET_Session=23131;

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
...