CSP - Content Security Policy

What is CSP?
CSP stands for Content Security Policy. The aim of the policy is to mitigate injection attacks faced by website. It is currently a ‘Working Draft’ from w3c.

Availability
This is available in Firefox, Chrome and to a limited extent IE

How it works
Normally <scripts> are inline with HTML and the browser has no way of knowing whether the script is part of the HTML or if it has been injected by an attacker. CSP forces a developer to totally separate code from data, by moving all scripts to an external file. This will involve a lot of work by the developer.
The developer then declares a white list of trusted locations that scripts can be loaded from. The browser enforces this list only allowing scripts from these trusted locations.
All other scripts are blocked automatically and any script in violation of the policy will trigger an error. 

Implementation
To implement CSP, developers need to include the Content-Security-Policy response header in each HTTP response. It is supplied in the header because it is quite hard for an attacker to forge.

An Example policy

Default-src ‘self’; declares to the browser that by default it should accept resources from the sites origin

This is the default directive but can be overridden by more specific directives for other resources as below:

Img-scr *; allows images from any location, the * indicates anywhere. This covers CSS images and images taken from other locations.

Object-src [url]; declares to the browser that it can accept <object> and <embed> from the URL’s listed

Script-src trustedscripts.example.com; tells the browser to only accept scripts from the location specified, any other script will be blocked. This is how attacker scripts will be prevented from running.

The list of other resources that can be specified includes

Default-src, script-src, object-src, style-src, img-src, media-src, frame-src, font-src, connect-src

These directives cover the following resources:

XSS Mitigation
The script-src is the key to blocking XSS.
Since whitelisting is used, the developer needs to declare where all scripts are located. Not including the attacker’s site on this list is the basis of how the browser knows not to run his script. 

Example

Will this script execute?

Yes because we declare that we accept scripts from ‘self’ our own origin

Example 2
Will this one execute?

No because it is an inline script and the browser does not know if we coded it inline or if an attacker injected it there. This could reflect the attacker’s intent rather than the server’s intent and so will be blocked.

If we indeed meant to run this script then we need to take it out of line and put it in the same location as the rest of our scripts. Another option is to include the token ‘unsafe-inline’

This states that ‘self’ can include inline scripts such as the one above. This however is counterintuitive since we are no longer ensuring that valid scripts are called from a trusted location and we are accepting any scripts that are inline and these could be scripts belonging to an attacker since a browser cannot tell where the inline scripts come from.


Deploying CSP
There are four basic steps to CSP deployment
1. Move inline scripts out of line
 

Instead of using
    <script>
           alert(“I am inline”);
    </script>

Use:
<script-src =”libs/Out-of-line.js”></script>
 

2. Move event handlers out of line – since these too can be injected

 
Instead of using:
<a href="#" onClick="alert('you clicked me')">Click Me</a>

Use:
function someEvent()
{
    alert("you clicked me");
}
var obj = document.getElementById("someElementId");obj.addEventListener("click", someEvent);
<script src=’events.js’</script>
<a href="#" id="someElementId">Click Me</a>

3. Remove Eval (optional).
Eval can be a point of injection for XSS when untrusted strings are Eval’d.
setTimeout is more or less the same, as this is essentially Eval’d also. Instead pass a function, which would be called and then nothing is sent to Eval. Eval is disabled by default in CSP so if its use is required it can be enabled using the tag script-src ‘self’ ‘unsafe-eval’
 

4. Add a script-src directive to content security policy
Content-Security-Policy: script-src ‘self’


Points to note
Setting Content-Security-Policy: default-src ‘none’ ensures an extremely safe site where no resources can be accepted i.e no functionality will work!

Start with default-src ‘self’ – load things from your origin and as you notice functionality that has stopped working you expand the directive, adding image-scr * to ensure images load etc. Taking an approach like this ensures you can refine your policy over time.

CSP also has a report only mode which allows you to set your directives but they are not enforced by the browser. The browser simply reports on the directives set. This function is good for testing CSP when starting off deployment to check how many reports are coming in on certain directives in the policy.

Conclusion
CSP can prevent XSS. It is relatively easy to implement, the majority of the work being on the developer who has to separate all the code from the data, moving scripts and event handlers to an external location. Once this task is done, however, CSP seems relatively easy to maintain, allowing refinement and adjustment of the policy.