Preface

While the technical details of this proposal and the proof-of-concept illustrated here may be most interesting to web application security professionals, it is important to first make a few points about the goals and spirit of the proposal:

  1. Nothing here is proprietary. We would like nothing more than to see all the browser vendors implement the same security policy framework to protect websites and web users across the board. There is no specification defined here. We are hoping to start a discussion among people who will use the framework (websites) and people who will implement the framework (browsers).
  2. This proposal is in early development and is highly experimental. We don't know when (or even if) it will be completed and be ready to ship with Firefox. For now, Site Security Policy will be distributed as a Firefox Add-on to socialize the idea and to build proof-of-concept.
  3. This is only a partial implementation. Even in the limited exposure Site Security Policy has been given, we have received positive feeback from various websites who want to utilize it. These sites think the proposal is a good start, but have ideas for additional functionality that would make the framework maximally useful. We hope to collect more of this type of feedback. Again, all are welcome to this discussion. This is about doing what is best for the Web.

Background

The last 3 years have seen a dramatic increase in both awareness and exploitation of Web Application Vulnerabilities. 2007 saw dozens of high-profile attacks against websites using Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) for the purposes of information stealing, website defacement, malware planting, etc.

It seems that while many sites are aware of these threats, and have programs in place to find and remediate the vulnerabilities, the sheer size and complexity of the websites make complete remediation of the security holes implausible. Browser vendors can do more to protect users from client-side attacks involving websites that are vulnerable to the classes of attacks mentioned above. This document proposes a mechanism that enables websites to define Site Security Policy which browsers can choose to enforce, restricting the capabilities of web content that make these attacks possible.

One might ask "if the vulnerable websites are aware of their shortcomings in Application Security, why won't they address the root cause and fix their vulnerabilities?" It is true that the ideal solution is to develop web applications free from any exploitable vulnerabilities. Real world security, however, is usually provided in layers and Site Security Policy intends to be only one layer. Even the hypothetical vulnerability-free website can benefit from Site Security Policy. Though the site may be free of vulnerabilities today, a new vulnerability may be introduced tomorrow which could remain fully mitigated by Site Security Policy until it is detected and fixed properly.

Goals

Site Security Policy is intended to mitigate two (possibly more) classes of Web Application Vulnerabilities: Cross Site Scripting and Cross Site Request Forgery.

  1. Cross Site Scripting (XSS)
    • There are many good references for those needing to familiarize themselves with XSS and the associated risks.
    • XSS exploits the client's trust of the content received from the server. Malicious script is executed by the victim's browser because the victim trusts the source of the content.
    • Site Security Policy provides a way for server administrators to reduce or eliminate their XSS attack surface.
      1. Website administrators specify which domains the browser should treat as valid sources of script.
      2. The browser will only execute script in source files from the white-listed domains and will disregard everything else, including embedded and inline scripts.
      3. Sites that never want to have JavaScript included in their pages can choose to globally disallow script.
  2. Cross Site Request Forgery (CSRF)
    • There are many good references that describe threat and impact of CSRF.
    • CSRF exploits a server's trust of the requests it receives from its clients. Attackers craft web content that, when viewed in the victim's browser, sends bogus requests to target websites on behalf of the victim.
    • Site Security Policy provides controls for administrators to define how their websites handle cross-site requests
      1. Ingress Filtering - web administrators explicitly define which domains can initiate cross-site requests to resources in their site.
      2. Egress Filtering - administrators define domains to which content in their site can initiate requests.

Compatibility

Site Security Policy will be fully backward compatible and will not affect sites or browsers which don't support it. Non-supporting browsers will disregard the policy definition headers and will default to the standard Same-Origin policy for webpage content. In the absence of any Site Security Policy headers, supporting browsers will also fall-back to the Same-Origin policy. Website administrators can define Site Security Policy without fear of web compatibility issues.

Overview | Details | Download | Demo | Discussion