NovoGeek's Blog (Archive)

In my previous post, “The uncontrollable web platform”, I have discussed at a high level the core security policy current browsers have (i.e., Same Origin Policy, SOP) and why it is insufficient to secure the modern web. As said in the post, researchers have put in lot of efforts to design stricter and smarter policies.

Several policies like BEEP (Browser Enforced Embedded Policies), SOMA (Same Origin Mutual Approval), Browser Enforced Authenticity Protection (BEAP), MashupOS (from Microsoft) have been proposed to fix the gaps in SOP. However, each of them had one or more problems with respect to real time implementation. In 2010, Mozilla proposed a new policy called Content Security Policy (CSP), which is the closest fit for current security problems. The goal of this article is to introduce CSP and highlight its importance.

The CSP Scheme:

As explained in one of my posts “Securing the web with Declarative HTTP security policies”, CSP can be added to web pages in the form of the response header which looks like this: “X-Content-Security-Policy: script-src mysite.com; img-src:*”. The primary goals of CSP scheme are as follows:

Control over content inclusion:

The CSP scheme provides website administrators control over the content which can go into a web page. As seen in the example above, if script-src is set to “mysite.com”, all external JavaScript files can be loaded only from “mysite.com”. So recursive script inclusions which is possible in the current browsers relying only on Same Origin Policy will not be possible in future browsers implementing CSP. Similar configuration can be done for images, frames, objects etc.

Preventing data exfiltration:

In the current SOP scheme, cross origin requests such as <img src=””> can steal sensitive data and export it to evil destinations. This is known as data exfiltration. CSP gives security assurance to the visitors of the site that sensitive data is not exfiltrated (sent out) to evil destinations. Before triggering cross origin requests, browsers check if the outgoing origins are present in CSP whitelist. If they are present, cross origin requests are sent, else cancelled.

Enhanced security against XSS:

CSP does not allow inline scripts to exist in a page, because of which a large section of XSS attacks can be reduced. Of course, as pointed out by Michal Zalewski in his blog post “Postcards from the post-XSS world”, HTML injection based attacks are still possible and are outside the scope of CSP.

Clickjacking protection:

The best defense so far against clickjacking attacks is X-Frame-Options header proposed by Microsoft and it is implemented by all browsers. Though it is a great solution to prevent framing altogether, CSP offers better flexibility. Administrators can decide which sites can frame their site, apart from denying framing completely. So Clickjacking is better defended by CSP.

Backward compatibility and only tightened security:

CSP scheme is backward compatible. i.e., if a site having CSP headers is opened in an old browser which does not support CSP, no negative impact is seen. Security is only enhanced if browsers have CSP support, else users have the same level of security as they have with SOP.

Now that we have seen the CSP scheme, let us see the rules on which it is based.

CSP Base Restrictions:

1. Disable the execution of inline scripts

   In the current browser architecture, there is no way of differentiating between scripts which are genuine and part of the page vs. scripts which are injected via XSS holes. CSP attempts to bring this differentiation by disabling inline scripts altogether.
   
   By disabling the execution of inline scripts, XSS can be mitigated to a large extent. The downside of this approach is, even genuine code such as event handlers, code between script tags, javascript: URLs will not work. Considering the dangerous effects of XSS, this tradeoff can be easily opted for enhancing security. Since inline script execution is disabled, CSP enforces that all JavaScript code should reside in external “.js” files. This separation of concerns is also good with respect to accessibility, code maintenance and performance.

2. Disable the evaluation of code in strings
   
   As Douglas Crockford rightly points, "eval is Evil”. The eval function is the most misused feature of JavaScript. It can be used to evaluate the code inside strings, which is very dangerous.
   e.g., The code eval(String.fromCharCode('97')+"l"+"ert"+"(1)"); throws alert(1).
   So one can imagine how easy it is to obfuscate strings. There are alternate forms of eval which can evaluate strings. e.g., Funciton, setTimeout, setInterval etc. CSP disables evaluation and execution code in strings, which is a major step in disabling the execution of malicious code.

CSP Directives:

The base restrictions get applied by default in a CSP supported browser, when CSP header is configured in a website (this default behavior can be configured). Apart from this, CSP also has “Directives”, which determine how a browser should behave when it comes across protected content. Some of the directives supported by CSP are:

• script-src: Requests which will be interpreted and executed as scripts
• style-src: Requests that will be interpreted and executed as stylesheets
• img-src: Requests which will be loading images
• frame-src: Requests which will be loaded as frames in the web page.
• xhr-src: Requests generated by XMLHTTPRequests.
• media-src: Requests targeted by HTML5 <audio> and <video> elements.
• frame-ancestors: Which sites my embed the protected page as iframes (clickjacking protection)
• object-src: Requests targeted by <object>, <embed> or <applet> elements.

The list is exhaustive and is updating at a rapid pace, adding newer directives. Apart from these directives, CSP also provides a mechanism to report policy violations. When a directive “report-uri” is configured, any violations of CSP (attack attempts) are submitted to that uri so that administrators can act accordingly.

Example CSP policies:

X-Content-Security-Policy: allow ‘self’ (Requests for all types of content should come from the same origin as that of the site)

X-Content-Security-Policy: allow ‘self’; img-src *; object-src media1.com media2.com *.cdn.com; script-src: trusted.com (Requests not configured by CSP directives are limited to same origin, images can load from any origin, plugin content can load only from the given media providers, scripts can be loaded only from trusted.com.)

X-Content-Security-Policy: allow https://*:443 (All contents should be loaded over SSL to prevent eavesdropping on insecure content)

Conclusion:

Content Security Policy (CSP) fixes the loopholes of Same Origin Policy of browsers by introducing content restrictions in web pages. It helps websites specify what content can be loaded and from where, prevents attacks like script injection, clickjacking, data exfiltration etc and provides early warnings to administrators. Having said that, a site should not depend solely on CSP and should have their security mechanisms still intact, since CSP is not supported by all browsers currently. As browsers mature, CSP will be a good first line of defense.for the web platform.

References:

• “Reining in the Web with Content Security Policy” by Sid Stamm, Brandon Sterne and Gervase Markham, WWW 2010.
• CSP specification: http://www.w3.org/TR/CSP/