Declaring Security

Recently, a number of people have asked me what I think about Mozilla’s Content Security Policy draft spec.  Back in January, I went on record as being someone who thinks that CSP is a good idea. 

CSP is a mechanism for declarative security, whereby a site communicates its intent and leaves it up to the user-agent to determine how to enforce it.

There are a number of benefits to declarative security mechanisms:

1. Reduced compatibility risks. Because sites must opt-in and declare what, if any, restrictions they want, new security features may be added to the user-agent with decreased compatibility fallout.
2. Clear intent. By plainly declaring which restrictions are desired, browsers need not try to “guess” the site’s intent.  For instance, when explaining that frame-breaking JavaScript cannot be relied upon to prevent ClickJacking, Kymberlee noted:
   

   If you don’t design something to prevent a security vulnerability, odds are that it doesn’t do a very good job of doing it.
   
   Because declarative security features are designed solely to mitigate security threats, browsers may implement the restrictions however they want, and can patch any holes found in the restrictions without unexpectedly breaking unrelated functionality.

3. Usability. By allowing a site to declare its security policy, browsers can make some security decisions on the user’s behalf.
4. Auditability. It is straightforward to build tools that scan content for policies and determine if they meet the publishing organization’s expectations.

Internet Explorer has a rich history in this space: HTTPOnly, SECURITY=RESTRICTED frames, X-Content-Type-Options, X-Download-Options, X-Frame-Options are all declarative security mechanisms first implemented in IE, and now supported by other browsers to varying degrees. 

The ideas behind the CSP draft are not new, and it is but one of many proposals for declarative security, from BEEP to HTML5 sandboxing.  In some respects it overlaps with other mechanisms for restricting script, although if CSP is successful, new directives will likely be created to provide uniform specification of the available policies.

While valuable, declarative security mechanisms are not without their challenges:

1. Plugins. Unless plugins have been blocked outright, they must be aware of, and enforce, the declared security policies.  Because plugins are provided by many different vendors, this requirement may prove challenging in real-world deployments.
2. Misconfiguration.  CSP is only as valuable as the policies configured by the developer or administrator, and a number of major sites have suffered breaches due to misconfiguration of security policy files. Ira Winkler claims [p143] that government studies indicate that 70% of computer intrusions are a result of configuration problems.
3. New attack surface. The very mechanisms used to implement CSP will be probed by hackers, and comprehensive fuzzing and penetration testing will be required to help mitigate the attack surface added.  Furthermore, if a hole is found that enables an attacker to circumvent a given policy within a given user-agent, that user-agent’s reputation may be harmed-- even if other user-agents do not attempt to support that policy.
4. Debuggability. Web developers already face significant challenges in developing their pages, and introducing new security policies will require that tools be updated to clearly indicate when content has been blocked due to security policies. Sites might inadvertently set overly restrictive policies and failure to catch mistakes via comprehensive testing could lead to a confusing user experience.
5. Dynamic content. It may prove difficult to author workable policies for some dynamic-content scenarios (e.g. email composition, blog authoring, etc) because the user may herself add content to a given page from origins unknown to the web developer.
6. Adoption. Perhaps the biggest challenge for CSP and competing proposals is related to the fact that they offer “off-by-default” security.  While this is great for compatibility, it’s not-so-great for protecting sites and users, because benefits are only attained after web developers update their sites.  To succeed, CSP must balance power/flexibility against simplicity/understandability.

No security technology is a panacea, and for comprehensive protection, I think browsers need to offer both:

1. Rich security APIs that enable sites to prevent XSS attacks.
2. Automated protections to shield sites that can’t/won’t update their code immediately / ever.

To combat XSS attacks, IE8 introduced a number of attack-surface-reductions, a few new APIs, as well as the declarative security mechanisms (X-* headers) mentioned above. But we knew that sites wouldn’t immediately adopt these APIs and declarative security features, so we built the XSS Filter, an on-by-default, no-questions-asked, no-code-changes required mechanism which helps mitigate the most common types of XSS attacks in the wild today.

I’m eager to see the progress on CSP, which I believe is a promising approach to helping websites secure themselves against the growing alphabet soup of web threats.  You can provide feedback on the CSP draft spec using Mozilla’s Talk page.

-Eric Lawrence