An Introduction To Content Security Policy

5 years ago

Stuart Larsen #article


This article is a very introductory background to Content Security Policy, it is intended for individuals who have some technical experience, but have never dug into content security policy.

Content Security Policy is not a trivial topic, unfortunately a lot of people get it wrong (Google Research).

What is Content Security Policy?

Websites are made up of a lot of different content. There is the HTML that scaffolds the web page and gives it text. There’s the CSS that applies styles and makes it pretty. There’s the javascript that makes the web pages dynamic. There’s also images, videos, fonts and more.

Content Security Policy is a mechanism for enforcing what content (scripts,styles,fonts,images,etc) can be loaded and used by a website.

Which on the surface is a little silly. As the website owner, don’t you already get to decide what content is allowed to be used by a webpage? As a website owner you are already telling your users what content to load when you give them an HTML document.

example http request to catbook

Figure 1: A browser requesting a web page

The resulting HTML document from catbook will load the correct images, stylesheets, javascript, fonts etc. So why would I need Content Security Policy (CSP) to restrict it further?

You need Content Security Policy (CSP) to prevent cases where the web page isn’t working in the way you intended. There’s a couple of ways that this could happen, but the one that content security policy was built to solve is a prolific web vulnerability called Cross Site Scripting (XSS).

Cross Site Scripting

Cross Site Scripting is the unwanted/malicious execution of Javascript in a web page.

Let’s imagine that we created a website called Catbook: Facebook for Cats. It’s a social network where cats can interact with other cats through the interwebs.

Let’s imagine it had a URL such as:

https://catbook.com/profiles?userName=madCatChessy

example XSS catbook

Figure 2: The HTML content of the URL and browser rendered view

We can see that the username "madCatChessy" is taken from the URL, and then placed into the HTML by the web server, and then rendered by the browser.

So, now the fun part. What if instead we went to a web page like: https://catbook.com/profiles?userName=<script>alert(1)</script>

example XSS cat book

Figure 3: Javascript Injection into a web page (Cross Site Scripting)

Uh oh! So the webserver thought that <script>alert(1)</script>was the name of a cat. So it took the name and injected it into HTML. The HTML was then rendered by the browser and the <script>alert(1)</script>was interpreted as Javascript and not as a username.

So if you were evil you could send this URL to all your cat friends, and scare them: https://catbook.com/profiles?userName=<script>alert('Your catbook account has been deleted')</script>

While a somewhat funny prank, there’s actually a lot of truly bad stuff you could do. For example:

  • You can use it to “steal someone’s session" and effectively log in as them. Meaning you can take over people’s account (somewhat).
  • You can send a malicious link to scare other people into doing things you want (‘Your computer has been hacked!! Download this (fake) antivirus’).
  • You could use it to read everything private that they’re doing and then blackmail them. You could use it to read all the HTML elements on that page and wait till they type in their credit card information or something else sensitive.

It’s a very serious problem, which is why all major browsers spent non-trivial time implementing Content Security Policy (along with other protective measures) to prevent these issues.

How does Content Security Policy prevent XSS?

First, Content Security Policy (CSP) disables any inline javascript from running, and second it requires that you explicitly list which external origins you allow your website to download javascript from.

By only allowing certain origins to be the source of javascript(and explicitly not allowing inline javascript) we can reduce the amount of allowed executable javascript.The goal is to reduce the amount of allowed executable javascript to the point that only the javascript that can be executed is the javascript we originally intended.

Demo Content Security Policy

Above is an example Content Security Policy. The most common origin is ‘self’ which means that on catbook.com I can load and execute javascript from <script src="https://catbook.com/app.js"/>. You could also use cdn.catbook.com and then load javascript from <script src="https://js.catbook.com/vendor.js"/>. What is important is the origins are trusted.

The same restrictions can be done for all types of content, but javascript is the most important.

How do I get started?

The easiest way is to have an automated tool generate a policy for you. Csper Generator is a chrome/firefox extension that automatically generates Content Security Policy for any website.

A full guide on generating a content security policy.

Conclusion

I hope that content security policy makes a little bit more sense now. If you have any questions, please feel free to reach out! stuart@csper.io

Automatically Generating Content Security Policy

How to automatically generate content security policy (CSP) headers.

Content Security Policy

Technical reference of content security policy

Deploying Content-Security-Policy

Guide on how to deploy content-security-policy

Looking for tools to make CSP easier?

Csper has the tools to help you understand, deploy and manage your content security policy. Get started in minutes. Report aggregations, classification, analysis, alerting, realtime and more. Free 14 day trial.