Many are most likely already familiar with CDNs, Content Delivery Networks, but in short, a CDN is a service where a site owner can place all static content, such as images or scripts. The following article will go over how to configure a web site to minimize the potential damage if a CDN is hacked.
CDN providers often got a lot of servers spread around the whole world, drastically decreasing the physical distance between the server and the user which allows for faster response times.
The following article will go over how to configure a web site to minimize the potential damage if a CDN are hacked. As an attacker could change all content as well as intercept user credentials with an hacked CDN it has become an important question that has received way too little attention.
The advantages of using a CDN are many, for both smaller as well as bigger sites. It improves the loading speed for the customer, lowers the pressure on your server and can often save you money.
It can be summarised in a few key points:
- Closer physical locations cause faster response times
- As this is all they do they are able to focus their knowledge on delivering data
- If popular scripts are loaded from one of the biggest CDNs, they have most likely already been cached in the user’s web browser
- If the website all of a sudden encounters a great traffic peak the service can quickly be scaled up to handle the pressure
Just a few years ago, this was only available to bigger sites as the starting cost was huge. Today even small personal blogs could take advantage of those services, and as CloudFlare even offer a plan for free there are no real economical drawbacks.
The problem is of course if the CDN decides to go malicious, or are hacked by an external part. The CDN are in control of the scripts executed on the website and could potentially in such case modify all visible content or steal sensitive credentials of the users.
By default the CDN is another part that a site owner must trust as much as they trust their own server.
A few questions to keep in mind when considering a CDN:
- Is the CDN trustworthy?
As the CDN has access to visitor information it is important to trust it. Go for the bigger ones or reach out to the people behind it to determine if they are trustworthy.
- What if the CDN gets hacked?
As with any service the CDN could get hacked. Make sure that the people behind the CDN seem to know security, by either checking its reputation online or reaching out to them directly to see how they handle security.
- What says the uptime will be good at all?
If the CDN goes down the content hosted there cannot be accessed. Make sure to be sure of its reliability before making the switch.
With all that said the hope is not out as there are methods to prevent all these, causing almost only advantages to be left.
An old simply privacy related one trick
Buy an additional domain, a dotcom is usually about $10/year. By doing so cdn-example.com can be used instead of cdn.example.com, and data are more easily seperated. This goes for cookies, other personal data, and also limits the potential exposure against client-side attacks such as XSS.
Integrity is a flag that can be included in script-tags that specify the hash of a accepted script. An example of this can be seen below:
That way it does not matter if the CDN tries to go malicious by changing the content, or if they get hacked and someone replaces the script with something else. If the script does not match the hash the user’s web browser will simply reject it altogether.
Please note that files containing the word ‘latest’ often update regularly, as well as ones that do not contain a version number. In those instances this method cannot be applied, and we would recommend to look for a specific version instead.
When using the integrity attribute the crossorigin attribute is also required. That is implemented by simply adding
in the script-tag.
This is because of restrictions in the spec on which assets that are eligible for integrity checking. What this does is stopping any credentials to be sent along with the request. I.e., no cookies, no Basic Authentication etc.
If the CDN decides to change the script for any reason it would be good if the website did not stop working altogether. To prevent that a backup solution can be implemented, where there is a check in place to see if the included script from the CDN was fully loaded, and if not just load it again but this time from the server itself.
This would also protect against the CDN being down for any reason.
How this is done varies between each library that is included and might not be the easiest thing to implement, but is a good complement when possible.
How everything looks together
Linus Särud, Security Researcher, Disposable mail