Index: details.html =================================================================== --- details.html (revision 13) +++ details.html (working copy) @@ -10,6 +10,7 @@
+

Version: 0.1 | 0.2 (cur)

Please note this is not a specification document. This is one proposal for the syntax and delivery for Site Security Policy. Discussion is open to all interested parties. We hope that a working spec which can be implemented by all browsers is one of the byproducts of this discussion.

Also, it seems appropriate to acknowledge RSnake and Gerv who originated this idea. Jeremiah Grossman has also been extremely helpful in advancing it.

@@ -28,6 +29,7 @@
  • Request-Source
    • Request-Source instructions sent by the server indicate a (potentially empty) set of domains whose content should be allowed to request the resource.
      • +
    • Only requests made via non-safe HTTP methods can be restricted. Requests made via GET and HEAD can be issued across domains without restrictions by Site Security Policy. Note that many aspects of the Web, most notably hyperlinks, create cross-site GET requests on a frequent basis. Site authors who wish to utilize Site Security Policy are encouraged to follow the W3C's guidance on minimizing side-effects produced by these requests.
    • In the absence of any Request-Source instructions, content from all sites will be allowed to initiate requests to the corresponding resource. Note that this keeps the prevention of CSRF primarily as the responsibility of the server receiving the cross-site requests. A supporting browser will make the preemptive policy check before sending content-initiated cross-site requests, but those requests will only be blocked if a Request-Source deny rule matching the requesting domain is returned.
    • A policy query will be made by the browser before a cross-site request is initiated by page content. Requests made via non-safe HTTP methods will not be sent if they violate a site's security policy.
    • These instructions take precedence over any Request-Target instructions which are defined below.
      • @@ -57,12 +59,14 @@
    • Script-Source
      • A valid Script-Source instruction contains one or more pairs of the form ("allow or deny", "host item").
        • +
      • Any deny rule for a host will take precedence over all allow rules for the host within a set of policies for a particular resource.
      • Example: X-SSP-Script-Source: allow *.example.com; deny public.example.com
    • Request-Source
      • Request-Source instructions are sent in response to policy queries made by the browser before allowing page content to make a cross-site request. The policy query sent by the browser is a HEAD request to the cross-site resource containing the HTTP header Policy-Query:. The policy instructions sent by the server in response to this query consist of one or more triplets of the form ("allow or deny", "host item", "list of HTTP methods") and an optional expires attribute specifying the number of seconds to cache the policy. The following are examples of valid Request-Source instructions:
        • +
      • For any host and HTTP method combination, a deny rule will take precedence over all rules allowing the same access for a particular resource.
      • X-SSP-Request-Source: deny * post; allow * get; expires 60
      • X-SSP-Request-Source: allow *.example.com post,get; deny public.example.com *; expires 3600
      @@ -70,6 +74,7 @@
    • Request-Target
      • A valid Request-Target instruction contains one or more triplets of the form ("allow or deny", "host item", "list of HTTP methods").
        • +
      • For any host and HTTP method combination, a deny rule will take precedence over all rules allowing the same access for a particular resource.
      • Example: X-SSP-Request-Target: allow *.example.com *, deny public.example.com post
      • Index: details.html =================================================================== --- details.html (revision 17) +++ details.html (revision 18) @@ -7,92 +7,143 @@
      - +

      Version: 0.1 | 0.2 | 1.0 (cur)

      Please note this is not a specification document. This is one proposal for the syntax and delivery for Content Security Policy. Discussion is open to all interested parties. We hope that a working spec which can be implemented by all browsers is one of the byproducts of this discussion.

      -

      Also, it seems appropriate to acknowledge RSnake and Gerv who originated this idea. Jeremiah Grossman has also been extremely helpful in advancing it.

      +

      Also, it seems appropriate to acknowledge RSnake and Gerv who originated this idea. Jeremiah Grossman, Collin Jackson, and Adam Barth have also been extremely helpful in advancing it.

      Policy Focus

      -

      We identify four security policy areas that website administrators can choose to define. Each area is optional and can be defined independently from the other areas. Security policy can be defined on a per-resource basis and can vary according to the sensitivity of a particular resource. Additionally, a reporting server can be specified as part of a server's security policy which tells the browser where to send reports when JavaScript or a cross-site request was blocked per some security policy. This has the added benefit of showing a website admin which pages within their site are being actively attacked or are potentially misconfigured.

      +

      There are a total of seven policy areas that website administrators can define via Content Security Policy. Meaningful policy sets can be created, however, by defining just a few of these policy areas. With the exception of the allow section, each policy area is optional and can be defined independently from the other areas. If Content Security Policy is specified by a web site, the allow section is required. It is treated as a catch-all for types of content whose policy may or may not be defined. If an allow section is not specified, then allow none is implied. Policies can be defined for more specific types of content including: images, scripts, objects, frames and iframes.

      +

      Security policy is defined on a per-resource basis and can vary according to the sensitivity of a particular resource. Some example policy sets are provided below.

        -
      1. Script-Source +
      2. allow
          -
        • Script-Source instructions returned by the server indicate a (potentially empty) set of domains that should be treated as valid sources of JavaScript for the page.
          • -
        • When any Script-Source instruction is received by the browser script enforcement mode is enabled and only white-listed hosts will be treated as valid sources of script for the page. Any script embedded within the page and any script included from non-white-listed hosts will not be executed.
          • -
        • In the absence of any Script-Source instructions, all JavaScript for a particular resource including embedded, inline, and external will be treated as valid and executed by the browser as normal.
          • -
        • Script-Source instructions are sent as HTTP response headers and are used by the browser to determine the JavaScript behavior for the corresponding page. Note the difference between this model and the model used by Request-Source instructions below.
          • +
        • allow is the catch-all section that defines the security policy for all types of content which are not called out in any of the specific policy areas below
          • +
        • It is required to be defined for any resource which utilizes Content Security Policy +
            +
          • If Content Security Policy is enabled but allow is not defined, then allow none is implied
            • +
          +
        3. -
      3. Request-Source +
      4. img-src
          -
        • Request-Source instructions sent by the server indicate a (potentially empty) set of domains whose content should be allowed to request the resource.
          • -
        • A policy query will be made by the browser before a cross-site request is initiated by page content.
          • -
        • Only requests made via non-safe HTTP methods can be restricted. Requests made via GET and HEAD can be issued across domains without restrictions by Content Security Policy. Note that many aspects of the Web, most notably hyperlinks, create cross-site GET requests on a frequent basis. Site authors who wish to utilize Content Security Policy are encouraged to follow the W3C's guidance on minimizing side-effects produced by these requests.
          • -
        • In the absence of any Request-Source instructions, content from all sites will be allowed to initiate requests to the corresponding resource. Note that this keeps the prevention of CSRF primarily as the responsibility of the server receiving the cross-site requests. A supporting browser will make the preemptive policy check before sending content-initiated cross-site requests, but those requests will only be blocked if a Request-Source deny rule matching the requesting domain is returned.
          • -
        • These instructions take precedence over any Request-Target instructions which are defined below.
          • -
        • Security policy for a particular resource can be cached for some period of time per the server's instructions. The policy cache will expire at the end of the browser session.
          • +
        • Indicates which hosts are valid sources for images
          • +
        • Images from non-white-listed hosts will not be requested or loaded
        5. -
      5. Request-Target +
      6. script-src
          -
        • Request-Target instructions returned by the server indicate a (potentially empty) set of hosts which should be white-listed by the browser as valid targets for cross-site requests initiated by the page's content.
          • -
        • Request-Target instructions provide a way to prevent page content from making outbound communication to other sites. This prevents data from being exfiltrated from the site as well as preventing additional non-intended resources from being included in the page.
          • -
        • Request-Target instructions can also be used to restrict a website from being used as a platform to attack other websites via CSRF. These may be particularly useful for sites that permit users to post HTML and JavaScript in publicly accessible areas.
          • -
        • Security policy for a particular resource can be cached for some period of time per the server's instructions. The policy cache will expire at the end of the browser session.
          • +
        • Indicates which hosts are valid sources for JavaScript
          • +
        • Scripts from non-white-listed hosts will not be requested or executed
          • +
        • If Content Security Policy is set for a resource, only script loaded from white-listed hosts will execute +
            +
          • Inline script (contents of <script> nodes) is disabled
            • +
          • Script called using event-handling attributes is not executed
            • +
          +
          • +
        • In summary, all valid scripts will be placed in external script files and served from white-listed hosts
        7. -
      7. Report-URI +
      8. object-src
          -
        • The Report-URI instruction tells the browser where to send reports when Content Security Policy prevents JavaScript from executing or page content from initiating a cross-site request.
          • -
        • A report will consist of a POST made to the specified URI containing as the POST body the full HTTP request which led to the policy violation.
          • -
        • For a page resulting in multiple policy violations, the browser will not send duplicate reports for a single page view.
          • -
        • This policy is not cached and will be expired immediately by the browser. Note that the server will need to send a Report-URI instruction explicitly with each page for which it wants policy violation feedback.
          • +
        • Indicates which hosts are valid sources for <object>, <embed>, and <applet> elements
          • +
        • Objects from non-white-listed hosts will not be requested or loaded
        9. -
      -

      Syntax and Delivery

      -

      Content Security Policy is delivered to the browser via custom HTTP headers. As indicated above, these policy headers will fall into two general groups. The first group consists of direct or inline policy, intended by the server to be applied as processing instructions for the attached content. The second group consists of third-party policy which is sent in response to specific policy queries. In these cases the server provides information which allows the client to decide whether or not to allow a content-initiated request to another site. A similar model is described in the W3's Access Control specification. Much of the policy described below makes reference to host items since Content Security Policy applies levels of privilege to page content based on its originating host. A host item is a domain string which may contain wildcards (*) which is explicitly allowed or denied in each instruction. Internationalized domain names are specified according to their punycode representations. Returned resources may contain one or more policy instructions defined. The instructions can be combined into one set and any conflict within a set of instructions will be resolved by following the more restrictive policy.

      -
        -
      1. Script-Source +
      2. frame-src
          -
        • A valid Script-Source instruction contains one or more pairs of the form ("allow or deny", "host item").
          • -
        • Any deny rule for a host will take precedence over all allow rules for the host within a set of policies for a particular resource.
          • -
        • Example: X-SSP-Script-Source: allow *.example.com; deny public.example.com
          • +
        • Indicates which hosts are valid sources for <frame> and <iframe> elements
          • +
        • Frame content from non-white-listed hosts will not be requested or loaded
        3. -
      3. Request-Source +
      4. report-uri
          -
        • Request-Source instructions are sent in response to policy queries made by the browser before allowing page content to make a cross-site request. The policy query sent by the browser is a HEAD request to the cross-site resource containing the HTTP header Policy-Query:. The policy instructions sent by the server in response to this query consist of one or more triplets of the form ("allow or deny", "host item", "list of HTTP methods") and an optional expires attribute specifying the number of seconds to cache the policy. The following are examples of valid Request-Source instructions:
          • -
        • For any host and HTTP method combination, a deny rule will take precedence over all rules allowing the same access for a particular resource.
          • -
        • X-SSP-Request-Source: deny * post; allow * get; expires 60
          • -
        • X-SSP-Request-Source: allow *.example.com post,get; deny public.example.com *; expires 3600
          • +
        • Instructs the browser where to send a report when Content Security Policy is violated
          • +
        • The report will be a XML document sent via POST to the specified URI containing the following: +
            +
          • request - HTTP request line which led to the policy violation (method, resource path, HTTP version)
            • +
          • headers - HTTP headers sent which led to the policy violation
            • +
          • blocked - URI of the resource that was blocked from loading
            • +
          +
          • +
        • Sample report:
          <csp-report>
