[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

WEBSEC                                                          A. Barth
Internet-Draft                                              Google, Inc.
Intended status: Standards Track                              T. Gondrom
Expires: September 7, 2012                                 March 6, 2012


                  HTTP Header Content Security Policy
                   draft-gondrom-websec-csp-header-00

Abstract

   To communicate the Content Security Policy (CSP) as defined by the
   W3C, the web server needs to send a HTTP header to the browser
   (client) to inform it about the content security policies that SHALL
   be applied on the client.  This draft outlines the header to
   communicate the CSP with its fields.  The definition of the semantic
   of the directives will be done by the Web Application Security
   Working Group at the W3C.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 7, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Barth & Gondrom         Expires September 7, 2012               [Page 1]

Internet-Draft                 CSP Header                     March 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   3.  Content Security Policy Header  . . . . . . . . . . . . . . . . 3
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     4.1.  Content-Security-Policy . . . . . . . . . . . . . . . . . . 4
     4.2.  Content-Security-Policy-Report-Only . . . . . . . . . . . . 4
   5.  Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . . . . . 5
   6.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Source List . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Directives  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
     11.1. Registration Template . . . . . . . . . . . . . . . . . . . 7
   12. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     13.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     13.2. Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8


























Barth & Gondrom         Expires September 7, 2012               [Page 2]

Internet-Draft                 CSP Header                     March 2012


1.  Introduction

   In 2011 the W3C started the working group "Web Application Security
   Working Group" to work on a future Content Security Policy.  A policy
   language intended to enable web designers or server administrators to
   declare web application content security policy.  The goal of the
   specification is to reduce attack surface by specifying overall rules
   for what content may or may not do, thus preventing violation of
   security assumptions by attackers who are able to partially
   manipulate that content.

   The goal of this drafts is only to document and specify the HTTP
   header used to communicate the Content Security Policy as specified
   by the W3C working group.


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  Content Security Policy Header

   The Content Security Policy (CSP) HTTP response header indicates a
   policy to be enforced by the browser on from which sources different
   types of content will be allowed to load and possibly execute.  Hosts
   can declare this policy in the header of their HTTP responses to
   prevent Cross Site Scripting, Cross-Site Request Forgery and
   clickjacking attacks, by ensuring that content from untrusted sources
   is not loaded/executed in web pages or frames.


4.  Overview

   The header field name is:
   Content-Security-Policy

   Please note, that previous experimental implementations prior to this
   standard may use the header name X-Content-Security-Policy, which
   does not indicate any conformance with this standard.

   The server transmits its security policy for a particular resource
   using a HTTP header with the label "Content-Security-Policy" followed
   by a collection of directives, each of which controls a specific set
   of privileges for a document rendered by a user-agent.  More details
   are provided in the directives section.



Barth & Gondrom         Expires September 7, 2012               [Page 3]

Internet-Draft                 CSP Header                     March 2012


   In general any directive consists of a directive name, which
   specifies the privileges controlled by the directive, and its
   directive value, which specifies the restrictions the policy imposes
   on those privileges.

   [TBD] do we need to mention the HTML meta tag here as well?
   The CSP SHOULD be delivered from the server to the client via an HTTP
   response header.  Another less recommended alternative is an HTML
   meta element.  Servers should use the HTTP response header mechanism
   whenever possible because, when using the meta element mechanism,
   there is a period of time between when the user agent begins to
   process the document and when the user agent encounters the meta
   element when the document is not protected by the policy.

4.1.  Content-Security-Policy

   A server may supply one or more CSP policies in HTTP response header
   fields named Content-Security-Policy along with the protected
   content.  Upon receiving an HTTP response containing more than one
   Content-Security-Policy header field, the user agent MUST enforce the
   most combination of all the policies contained in these header
   fields.  [TBD] should this be the most restrictive combination?

4.2.  Content-Security-Policy-Report-Only

   As an alternative, the server can also use the HTTP header "Content-
   Security-Policy-Report-Only" header field to experiment with CSP by
   only monitoring (instead of enforcing) the policy.  This feature
   allows server operators to develop their security policy in
   iterations.  They can deploy a report-only policy based on their best
   estimate of how their site behaves.  And if the site violates this
   policy, instead of breaking the site, the user agent(s) will send
   violation reports to a URI specified in the policy.  Once a server
   has confidence that the policy is appropriate, it can promote the
   report-only policy to full "Content-Security-Policy" (blocking) mode.
   As with "Content-Security-Policy", a server may supply one or
   multiple of these policies in HTTP response header fields named
   Content-Security-Policy-Report-Only along with the protected content.
   Upon receiving an HTTP response containing more than one Content-
   Security-Policy-Report-Only header field, the user agent MUST enforce
   the most combination of all the policies contained in these header
   fields.  [TBD] should this be the most restrictive combination?

   A server MUST NOT provide Content-Security-Policy header field(s) and
   Content-Security-Policy-Report-Only header field(s) in the same HTTP
   response.  If a client received both header fields in a response, it
   MUST discard all Content-Security-Policy-Report-Only header fields
   and MUST enforce the Content-Security-Policy header field.  A warning



Barth & Gondrom         Expires September 7, 2012               [Page 4]

Internet-Draft                 CSP Header                     March 2012


   SHOULD be send to the report URI as specified in the Content-
   Security-Policy, if the report address is specified.


5.  Augmented Backus-Naur Form (ABNF)

   The RFC 5234 [RFC5234] ABNF of the CSP header is as follows:


6.  ABNF

   The ABNF is as follows:

   csp-header   = "Content-Security-Policy:" OWS policy OWS

   policy            = directive-list
   directive-list    = [ directive *( ";" [ directive ] ) ]
   directive         = *WSP [ directive-name [ WSP directive-value ] ]
   directive-name    = 1*( ALPHA / DIGIT / "-" )
   directive-value   = *( WSP / <VCHAR except ";"> )



7.  Source List

   Many CSP directives may refer to sources from which content /
   resources may be loaded.  These sources are defined as a value
   defined by a source list.  Each source expression in the source list
   represents a location from which content of the specified type can be
   retrieved.  The source expression 'self' represents the set of URIs
   which are in the same origin (as defined by SAMEORIGIN [RFC6454]) as
   the protected document and the source expression 'unsafe-inline'
   represents content supplied inline in the document itself.

   source-list       = *WSP [ source-expression
                       *( 1*WSP source-expression ) *WSP ]
                       / *WSP "'none'" *WSP
   source-expression = scheme-source / host-source / keyword-source
   scheme-source     = scheme ":"
   host-source       = ( [ scheme "://" ] host [ port ] )
   keyword-source    = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"
   scheme            = <scheme> production from RFC 3986
   host              = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
   host-char         = ALPHA / DIGIT / "-"
   port              = ":" ( 1*DIGIT / "*" )






Barth & Gondrom         Expires September 7, 2012               [Page 5]

Internet-Draft                 CSP Header                     March 2012


8.  Directives

   The following CSP directives are defined:

   default-src
         If this directive is set, it it sets the default source for all
         directives that are not explicitely specified.

   script-src

   object-src

   style-src

   img-src

   media-src

   frame-src

   font-src

   connect-src

   sandbox
         [TBD]???

   report-uri
         Reports of violations of the CSP will be send to this URI

   policy-uri
         URI to load the CSP


9.  Examples

   Example Cases


10.  Acknowledgements

   This document was derived its input from specifications published by
   W3C and developed by various browser vendors like Mozilla, Google,
   Microsoftm Opera and Apple.







Barth & Gondrom         Expires September 7, 2012               [Page 6]

Internet-Draft                 CSP Header                     March 2012


11.  IANA Considerations

   This memo a request to IANA to include the specified HTTP header in
   registry as outlined in Registration Procedures for Message Header
   Fields [RFC3864]

11.1.  Registration Template


   PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

   Header field name: Content-Security-Policy

   Applicable protocol: http [RFC2616]

   Status: Standard

   Author/Change controller: IETF

   Specification document(s): draft-gondrom-websec-CSP-header

   Related information:

                                 Figure 1


12.  Security Considerations

   The introduction of the CSP http header improves the protection
   against Cross Site Scripting, CSRF and Clickjacking, however it is
   not self-sufficient on its own but MUST be used in conjunction with
   other security measures like secure coding, the Same-Origin Policy,
   Frame-Options, etc,


13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2.  Informative References

   [CLICK-DEFENSE-BLOG]
              Microsoft, "Clickjacking Defense", 2009, <http://
              blogs.msdn.com/b/ie/archive/2009/01/27/
              ie8-security-part-vii-clickjacking-defenses.aspx>.



Barth & Gondrom         Expires September 7, 2012               [Page 7]

Internet-Draft                 CSP Header                     March 2012


   [CSRF]     OWASP (Open Web Application Security Project), "OWASP
              Top-10: Cross-Site Request Forgery (CSRF)", 2010,
              <http://www.owasp.org/index.php/Top_10_2010-A5>.

   [Clickjacking]
              OWASP (Open Web Application Security Project),
              "Clickjacking", 2010,
              <http://www.owasp.org/index.php/Clickjacking>.

   [FRAME-OPTIONS]
              IETF, "The Frame-Options", December 2010, <http://
              tools.ietf.org/id/draft-gondrom-frame-options-02.txt>.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              December 2011.

   [W3C]      W3C, "W3C: DRAFT Web Application Security Working Group
              Charter", 2012,
              <http://www.w3.org/2011/07/appsecwg-charter.html>.

   [W3C-CSP]  W3C, "W3C: CSP", 2012,
              <http://www.w3.org/TR/CSP/#policies>.


Authors' Addresses

   Adam Barth
   Google, Inc.

   Email: ietf@adambarth.com
   URI:   http://www.adambarth.com/






Barth & Gondrom         Expires September 7, 2012               [Page 8]

Internet-Draft                 CSP Header                     March 2012


   Tobias Gondrom
   Kruegerstr. 5A
   Unterschleissheim,
   Germany

   Phone: +44 7521003005
   Email: tobias.gondrom@gondrom.org












































Barth & Gondrom         Expires September 7, 2012               [Page 9]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/