In April, we wrote about Web Cache Deception attacks, and how our customers can avoid them using origin configuration.
Read that blog post to learn about how to configure your website, and for those who are not able to do that, how to disable caching for certain URIs to prevent this type of attacks. Since our previous blog post, we have looked for but have not seen any large scale attacks like this in the wild.
Today, we have released a tool to help our customers make sure only assets that should be cached are being cached.
A brief re-introduction to Web Cache Deception attack
Recall that the Web Cache Deception attack happens when an attacker tricks a user into clicking a link in the format of http://www.example.com/newsfeed/foo.jpg
, when http://www.example.com/newsfeed
is the location of a dynamic script that returns different content for different users. For some website configurations (default in Apache but not in nginx), this would invoke /newsfeed
with PATH_INFO
set to /foo.jpg
. If http://www.example.com/newsfeed/foo.jpg
does not return the proper Cache-Control
headers to tell a web cache not to cache the content, web caches may decide to cache the result based on the extension of the URL. The attacker can then visit the same URL and retrieve the cached content of a private page.
The proper fix for this is to configure your website to either reject requests with the extra PATH_INFO
or to return the proper Cache-Control
header. Sometimes our customers are not able to do that (maybe the website is running third-party software that they do not fully control), and they can apply a Bypass Cache Page Rule for those script locations.
Cache Deception Armor
Photo by Henry Hustava / Unsplash
The new Cache Deception Armor Page Rule protects customers from Web Cache Deception attacks while still allowing static assets to be cached. It verifies that the URL's extension matches the returned Content-Type
. In the above example, if http://www.example.com/newsfeed
is a script that outputs a web page, the Content-Type
is text/html
. On the other hand, http://www.example.com/newsfeed/foo.jpg
is expected to have image/jpeg
as Content-Type
. When we see a mismatch that could result in a Web Cache Deception attack, we will not cache the response.
There are some exceptions to this. For example if the returned Content-Type
is application/octet-stream
we don't care what the extension is, because that's typically a signal to instruct the browser to save the asset instead of to display it. We also allow .jpg
to be served as image/webp
or .gif
as video/webm
and other cases that we think are unlikely to be attacks.
This new Page Rule depends upon Origin Cache Control. A Cache-Control
header from the origin or Edge Cache TTL Page Rule will override this protection.