Sweeping content security enhancements tested on Firefox 3.7

Initial development is nearly complete on an entirely new kind of Web browser code execution policy management system, which may yet become part of Firefox 3.7 (the point release following the next one in line), a Mozilla spokesperson informed Betanews. When implemented, browsers such as Firefox will be capable of restricting certain classes of embedded code from execution, and Web sites can advertise to browsers in advance which classes of code its pages contain.

The end result, the developers of Mozilla's Content Security Policy (CSP) hope, is that policy-enhanced browsers will be completely immune from cross-site scripting (XSS) attacks from malicious sources, by virtue of restricting themselves to either only executing inline code from trusted, certified sites, or not executing any such code at all.

"The main goal of Content Security Policy is to prevent malicious code from being injected into a Web site and executed within the context of that site," reads the most recent text of Mozilla's CSP specification. "Hence, a recurring theme in CSP is to prevent the creation of script code from potentially tainted strings. It should be made clear that it is not the intent of CSP to prevent navigation to arbitrary sites, but rather to restrict the types of script, media, and other resources that may be used on a Web page."

In any kind of modern software administration, policy is a term for settings, restrictions, and permissions in a system that can be grouped together and represented explicitly, in common language (like English), for the admin to comprehend. For instance, one of CSP's policies is a setting disabling any kind of executable code from being created from a JavaScript string variable, through the use of the keyword eval(). There are several settings involved in establishing that policy, but from the admin's standpoint, the policy is quite clearly stated: "Code will not be created from strings."

The wide implementation of CSP, though, will not be easy. First of all, Mozilla's intention is for CSP to be non-proprietary, but that doesn't mean other manufacturers are chomping at the bit to adopt it. Mozilla may need support from its own competitors, including Google, Apple, and Opera, for Web site developers to feel the impetus to include policy directives -- methods of telling browsers what classes of content it may include. Microsoft is certainly aware of CSP's development, but opted to steer clear of it for Internet Explorer 8; and IE9 is still probably years away.

In a public discussion last January that included Mozilla contributors working on the CSP spec, Microsoft IE program manager Eric Law stated that his team would not be interested in considering adoption of CSP until it was done. "The problem in targeting a moving spec is that if we ship something that isn't compatible with the future evolution of that spec, we're inevitably pilloried for hurting adoption of that spec." Defending Microsoft's use of a private technology called the XDomainRequest object, he added, "Until we're ready to support a stable CSP spec, we're surgically addressing this vector."

But getting other manufacturers on board isn't the biggest hurdle CSP faces. Although the CSP specification clearly states its goal is to present an alternative from preventing browsers from navigating to sites whose layout techniques may be exploitable, that alternative would effectively mandate that developers build bypass routes for browsers that advertise their own restrictions. The most widespread example will likely be inline scripts -- pieces of JavaScript that are passed as parameters to event-driven objects such as on-screen gadgets and hyperlinks. JavaScript was designed to enable this -- it's a feature, to embed snippets of code as responses to events, instead of pointers to named functions residing in enclosed <SCRIPT> elements. It's shorthand for the developer, and makes many functions of site development much easier.

One sure-fire way to prevent inline scripts from injecting malicious code into the JavaScript stream is to prevent any inline scripts from executing at all -- and that's one of the available policies in CSP. A more Draconian measure would be to prevent navigation to a site that uses inline code (for example...Betanews). While CSP's alternative seems fairer, it's left to the site developer how to handle a situation where the site's been informed the browser can't execute inline scripts.

In the opinion of Mozilla security program manager Brandon Sterne, that's just fine with him: If CSP promotes a more secure, if more difficult, programming method, that may only mean sites are more protected from exploitation to begin with. And if developers get the loosely veiled message, then he hopes they'll simply take heed of it.

On Sterne's Mozilla blog yesterday, he posted a download link to a custom preview build of Firefox 3.7 "Minefield" with Content Security Policy included. He also posted a test page demonstrating how certain code samples can be effectively excluded using CSP, and how other browsers loading that test page let them right through.

"We have looked at HTML/JavaScript samples from a wide variety of Web sites ranging in complexity and have yet to see an example which could not be modified to support CSP," Sterne wrote last June. "We'll provide documentation regarding best practices for migrating a site to use CSP. Content Security Policy is also consistent with the programming paradigm 'don't mix code with content,' so there may be additional functional benefits to be gained by implementing such separation."

Even if Web site developers concur with the paradigm engineers such as Sterne are promoting, they may still have to contend with advertisers, especially those who contribute by way of ad distribution services. Outside of these developers' control, more often, advertisers are using dynamic JavaScript tweaks themselves, sometimes to expand the reach of their ads beyond the borders set for them on the page. A site may not be able to vouch for the inline content its advertisers supply, so while they may advertise themselves as compliant, from time to time, through no fault of their own, they may not be.

Brandon Sterne's custom build of "Minefield" is not one of the daily preview builds of Firefox 3.7, so testers who download the latest private alpha build will notice that it, too, fails Sterne's CSP test. CSP has yet to be officially announced as a component of Firefox 3.7, or any future release.