Protecting Against CDN Cache Poisoning

Recently, a new type of denial of service attack has surfaced that directly target CDNs. The so called cache poisoning attack works by poisoning the responses cached from the origin server.

What is cache poisoning and how does it work?

Generally a CDN works by getting a response from the origin server and then caching that locally to deliver to end users. However, this presents a unique threat where an attack can send a malicious request through the CDN to force the origin server to return a malformed response or error message that would then be cached on the CDN and returned to other users.

In some cases, this could then result in a denial of service as real users would be served an error message instead of the actual files. In an extreme case, an attacker might run these requests in a loop or on a big scale, essentially preventing the actual content from ever loading correctly.

How do we protect against cache poisoning at BunnyCDN?

At BunnyCDN, we have had this in mind even early on and our caching system was specifically configured to only cache error responses for a very short amount of time of 5 seconds. This largely prevented accidental or malicious attempts to cache invalid responses from the origin.

The 5 seconds caching was selected with two consideraitons. It allows the cache to be short enough to allow legitimate requests to come in, yet long enough to prevent an attacker from being able to overload the origin server.

But there's a catch!

That sounds nice and lovely, but the system we used until now was not perfect. In some cases, the cached responses were not malicious and the server simply had a hiccup which then got cached for up to 5 seconds or a file simply wasn't there one second, but was the next. In those cases, the right thing to do would be to not cache the file at all.

Our Solution: "Cache Error Responses" Setting

At BunnyCDN, we really try to make the setup as easy as possible and already optimized out of the box. On the other hand however, we also want to offer you extremely powerful features and very fine grained control of how content is delivered.

With that in mind, we released a new feature called Cache Error Responses that allows you to either enable or disable the temporary 5 second caching of error responses. The feature is enabled by default, but if your use-case can't afford to cache error responses even temporarily, you can now disable this with a click of a button. When enabled, any response with the status code higher than 304 will no longer get cached at all, making sure that your content will only get cached when it was supposed to be.

With this feature, we give you the full control of how you wish to handle your content and allow you to protect against these types of attacks in the best way you see fit.

If you're interested about the new feature, it's already available in your pull zone manager under the Caching settings panel.