Article: Improving Web Security with the Content Security Policy

[SitePoint_Articles]

An except from http://www.sitepoint.com/improving-web-security-with-the-content-security-policy/

---

Content Security Policy (CSP) is a security mechanism that helps protect against content injection attacks, such as Cross Site Scripting (XSS). It’s a declarative policy that lets you give the browser a whitelist of where it can load resources from, whether the browser can use inline styles or scripts, and whether it can use dynamic JavaScript evaluation—such as through the use of eval. If there’s an attempt to load a resource from somewhere that isn’t on this whitelist, loading of that resource is blocked.

How it Works

CSP is currently a Candidate Recommendation published by the W3C WebApplication Security Working Group. It’s delivered to the browser via the Content-Security-Policy HTTP header, which contains one or more directives that whitelist domains from which the browser is allowed to load resources. CSP 1.0 has the following directives:

• default-src
• script-src
• object-src
• style-src
• img-src
• media-src
• frame-src
• font-src
• connect-src

The default-src, as the name suggests, sets the default source list for the remaining directives. If a directive isn’t explicitly included in the CSP header, it will fall back to using the values in the default-src list.

All directives follow the same pattern:

• self is used to refer to the current domain
• one or more URLs can be specified in a space-separated list
• none indicates that nothing should be loaded for a given directive e.g. object-src 'none' indicates that no plugins—such as Flash or Java—should be loaded.

At its simplest, we could define a CSP to load resources only from the current domain as follows:

Content-Security-Policy:	default-src 'self';

If an attempt to load a resource from any other domain is made, it is blocked by the browser, and a message is logged to the console:

If an attempt to load a resource from any other domain is made, it is blocked by the browser, and a message is logged to the console:

By default, too, CSP restricts the execution of JavaScript by disallowing inline scripts and dynamic code evaluation. This, combined with whitelisting where resources can be loaded from, goes a long way to preventing content injection attacks. For example, an XSS attack attempt to inject an inline script tag would be blocked:

As too would any attempt to load an external script that wasn’t included in the CSP:

Paths aren’t currently supported in the URLs, so you can’t lock down your site to only serve CSS from http://cdn.example.com/css. You have to make do with specifying the domain only—for example, http://cdn.example.com. You can, however, use wildcards—for example, to specify all subdomains of a given domain, such as *.mycdn.com.

Subsequent directives don’t inherit their rules from previous directives. Each directive you include in the CSP header must explicitly list the domains / subdomains it allows. Here default-src and style-src both include self, and script-src and style-src both contain http://cdn.example.com:

Content-Security-Policy:    default-src 'self'; 
                            style-src 'self' http://cdn.example.com; 
                            script-src http://cdn.example.com;

If you need to use data URLs for loading resources, you’ll need to include data: in your directive—for example, img-src ‘data:’;.

Aside from listing domains, two further features supported by script-src and style-src are unsafe-inline and unsafe-eval:

• unsafe-inline can be used by style-src and script-src to indicate that inline <style> and <script> tags are allowed. CSP uses an opt-in policy. That is, if you don’t include unsafe-inline, then all inline <style> and <script> tags are blocked. unsafe-inline also permits inline style attributes for CSS, and permits inline event handlers (onclick, onmouseover etc.) and javascript: URLs (such as <a href=“javascript:foobar()”>).
• unsafe-eval can be used by script-src. Again, it uses an opt-in policy, so if your script-src doesn’t explicitly include unsafe-eval, any dynamic code evaluation—which includes the use of eval, the Function constructor, and passing strings to setTimeout and setInterval—is blocked.

Browser Support

Browser support for CSP 1.0 is pretty good, with Internet Explorer being the usual elephant in the room: IE10 and IE11 have partial support for CSP via the X-Content-Security-Policy header, but even then they only appear to support the optional sandbox directive.

---

Continued at http://www.sitepoint.com/improving-web-security-with-the-content-security-policy/