+  <request>GET /index.html HTTP/1.1</request>
+  <headers>Host: example.com
+           User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0
+           Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+  </headers>
+  <blocked>http://evil.com/some_image.png</blocked>
+</csp-report>
          +
        5. -
      5. Request-Target +
      6. policy-uri
          -
        • A valid Request-Target instruction contains one or more triplets of the form ("allow or deny", "host item", "list of HTTP methods").
          • -
        • For any host and HTTP method combination, a deny rule will take precedence over all rules allowing the same access for a particular resource.
          • -
        • Example: X-SSP-Request-Target: allow *.example.com *, deny public.example.com post
          • +
        • Indicates the location of a file containing the security policies for the resource
          • +
        • The policy-uri must point to the same host as the resource for which it defines policy
          • +
        • If a valid policy-uri is specified, any policy defined in the HTTP header will be ignored
        7. -
      7. Report-URI +
      +

      Syntax and Delivery

      +

      Content Security Policy is delivered to the browser in one of two ways: a custom HTTP header or a file served from the same host as the resource to be secured. If a policy-uri is specified then the policy defined in that file will take precedence over any policy defined in the HTTP header. The syntax is identical between file-based and header-based policy. The contents of a policy file are equivalent to the value of the X-Content-Security-Policy header. Authors who are unable to support signaling via HTTP headers can use <meta> tags with http-equiv="X-Content-Security-Policy" to define their policies. HTTP header-based policy will take precedence over <meta> tag-based policy if both are present.

      +

      Much of the policy described below makes reference to host items since Content Security Policy applies levels of privilege to content based on its originating host. A host item is a domain string which may contain wildcards (*) which is explicitly allowed to be a source of content for a particular resource. Internationalized domain names are specified according to their punycode representations. Sets of security policies may contain both general (e.g. allow) and specific (e.g. script-src) instructions that could apply to the same content. In these cases, policy from the more specific instruction will be enforced.

      +

      Content Security Policy supports the following three keywords to be used as host items:

      +
        +
      • self: refers to the host that the resource is served from
        • +
      • none: indicates the empty set
        • +
      • data: indicates data: URLs are a valid source of content
        • +
      +

      Content Security Policy will be specified according to the following format:

      +
        +
      • Policy sections are delimited by semi-colon (;)
        • +
      • Each policy section will consist of a policy section identifier followed by: +
          +
        1. a whitespace-delimited list of host items or
          2. +
        2. a single URI
          3. +
        +
        • +
      • Valid policy section identifiers include: +
          +
        1. allow
          2. +
        2. img-src
          3. +
        3. script-src
          4. +
        4. object-src
          5. +
        5. frame-src
          6. +
        6. report-uri
          7. +
        7. policy-uri
          8. +
        +
        • +
      +

      Example Use Cases

      +
        +
      1. Site wants all content to come from its own domain:
          -
        • A report URI instruction contains the URI to which the browser should POST the full request which resulted in the policy violation.
          • -
        • Example: X-SSP-Report-URI: http://www.example.com/policy.cgi
          • +
        • X-Content-Security-Policy: allow self
          • +
        • <meta http-equiv="X-Content-Security-Policy" content="allow self" />
        2. +
      2. Auction site wants to allow images from anywhere, plugin content from a list of trusted media providers, and scripts only from its server hosting sanitized JavaScript: +
          +
        • X-Content-Security-Policy: allow self; img-src *; object-src media1.com media2.com; script-src userscripts.example.com
          • +
        • <meta http-equiv="X-Content-Security-Policy" content="allow self; img-src *; object-src media1.com media2.com; script-src userscripts.example.com" />
          • +
        +
      +

      The Origin Header

      +

      Since Cross Site Request Forgery has been removed from the scope of Content Security Policy, we now propose that the Origin header be implemented to address CSRF.

      Conclusions

      -

      Content Security Policy provides a way to greatly reduce or altogether eliminate a website's attack surface for Cross-Site Scripting. With proper Content Security Policy in place, a successful XSS attack will require the attacker to have control over the contents of white-listed script source files. No longer will XSS attacks which rely on echoing script into page contents be effective. Further, if a site knows it never want to have JavaScript executing in its pages, it can simply globally disable JavaScript and not have to worry about script injection attacks against its users with supporting browsers.

      -

      Content Security Policy also provides a simple way for a website to prevent Cross-Site Request Forgery against its sensitive resources. A comprehensive CSRF protection mechanism, such as form token checking, can be complicated to implement and difficult to integrate into an existing web application. Such a mechanism may even be subject to its own security bugs. Even a properly implemented CSRF-protection-token system will not stand up in an environment with XSS bugs. Web sites facing these challenges can utilize Content Security Policy to harden themselves against attack and achieve a higher level of confidence in the security of their systems with an added layer of security. Websites will be able to fully control who can request resources from outside the site and what remote locations should be reachable by content from within the site.

      +

      Content Security Policy provides a way to greatly reduce or altogether eliminate a website's attack surface for Cross-Site Scripting. With proper Content Security Policy in place, a successful XSS attack will require the attacker to have control over the contents of white-listed script source files. No longer will XSS attacks which rely on echoing script into page contents be effective. Further, if a site knows it never wants to have JavaScript executing in its pages, it can simply globally disable JavaScript and not have to worry about script injection attacks against its users with supporting browsers.

      +

      The Origin header provides a simple way for a website to mitigate Cross-Site Request Forgery against its sensitive resources. The Origin header provides the information a server needs to validate its requests while avoiding the privacy concerns which were chief among the criticisms of Referer.

      As seen in every aspect of Computer Security, the protection of a system is best achieved through a variety of overlapping controls. Content Security Policy aims to be one part of a larger defense-in-depth application security strategy, or as our colleague Gerv likes to say, "belt-and-braces". Web administrators, while maintaining their normal security auditing and remediation process, will embrace the opportunity to mitigate broad classes of web app vulnerabilities, for those users with compliant browsers, by defining a few simple rules.

      -

      Overview | Details | Download | Demo | Discussion

      +

      Overview | Details | Download | Demo | Origin Header | Discussion

      - +