With security becoming even more of a hot topic in the web industry, it’s not just hackers and other attackers who are developing new exploits and attacks – the industry is also developing tools and standards to fight back.
One such standard is Content Security Policy. Originally developed in 2012, but not gaining much attention until more recently, the Content Security Policy (CSP) standard is a method to allow websites to indicate to web browsers what technologies they’re using and what other sites they may be loading data from in an attempt to prevent malicious code from being included on the site and being sent to users.
Malicious code and its origins
So why would a website contain malicious code in the first place? While website operators do their best to keep their site secure, there are two ways which malicious code may be uploaded:
1. Most websites allow some form of user participation such as comments, photo upload or other ways a user may be able to upload data. Web sites need to be very careful to review the data uploaded by their users to ensure a malicious user doesn’t upload something which either harms the site or harms other users. In particular an attacker may attempt to upload code to the site which manipulates a user’s browser in a way the site operator didn’t intend. Known as cross site scripting, this is one of the most common attacks on websites and regularly occurs on even large well known websites.
2. Many sites include code not just from their own site, but from other sites as well. Sites can include code from advertising networks to display ads, from analytics providers to collect data on their visitors and from providers of other services such as online chat. These all work by including code from another provider which is then sent to the user’s browser and run. Generally, this shouldn’t be a problem, but it means when you visit a website, you don’t just need to trust the website, but also all the providers they use – which on some sites can be as many as ten or twenty other providers on a single page. In this case attackers don’t attack the site you’re browsing but one of their providers, who then direct your browser to run the malicious code. This is less common, but again some well known websites have been affected.
Content Security Policy to the rescue
So how does having a Content Security Policy (CSP) protect against this? CSP works as a whitelist, allowing site owners to specify only certain types of content which may appear on their site and where it may originate from. The content types, include scripts (code), images, video and audio, fonts, forms and other types of content which may feature on a website. For each type, the site owner can specify whether it’s allowed at all, allowed only from the website, or allowed from a whitelist of specific sites.
For example, online chat functionality requires the loading of a script from the provider, so the owner would need to set the ‘script’ content security policy with the chat providers domain. Once in place the CSP will be sent with the page when a site is visited. It will be checked by the browser, and the browser will enforce the policy, blocking any functionality which has not been explicitly approved by the policy such as malicious scripts or other code which may have been placed on the site by attackers.
Implementing CSP
Creating and implementing a CSP on a website requires some further technical knowledge so is best left to your web developer, but further implementation details can be found as part of CSP implementation tutorials.
The main concern is implementing it correctly – too strict a policy and functionality on the site will be broken. In our example above with the online chat functionality, forgetting to include the provider in the policy will prevent the chat code from loading, and it won’t appear on the website.
Creating a policy for an existing site requires auditing the use of functionality affected by the CSP and ensuring the policy correctly includes all the functionality the site requires to function. This must also be considered during future development to ensure that the policy is correctly updated should new functionality be added or removed requiring the policy to be changed.
At the other end of the scale there’s also the opposite problem – it would be very easy to create a very lax policy which would e.g. allow scripts from all sources, which then removes the very protection that CSP provides. So, in addition to implementing CSP, some care needs to be taken to implement it correctly.
So far it doesn’t seem as though many website owners have implemented CSP yet, with a recent survey indicating far less than 1% of the top sites have implemented it. As with any best practice, it does take some time for these to be adopted by the industry so hopefully we’ll see an increase in these numbers over the coming months and the web will become as safer place because of it.
