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 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
PATH_INFO set to
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
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
text/html. On the other hand,
http://www.example.com/newsfeed/foo.jpg is expected to have
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
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
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.