Security/CSP/Design Considerations

Much thought was put into the design and construction of the CSP Spec. This document describes some of the reasoning behind the specification for those interested.

Background

Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection. CSP is not intended to be a main line of defense, but rather one of the many layers of security that can be employed to help secure a web site. More information about the intended use of CSP is available in the goals section.

Content Restrictions

The main goal of Content Security Policy is to prevent malicious code from being injected into a website and executed within the context of that site. 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.

Base Restrictions (and XSS protection)

In order to support Content Restrictions properly, some base restrictions must be enforced on a web site:

No inline scripts will execute

Allowing inline scripts on a site opens the site up to XSS attacks that leverage inline scripts to run. Such attacks could effectively manipulate the page even though the injected script may not come from a source authorized by the content restriction policy of the site.

In order to implement a content restrictions scheme properly, inline and evaluated scripts must be disabled (see above base restrictions). This enables CSP to also be used in an XSS-blocking way.

• XSS attacks are possible because the browser has no way to differentiate between content the server intended to send and content injected by an attacker. Content Security Policy forces the separation of code from content and requires authors to be explicit about the code they intend to execute

• Common vectors for injecting script into web pages have been restricted in CSP. With CSP enabled, the bar for a successful XSS attack is raised substantially, requiring an attacker to:
  1. inject a <script> tag into the target document
  2. point this tag at a script file on a white-listed host
  3. control the contents of the white-listed script file
• Note: websites are still able to peform event-handling in the following ways, both of which require being used from within valid white-listed script files:
  1. setting the on<event> properties of an element, e.g. element.onclick = myFunc;
  2. using addEventListener, e.g. element.addEventListener("click", myFunc, false);

• Vulnerability types mitigated:
  1. Reflected XSS
  2. Stored XSS
  3. javascript: link injection
  4. HTML attribute injection

Code will not be created from strings

Functions that create code from strings during runtime can be leveraged by an attacker who can insert malicious strings into a page. Commonly, these interpreted malicious strings have the same control over a web page as an inline script, yet are potentially more difficult to detect.

• eval and related functions make trivial the task of generating code from strings, which commonly come from untrusted sources, are loaded via insecure protocols, and can become tainted with attacker controlled data.
• Once tainted data has been introduced to a JavaScript program, it is extremely difficult to control its propogation and calls to eval and similar are likely to incorporate tainted strings containing malicious code.
• Note: the common AJAX pattern in which a site makes a XMLHttpRequest to fetch JSON data is still enabled under CSP using a JSON parser or inside a browser that has native JSON support.

• Vulnerability types mitigated:
  1. AJAX request tampering
  2. Improper use of dynamic properties

data: protocol blocking

CSP must provide a mechanism for disabling protocols that represent request-less data such as the data: and javascript: protocols. The data: protocol can be used to load binary data into a web site, and could potentially be used to inject scripts or other active content not authorized by the site's policy. As a result, it's important for a site designer to explicitly state in a policy that the data: protocol is expected on the site and should be tolerated.

Firefox-specific restrictions

XBL is used to define the properties and behaviors of elements in HTML, XUL, and SVG documents from external files and as such is a vector for script injection. As a result, XBL should be disabled on pages that use CSP, except when it is loaded from a fundamentally trusted "chrome:" or "resource:" context.

Restricting report-uri

The report-uri directive could potentially be abused to exfiltrate sensitive data like cookies or other session data. As a result, it can only be transmitted to a host that is probably controlled by the same entity as the protected content. This means that a report-uri must go to another host whose public suffix and base host are the same. For instance, a report-uri in a policy for "www.mysite.com" may refer to anything that ends with "mysite.com", so long as the scheme is the same.

Policy Delivery

What about http-equiv in a meta tag?

TODO

Why Intersect Policies?

Because the X-Content-Security-Policy header may appear multiple times in the response, it is possible they're crafted by different entities and may conflict. A decision must be made about which policy to use, or whether to combine them or not. Assuming there are two different policies present, there are five obvious ways to address this conflict:

1. Ignore both. Raise error in the console. Enforce "allow none" (most secure).
   Simplest and safest way to lock down when the policies conflict.
2. Ignore both. Raise error in the console. Enforce "allow *" (most relaxed).
   This is a fail-open policy and will keep the site from breaking if two policies conflict.
3. Use the first header's policy.
4. Use the second header's policy.
5. Enforce the intersection of the policies.
   This is the technique used by CSP. For each URI that is accepted by both policies, the new intersected policy will also accept the URI. Any request that is not accepted by both policies will be rejected by the new policy. This provides the ability for interaction between multiple policy specifications, allowing infrastructure admins to add a global policy to all sites on their network that may additionally want more restrictions. This technique allows the use of multiple headers to make a widely used policy more restrictive, but never more relaxed.

The fifth option, enforcing the intersection of the policies, is the best balance between safety and flexibility so CSP implements this conflict resolution technique. Furthermore, it is likely that those controlling the network are not always the same people who maintain or create the web application itself -- the ability to "refine" or further restrict enforced policies allows the web programmers to tighten the belt on a CSP-protected page without violating the policy set out by the network (possibly set by the sysadmins).

Conflicting report-uri values

Report-duplication (or multiple reporting) is useful in the case where two different groups want to receive reports, but may not share access to the reports archive. Take for instance a large web company that has a separate sysadmin staff (who are also in charge of security at some level) and project teams. One project team may be interested in receiving reports about violations of their CSP, but are not interested in violations on other parts of the web site. The sysadmin team wants to record all violations from all parts of the site into a massive archive. The multiple reporting technique allows both entities to receive the reports they want without causing extra data-mining work on the part of the sysadmin team to isolate the reports that each project team may want.