Google is continuing to introduce new security technologies in its Chrome browser, and the latest addition on the horizon is support for unprefixed Content Security Policy, a behind-the-scenes improvement designed to prevent malicious script injections. The technology is included in the beta of Chrome 25, which was released earlier this week, and will soon find its way into the stable channel.
One of the many attack vectors that have made life easier for the bad guys in the last few years is cross-site scripting. This attack relies on specific vulnerabilities in Web applications that allow attackers to get their own malicious scripts onto a legitimate Web page. Browsers will then run those scripts as if they were part of the trusted Web page, enabling the attacker to plant malicious code on a victim’s machine or steal sensitive data.
Content Security Policy is one mechanism for preventing these kinds of attacks by allowing users to define which content sources they trust. Chrome then will run scripts only from those trusted sources, creating a whitelist of known good content sources and ignoring content from all other sources.
“Content Security Policy (CSP) helps you reduce the risk of cross-site scripting and other content injection attacks. Starting in today’s Beta release, you can use the unprefixed Content-Security-Policy HTTP header to define a whitelist of trusted content sources. The browser will only execute or render resources from those sources,” Google’s Eric Bidelman said in a blog post.
Cross-site scripting attacks have been a major problem for a long time now, and there have been a number of defenses proposed to help prevent these attacks. But none has turned out to be a universal shield against XSS attacks. The only across-the-board fix, of course, would be to eliminate all of the XSS vulnerabilities in Web apps, which is a somewhat more difficult task than implementing a client-side protection such as Content Security Policy.
“Instead of blindly trusting everything that a server delivers, CSP defines the Content-Security-Policy HTTP header that allows you to create a whitelist of sources of trusted content, and instructs the browser to only execute or render resources from those sources. Even if an attacker can find a hole through which to inject script, the script won’t match the whitelist, and therefore won’t be executed,” Mike West, a developer relations employee at Google in Germany, wrote in an explanation of the way Content Security Policy works.
“With this policy defined, the browser will simply throw an error instead of loading script from any other source. When a clever attacker does manage to inject code into your site, she’ll run headlong into an error message, rather than the success she was expecting.”
Chrome is not the only browser that’s on track to enable support for Content Security Policy. Both Safari and Firefox also have implementations of the header, but both include a prefix before the header.
In addition to the directive in CSP that prevents scripts running from untrusted sources, there also are several other directives with various capabilities. One of those directives is a “sandbox” flag that, when set, will impose some further restrictions on what content can run and from which sources.
“If the sandbox directive is present, the page will be treated as though it was loaded inside of an iframe with a sandbox attribute. This can have a wide range of effects on the page: forcing the page into a unique origin, and preventing form submission, among others,” West wrote.
