We have been used to securing web pages with security headers to fend off cross-site scripting attacks, clickjacking attacks and data theft. Many of these headers are now being deprecated and browser may no longer respect these header settings. Instead, we can use a content security policy to reduce the risk to our web content and its users. A content security policy, or CSP for short, is usually set as a HTTP header and allows you to instruct the browser to ensure only your approved resources will run in the browser context.
CSP’s are universally supported, and also allows reporting of policy violations, which can aid in detecting hacking attempts.
Mozilla Developer Network has great documentation on the use of CSP’s: MDN: HTTP Headers.
Client based attacks
When you build a web site, you should create a basic threat model for your project. Think about what type of attacks that are likely to occur, and build good defensive strategies to protect against such attacks. When building a threat model it is invaluable to have access to threat intelligence to support the assessment. Common attacks we would like to include are cross-site scripting, injection of malicious scripts and clickjacking.
CSP by example
We want to make it even easier to understand how CSP’s can be used, so we have made some demonstrations for the most common directives we should be using. Let us first start with setting the following header:
Content-Security-Policy: default-src ‘self’;
We have created a simple Flask application to demonstrate this. Here’s the view function:
- Blocks media resources from other domains, including images
- Blocks stylesheets from external domains, as well as inline style tags (unless explicitly allowed)
Blocking untrusted scripts: XSS
Content-Security-Policy: default-src: ‘self’;
We have implemented this in a route in our Python web app:
Let us first try the following url: /xss/safe/hello: the result is injected into the HTML through the Jinja template. It is using the “safe” filter in the template, so the output is not escaped in any way.
We see here that the word “hello” is reflected on the page. Trying with a typical cross-site-scripting payload: shows us that this page is vulnerable (which we know since there is no sanitation):
We did not get an alert box here, saying “XSS”. The application itself is vulnerable, but the browser stopped the event from happening due to our Content-Security-Policy with the default-src directive set to self, and no script-src directive allowing unsafe inline scripts. Opening the dev tools in Safari shows us a bunch of error messages in the console:
The first message shows that the lack of nonce or unsafe-inline blocked execution. This is done by the web browser (Safari).
Further, we see that Safari activates its internal XSS auditor and detects my payload. This is not related to CSP’s, and is internal Safari behavior: it activates its XSS auditor unless there is an X-XSS-Protection header asking to explicitly disable XSS protection. This is Safari-specific and should not be assumed as a default. The X-XSS-Protection header is a security header that has been used in Internet Explorer, Chrome and Safari but it is currently be deprecated. Edge has removed its XSS Auditor, and Firefox has not implemented this header. Use Content Security Policies instead.
What if I need to allow inline scripts in my content security policy?
Let’s do an example of an unsafe inline script in our template, using a nonce to allow the inline script. Here’s our code:
Remember to make the nonce unguessable by using a long random number, and make sure to regenerate it each time the CSP is sent to the client – if not, you are not providing much of security protection.Nonces are only good if they can’t be guessed, and that they are truely used only once.
Here we have one script with a nonce included, and one that does not have it included. The nonce’d script will create an alert box, and the script without the nonce tries to set the inner HTML of the paragraph with id “blocked” to “Hello there”. The alert box will be created but the update of the “blocked” paragraph will be blocked by the CSP.
Here’s the HTML template:
The result is as expected:
Conclusion: Use CSP’s for protecting against cross-site scripting (XSS) – but keep sanitising as well: defence in depth.
What about clickjacking?
good explanation of clickjacking and how to defend against it is available from Portswigger: https://portswigger.net/web-security/clickjacking.
Here’s a demo of how clickjacking can work using to “hot” domains of today: who.int and zoom.us (the latter is not vulnerable to clickjacking).
Here’s how to stop that from happening. Add the frame-ancestors directive, and whitelist domains you want to be able of iframing your web page.
Content-Security-Policy: default-src: 'self'; frame-ancestors: 'self' 'youtube.com';
Protecting against common client-side attacks such as XSS and clickjacking can be done using the Content Security Policy header. This should be part of a defense in depth strategy but it is an effective addition to your security controls. As with all controls that can block content, make sure you test thoroughly before you push it to production!
This post was originally published on Håkon’s personal blog: https://safecontrols.blog/2020/04/02/protecting-the-web-with-a-solid-content-security-policy/