- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Wed, 23 Mar 2011 16:55:22 -0700
- To: W3C Web Security Interest Group <public-web-security@w3.org>
I've read through csp-unofficial-draft-20110315.html and have the below largely
editorial comments on it. This is long, so I've attempted to coalesce some
overall comments at the top, and then all the detailed ones below.
I'm not going to attempt, in this message, to address the "Issues" that are
presently identified in the spec -- they should probably each be discussed in
individual message threads.
HTH,
=JeffH
------
feedback on csp-unofficial-draft-20110315.html
<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-unofficial-draft-20110315.html>
[ please view using a fixed-pitch font ]
Contents
--------
I. Substantive Issues/Questions/Comments
II. Terminology to define
III. Editorial Overall
IV. Detailed Editorial
----------------------------------------
I. Substantive Issues/Questions/Comments
----------------------------------------
1. X-Content-Security-Policy-Report-Only
> 3.1.1 |X-Content-Security-Policy| Response Header
>
> ....
>
> Content Security Policy can be deployed in report-only mode
> by sending the HTTP response header
> |X-Content-Security-Policy-Report-Only|.
see also S4.4 "Report-Only Mode".
Is this to be used in conjunction with the X-Content-Security-Policy ? or
instead of it ? This isn't clear in the spec. However the Note at the end of
S4.4 implies that the answer is "both" depending on the desires of the server
admin.
2. The object, or "values", of policy directives are all syntactically
"sources" whose syntax is based on the syntax for serialized origins defined in
draft-abarth-origin <http://tools.ietf.org/html/draft-abarth-origin>.
Presently the source et al semantics & grammar isn't defined until section 3.4
and 3.5. I suggest that much of this material (S3.4 and S3.5.1) should occur
before the directive descriptions, or be explicitly referenced from the
directive descriptions.
3. Need an explicitly defined procedure for matching a source expression with a
origin extracted from a presented URI.
This should define a means for comparing sources (leverage section 4 of
draft-abarth-origin) specified in policy to sources (ie orgins) presented in
content, as well as how to extract an origin from a URI (ie invoke section 3 of
draft-abarth-origin).
4. Grammar issues/comments:
The text in S3.4.1 indicates that a "host" can be null, but..
host = [ "*." ] 1*host-char *( "." 1*host-char )
/ "*"
..should first "1*host-char" be " *host-char " ? ie can "host" be null ?
ah --- the nullness is in the source production...
source = scheme ":"
/ ( [ scheme "://" ] host [ port ] )
/ "'self'"
; <scheme> production from RFC 3986
..in that source can have just a " scheme: ".
Port also can't be null on its own..
port = ":" ( 1*DIGIT / "*" )
These could be re-written so that their being null is a property of those
productions themselves rather than a property of the source production - this
might be more clear.
Unless there's some subtle advantage to having the grammar as presently
specified that I'm missing?
5. HTML5 vs HTML4
Are there salient differences between HTML5 and HTML4 that browser implementers
will have to code for in terms of implementing CSP policy enforcement?
Also, the <source> and <track> html5 elements have "src=" attrs, but aren't
mentioned in the spec.
6. Is a description of a policy intersection algorithm necessary?
Yes, I tend to think so because we need to (attempt to) ensure that UAs will
get same result when intersecting policies.
-------------------------
II. Terminology to define
-------------------------
These are terms/phrases that in reading through the spec it seemed needed a
concise definition with supporting citations in some cases...
chrome: or resource: URI
content
CSS properties
default port (for a scheme)
embedded browsing context
Event-handling HTML attributes
external script resource
favicons
image resources
inline script
internal <script> nodes
internationalized domain names
javascript (ie == ecmascript)
javascript: URIs
load (content)
plugins
redirect
shortcut icons
sub-document resource
"token", "LDH, and "LDH tokens"
window parent chain
---------------------
III. Editorial Overall
---------------------
[NOTE: these are detailed comments that affect several/many sections due to
reuse of certain text patterns - coalescing here in order to reduce length of
the detailed editorial comments below. ]
1. Ought to cast HTTP terminology in proper HTTP form throughout. E.g.
"response header" is "HTTP response header field".
2. Should illustrate the ABNF for the directives themselves in the directive
description sections. Retain the "Content Security Policy Grammar" S3.5, but
perhaps rename it to "Collected CSP Grammar" (also, it can be an appendix).
This is how its done in the httpbis spec(s).
3. In sections 3.2.1 through 3.2.10 the following pattern is used in the first
para..
The |foo| directive defines the list of sources that are permitted to
load bar things.
Then subsequent paras stipulate various aspects of the directive value and its
syntax, and the following pattern occurs in all mentioned sections..
The origin portion of the |foo| { attribute | value } MUST be present
in the source list defined by the |bar| directive in order for the
{ whatever } to be requested.
Afterwards, there's a statement to the effect..
User-agents MUST NOT request |bar| things from non-approved sources.
I suggest rewriting the above portions of those sections into new first paras
along these lines...
The |foo| directive applies to {stuff}. The directive's value is the
exclusive list of sources from which the UA MUST load {stuff}. The UA
MUST NOT load {stuff} from any source not appearing on the list.
This, among other things, will make the "The origin portion of the..." pattern
to go away, which is good because: these attributes/values are all URIs.
RFC3986 doesn't define a "origin portion" of URIs, and neither does
draft-abarth-origin, though the latter defines a way to compute the origin of a
given URI.
4. Also in all the directive description sections, there's this pattern..
If the |foo| directive is not present in a policy and the
|default-src| directive is present in the policy,
user-agents /must/ subject requests for |bar| resources to the
|default-src| directive.
I suggest overall rewriting the 2nd clause of these sentences to follow this
pattern..
UAs MUST apply the |default-src| directive to any requests for
|bar| resources.
5. these other specs are cited in-line, but don't appear in the Normative
References section, but should...
[origin]
[CSS3-Images]
[RFC 5890]
[ECMAscript]
6. I suggest adding an informative reference to (make the citation in the
Introduction)..
Stamm, Sterne, Markham, "Reining in the Web with Content Security Policy",
WWW 2010, April 26–30, 2010, Raleigh, North Carolina, USA.
----------------------
IV. Detailed Editorial
----------------------
[Note:
In the below, I use "UA" as abbreviation for "user agent".
The quoted portions of the CSP spec below are extracted from a plain-ASCII-text
spec rendering, and thus denotes highlighted text |like so|, etc.
]
> 1. Introduction
>
> /This section is non-normative./
>
> The purpose of this specification is to provide a method for web
> applications to broadly address a large class of vulnerabilities known
> as *content injection* which is the primary focus of Content Security
> Policy. Other threats, such as cross-site request forgery, are not a
^
(CSRF)
> focus of this specification.
Should provide references for "content injection" and "cross-site request forgery".
> Content Security Policy is a declarative policy framework that enables
> web authors and server administrators to specify the permitted sources
> of content in their web applications and to restrict the capabilities of
> that content. Content Security Policy mitigates and detects content
> injection attacks such as cross-site scripting (XSS).
need to define "content"
https://secure.wikimedia.org/wikipedia/en/wiki/Web_content
define intended audience roles
define "(content) capabilities"
> 2. Conformance Criteria
>
> This specification is written for resource authors and user-agents.
you mean authors of user agents?
how is "user-agent" expressed in other w3c specs? is it hyphenated?
> 2.1 Terminology
>
> This section defines several terms used throughout the document.
>
> The term security policy, or simply policy, for the purposes of this
> specification refers to either:
>
> 1. A set of security preferences for restricting the behavior of
> content within a document or resource
document should be "web document" ?
possible informative ref (?):
https://secure.wikimedia.org/wikipedia/en/wiki/Web_document
resource should be "web resource" ?
possible informative ref (?):
https://secure.wikimedia.org/wikipedia/en/wiki/Web_resource
*** need to rationalize " document == client side of a web app execut(ing,ed)
within user agent"
>
> 2. A fragment of text that codifies these preferences
>
text? appearing where?
perhaps "a codified textual expression of such preferences" ?
> A server transmits their security policy for a particular resource as a
> composition of directives, such as |default-src 'self'|, each of which
> controls a specific set of content capabilities within a document
> rendered by a user-agent.
define "content capabilities" (see above)
> A directive is composed of a directive name, which indicates the class
> of content that is to be restricted by the user-agent, and a directive
> value, which specifies the range of permitted behavior for that content
> class.
examples of "content classes" ? definition ?
> Most of the policy directives defined in this document take a list of
> sources as the directive value.
Thus a "source" is a "behavior" ? (the prior para defines "directive value" in
terms of "permitted behavior")
> A source is a location, such as a
> network host, that is permitted to serve content of a particular type.
^
to the web application
> Sources can be specified according to scheme, host and port.
this is "origin", shud mention here. also specifying sources here means doing
so in the context of CSP directives, not in the context of "src=" html attrs.
> Content Security Policies are applied by a user-agent on a *per-resource
> basis*.
"resource" definition ? (see above) Should use "web resource" ?
> This means that when a server emits a Content Security Policy in
> a response, the user-agent applies the stated policy to the document
> returned *in that response only* for the lifetime of the document. That
> document is often referred to in this specification as the protected
> document or protected resource.
This applies to "origin document loads", yes?
I.e. this is assuming that a "document" is returned in any particular response
to a UA request, which isn't the case if, say, the UA is requesting <img>,
<script>, etc. on behalf of an instantiated web resource (yes?)
need to define "lifetime of the document"
here "document" / "resource" == instantiated web app client side stub ?
plus such an instantiated web resource can perform various further interactions
with the origin server and other servers during its "lifetime". the policy also
applies to these, yes? should express this in the spec.
> When Content Security Policy is enabled by a server, several base
> restrictions <#base-restrictions> are applied in the user-agent
> processing model. These base restrictions provide support for the
^
addressing
> primary threat model.
> The <script>, <object>, <embed>, <applet>, <img>, <video>, <audio>, <link>,
> <frame> and <iframe> elements are defined in the HTML 5 standard. [HTML5].
>
> The <applet> element is defined in the HTML 4.01 standard. [HTML401].
>
> The @font-face CSS rule is defined in the CSS Fonts Module Level 3 standard.
> [CSS3FONT]
>
> The XMLHttpRequest object is defined in the XMLHttpRequest standard.
> [XMLHTTPREQUEST]
for the above quoted paras: s/standard/specification/g
> 3. Syntax
>
> This section defines the syntax and semantics of the policy directives
> and policy delivery mechanisms introduced by this specification.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
del
>
> The Augmented Backus-Naur Form (ABNF) notation used in this document is
> specified in RFC 5234. [ABNF <#bib-ABNF>]
>
>
> 3.1 Policy Delivery
>
> The policy can be delivered from the server to the client via an HTTP
> response header or an HTML |meta| element. Both mechanisms indicates
> that a resource /must/ have the set of restrictions specified in the
> policy applied to it by the user-agent while rendering the content.
suggest last sentence as..
The inclusion of a policy via either mechanism indicates to the user-
agent that it MUST apply the set of specified restrictions when
processing the content.
Note that here "processing" essentially means while that instance of the web
app's client side is instantiated by the UA.
This has implications for any content fetched via e.g. XHR and similar means
while that particular web app client side instance exists.
Include another sentence after the above one..
Precedence rules are given in the next section
for the situation where both mechanisms appear simultaneously.
(I'm suggesting the precedence rules appear next)
> 3.1.1 |X-Content-Security-Policy| Response Header
^ ^
HTTP Field
>
> The policy is transmitted as the HTTP header value and is parsed by the
> client before it receives the response body.
hm, that makes assumptions about how UAs work. Perhaps..
The |X-Content-Security-Policy| HTTP Response Header Field conveys policy
as its header field value. The UA (MUST?) parse and interpret the policy
before commencing processing of the HTTP message body content.
> 3.1.2 |<meta http-equiv="X-Content-Security-Policy">| HTML Element
>
> The policy is transmitted as the |content| attribute of the element.
Suggest rewrite the above as..
3.1.2 |<meta>| HTML Element
The HTML <meta> Element may be used to convey policy. The
//meta@http-equiv attribute is set to the value
"X-Content-Security-Policy", and the //meta@content attribute
is set to the value of the policy string (defn?). For example:
<meta http-equiv="X-Content-Security-Policy" content="...policy ..." />
..where "//meta@http-equiv" is shorthand for "the http-equiv attr of the <meta>
tag" (I'm not sure offhand how w3c specs are to refer to such things).
> 3.1.3 Delivery Mechanism Precedence
>
> Policies expressed in |X-Content-Security-Policy| response headers take
> precedence over policies expressed via |meta| elements. If no
> |X-Content-Security-Policy| response headers are present, then the first
> Content Security Policy |meta| element found in the document |head|
> takes precedence.
I suggest that this subsection precede the response & meta element subsections
(above).
> 3.2 Directives
>
> This section describes the policy directives introduced by this
^^^^^^^^^^^^^^^^^^^
del
> specification.
^^^^^^^^^^^^^
del
> 3.2.1 |default-src|
>
> The |default-src| directive defines the default policy for all types of
> content which are not explicitly restricted by any of the other
> directives specified in a policy. The directive value represents the
> default list of sources that are permitted to load content of types not
> specified elsewhere in the policy.
suggested rewrite..
The |default-src| directive applies to all content types.
Its value is an exclusive list of sources from which the UA MUST load
content types for which there are no other explicit directives in the
policy. In those cases where the |default-src| directive applies, the
UA MUST NOT load content for those content types from any
source not appearing on the list.
> An exception to the |default-src| directive value being used as the
> default policy exists in the case of the |frame-ancestors|
> directive, which /must/ be enforced as |*| (all
> sources) when not explicitly declared.
^^^^^^^
ancestors?
>
> User-agents /must/ enforce the |default-src| directive for any content
> request which would be restricted by one of the following more specific
> directives when that specific directive is not present in the policy.
the above para no longer needed if revised para above is used.
> 3.2.2 |script-src|
>
> The |script-src| directive defines the list of sources that are
> permitted to load external |<script>| elements.
suggested rewrite..
The |script-src| directive applies to |<script>| elements having
a "src" attribute. The |script-src| directive defines a list of sources
from which the UA MUST load any external script resource. The UA MUST
NOT load external script resources from any source not appearing on the
list.
> The |origin| portion of the |src| attribute of an external |<script>|
> element /must/ be present in the source list defined by the |script-src|
> directive in order for the script resource to be requested.
>
> User-agents /must not/ request script resources from non-approved sources.
The above two paras are not needed if the first para is re-written as suggested.
> If the |script-src| directive is not present in a policy and the
> |default-src| directive is present in the policy,
> user-agents /must/ subject requests for script resources to the
> |default-src| directive.
suggested rewrite of 2nd clause..
UAs MUST apply the |default-src| directive to any requests
for external script content.
> 3.2.3 |object-src|
>
> The |object-src| directive defines the list of sources that are
> permitted to load |<object>|, |<embed>| and |<applet>| elements.
suggested rewrite..
The |object-src| directive defines the list of sources from which
the UA MUST load |<object>|, |<embed>| and |<applet>| resources.
The UA MUST NOT load |<object>|, |<embed>| and |<applet>| resources
from any source not appearing on the list.
> The |origin| portion of the element attribute containing the URI
> location of the embedded content /must/ be present in the source list
> defined by the |object-src| directive in order for the embedded content
> to be requested.
>
> User-agents /must not/ request |<object>|, |<embed>| or |<applet>|
> resources from non-approved sources.
above paras not needed if first para rewritten as suggested.
>
> If the |object-src| directive is not present in a policy and the
> |default-src| directive is present in the policy,
> user-agents /must/ subject requests for |<object>|, |<embed>| and
> |<applet>| resources to the |default-src| directive.
suggested rewrite of 2nd clause..
UAs MUST apply the |default-src| directive to any requests for
|<object>|, |<embed>| and |<applet>| resources.
> Note:
> In order to achieve comprehensive XSS protection, sites must include
> both a |script-src| directive and a |object-src| in their policy, or a
> |default-src| directive, which covers both cases, due to some plugins
> having scripting capability.
It isn't clear what cases "both cases" refers to. Also why "some plugins having
scripting capability" is relevant here -- this is the only place in present
spec where the term "plugins" appears.
Perhaps this Note should appear (or be duplicated) elsewhere, e.g. in a more
"overall" section concerning the effects of CSP policy?
> Issue:
> Some plug-ins, e.g. Google Gears, do not load via URLs. How does
> |object-src| interact with these kinds of plug-ins?
This issue begs possibly needing more context in spec wrt "how plugins are or
are not 'loaded from URIs'" and definition(s) of "plugins".
> 3.2.4 |img-src|
>
> The |img-src| directive defines the list of sources that are permitted
> to load images via |<img>| elements, CSS properties and shortcut icons,
> or favicons.
>
> The |origin| portion of the |src| attribute of an |<img>| element /must/
> be present in the source list defined by the |img-src| directive in
> order for the image resource to be requested.
>
> The |origin| portion of the |url()| or |image()| value of any CSS
> property that is capable of loading an image /must/ be present in the
> source list defined by the |img-src| directive in order for the image
> resource to be requested.
>
> The |origin| portion of the |href| attribute of a |<link rel="icon">| or
> |<link rel="shortcut icon">| element /must/ be present in the source
> list defined by the |img-src| directive in order for the shortcut icon,
> or favicon, to be requested.
>
> User-agents /must not/ request image resources from non-approved sources.
>
> If the |img-src| directive is not present in a policy and the
> |default-src| <#default-src> directive is present in the policy,
> user-agents /must/ subject requests for image resources to the
> |default-src| <#default-src> directive.
>
> The |url()| and |image()| notations are defined in the CSS Image Values
> and Replaced Content Module Level 3 standard. [/CSS3-Images
> <http://www.w3.org/TR/css3-images/>/]
Suggest rewriting above section as..
The |img-src| directive applies to image resources referenced or loaded
via |<img>| elements, CSS properties and shortcut icons, or favicons.
The directive's value is the exclusive list of sources from which the UA
MUST load image resources. This applies to image resources denoted by:
The |src| attribute of |<img>| elements.
The |url()| or |image()| value of any CSS property that is capable
of loading an image. The |url()| and |image()| notations are defined
[CSS3-Images].
The |href| attribute of a |<link rel="icon">| or
|<link rel="shortcut icon">| element.
If the |img-src| directive is not present in a policy and the
|default-src| directive is present in the policy,
UAs MUST apply the |default-src| directive to any requests for image
resources.
UAs MUST NOT request image resources from any source not appearing on
the directive's source list.
>
> 3.2.5 |media-src|
>
[ similar suggestions for 3.2.5 |media-src| through 3.2.9 |xhr-src| ]
> 3.2.10 |frame-ancestors|
>
> The |frame-ancestors| directive defines the list of sources that are
> permitted to embed the protected resource as an |<iframe>|, |<frame>| or
> |<object>| element.
>
> If the |frame-ancestors| directive is present in a policy the |origin|
> portion of the |location.href| of every |window| in the protected
> document's window parent chain /must/ be present in the source list
> defined by the |frame-ancestors| directive in order for the protected
> document to be used in the embedded browsing context.
>
> If the |frame-ancestors| directive is not present in a policy its value
> /must/ be assumed to be |*|, or all sources.
>
> User-agents /must not/ use a protected document in an embedded browsing
> context if any |window| in the protected document's window parent chain
> has a |location.href| representing a non-approved source.
Suggest rewriting above section as..
The |frame-ancestors| directive defines the exclusive list of
sources within which the UA is permitted to embed the protected
resource as the content of an |<iframe>|, |<frame>| or |<object>|
element.
If the |frame-ancestors| directive is present in a policy, then each
element of the set of target sources, as extracted from the
|location.href| of every |window| in the protected document's window
parent chain, MUST match at least one element in the |frame-ancestors|
directive's source list in order for the UA to load the protected document
into the embedded browsing context. User-agents MUST NOT load a protected
document into an embedded browsing context if any |window| in the
protected document's window parent chain does not satisfy the
foregoing criteria.
If the |frame-ancestors| directive is not present in a policy then
the protected document MAY be loaded into any embedded browsing context.
This is equivalent to a |frame-ancestors| directive whose value is
|*|.
>
> ...snippage...
>
>
>
> 3.2.12 |policy-uri|
>
>
> ...snippage...
>
> User-agents /should/ resolve a relative |policy-uri| using the same
> scheme, host and port as the protected resource.
suggested rewrite of that para...
If the value of a |policy-uri| directive is a relative URI [URI], then
the UA SHOULD resolve it using the same |origin| as the protected
resource.
> 3.2.13 |options|
>
> The |options| directive defines a set of modifications to the Content
> Security Policy base restrictions.
"base restrictions" should link to S4.1
> The |options| directive value is comprised of a space-separated LDH
> tokens,
"token", "LDH, and "LDH tokens" are all undefined.
> each specifying a modification to the default Content Security
> Policy processing model.
How can these options be used? Only on their own, eg..
x-content-security-policy: options disable-xss-protection
..or in combination with actual policies..
x-content-security-policy: default-src 'self' ; \
options disable-xss-protection
?
According to the CSP grammar, it appears the latter is the case, but it isn't
illustrated in the text.
> 3.3 Proposed Directives
>
> /This section is non-normative./
>
> This section describes policy directives that have been proposed for
> inclusion in this specification but have not yet been accepted.
This is ok for a draft such as this, but this section ought to be removed
when/if this spec moves to working-draft state.
> 3.4 Source Expressions
>
> /This section is non-normative./
>
> This section describes the structure of the directive values that
> restrict the loading of content into a protected document.
seems to me that this ought to be a normative section.
are it's subsections to be considered non-normative also ?
> A source expression represents a combination of a scheme, a set of
> hosts, and a network port from which content may be loaded. Source
> expressions may contain a wildcard, |*|, used to match a set of hosts or
> a set of ports.
>
> A source expression may specify a set of hosts represented by any number
> of DNS labels and an optional leading hostname wildcard
> which matches 0 or more leading DNS labels. If 0
> DNS labels are specified in the source expression, a wildcard represents
> the set of all hosts.
>
> Examples of host-only source expressions are |example.net| and
> |*.example.com|.
>
> Source expressions may specify a scheme and/or port from which content
> is limited to loading from. Content loading may be restricted to a
> single scheme by declaring the scheme at the beginning of a source
> expression. Content loading may also be restricted to a particular port
> by declaring the port number at the end of a source expression. A port
> wildcard <#port-wildcards> |*| may also be used in place of a single
> port number to permit content from any port.
>
> If a scheme is not specified as part of the source expression, a
> user-agent /must/ use the same scheme as the protected document. If a
> port number is not specified as part of the source expression, a
> user-agent /must/ use the default port for the source's scheme, whether
> the scheme was explicitly stated in the source expression or was
> inherited from the protected document.
>
> An example of a source expression specifying a scheme restriction is
> |https://example.com|. An example of a source expression specifying
> scheme and port restrictions is |https://*.example.org:443|.
>
> A source expression may consist entirely of a scheme. In this case,
> user-agents /must/ only restrict content to be loaded from the specified
> scheme and /must not/ apply any host or port restrictions. This allows
> host-less schemes <#host-less-schemes> to be used as sources in security
> policies.
>
> User-agents /must/ treat all invalid source expressions encountered in a
> directive value as empty.
>
> Servers /must/ specify internationalized domain names in security
> policies according to their punycode representations. [/RFC 3492
> <http://tools.ietf.org/html/rfc3492>/]
suggested rewrite (which assumes a new section gets added detailing how one
performs a match between a source expression and a pressented origin)...
A source expression consists of a combination of a scheme, a host
expression, and a network port expression.
[ insert appropriate ABNF chunk here ]
Host and network port expressions may each contain a wildcard, |*|,
used to match a set of hosts or a set of ports. In host expressions,
the wildcard MAY appear only in the left-most label position and
matches zero or more labels. If a host expression contains only
the wildcard and no DNS labels, the wildcard represents the set
of all hosts.
Note:
Examples of host-only source expressions are |example.net| and
|*.example.com|.
In port expressions, the |port wildcard| matches all port numbers.
If a scheme is not specified as part of a source expression, the
user-agent MUST use the same scheme as the protected resource. If a
port number is not specified as part of the source expression, a
user-agent MUST use the default port for the source's scheme, whether
the scheme was explicitly stated in the source expression or was
inherited from the protected document.
Note:
An example of a source expression specifying a scheme restriction is
|https://example.com|. An example of a source expression specifying
scheme and port restrictions is |https://*.example.org:443|.
A source expression MAY consist of only a scheme. In this case,
user-agents MUST only apply policy to web resources having the specified
scheme and MUST NOT apply any host or port restrictions. This allows
host-less schemes to be used as sources in policies.
User-agents MUST ignore invalid source expressions.
[ need to address having an accurate discussion of how to handle
IDNs -- that's out-of-scope of these comments ]
[ include a collected set of source examples like the below:
For example, various valid sources:
http://example.com:8080
http://*.example.com:80
http://*.example.com:*
http://*:*
http://*
example.com
*.example.com
example.com:8080
example.com:*
*:8080
http:
*
]
I'm not sure the sections 3.4.1 through 3.4.3 are really needed if the above is
carefully crafted.
> 3.4.4 Source Expression Keywords
>
> A source expression /may/ make use of one of the following keywords
> which serve as a shorthand replacement for a set of hosts.
>
> Source expression keywords begin and end with a single-quote character
> in order to differentiate them from network hosts of the same name.
>
> The |'none'| keyword represents the empty set of hosts. If used, no
> hosts are permitted for that directive.
>
> The |'self'| keyword represents the source serving the protected
> resource. When used, content may be loaded from the scheme, host and
> port that the protected resource was served from.
suggest rewrite of above para...
The |'self'| keyword represents the |origin| of the protected
resource. If used, the directive restricts operations to only that
|origin|.
> User-agents /must/ ignore any unrecognized source expression keywords.
>
>
> 3.5 Formal Policy Grammar
>
>
> ...snippage...
>
>
>
> 3.6 Sample Policy Definitions
>
>
> ...snippage...
>
> 3.7 Violation Report Syntax
>
> This section defines the structure of the violation report sent by a
> user-agent when a protected resource's security policy is violated.
>
> ...snippage...
>
>
> Sample Policy Violation Report
>
> In the following example a page located at
> |http://example.org/page.html| was requested and returned with its
> response a policy of |default-src 'self'; policy-uri
^^^^^^
report?
> http://example.org/csp-report.cgi|. The policy was violated by an image
> element from |evil.example.com| which had been embedded in the page.
suggested rewrite of above para..
In the following example a html document located at
|http://example.org/page.html| has been loaded. The policy returned
with the document was:
|default-src 'self'; report-uri http://example.org/csp-report.cgi|
The document attempted to request and load |http://evil.example.com
/image.png|. This violated the default-src directive. The following
report was sent to |http://example.org/csp-report.cgi| as the contents
of the entity-body of an HTTP POST message [HTTP11], per the |report-uri|
directive.
> Note:
> In the above sample report the |violated-directive| field was sent in
^^^^^^
example
> the way it was interpreted by the user-agent. The directive was made
> explicit by replacing the keyword |'self'| with the explicit host name
> of the protected resource. This is recommended behavior for user-agents
> as it reduces ambiguity, making policy violations easier to trace by
> server admins.
^^^^^^
administrators
> 4. User-Agent Behavior
>
> This section describes required behavior for conformant user-agents when
> processing a Content Security Policy and applying restrictions to a
> protected resource.
>
>
> 4.1 Base Restrictions
>
> The following restrictions /must/ be applied by a user-agent rendering a
^ ^^^^^^^^^
base processing
> protected resource which has declared a Content Security Policy unless
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
del
> the policy includes directives which disable or modify the restrictions.
^
resource's
Is there an example where the latter clause would be in effect?
> 4.1.1 Inline scripts /must not/ execute
^^^^^^^^^^
Having rfc219 conformance statements in section headers is not generally done
me thinks.
Perhaps..
4.1.1 Inline scripts disabled
> User-agents /must/ prevent inline scripts from executing. These include:
>
> * Contents of internal <script> nodes
> * javascript: URIs
> * Event-handling HTML attributes
>
> The |disable-xss-protection| options directive may be used to
> disable this base restriction, though it is not recommended to do so as
> all cross-site scripting protection provided by Content Security Policy
> will be effectively disabled.
above para rewrite..
The |disable-xss-protection| options directive may be used to
disable this base restriction, though it is not recommended because it will
effectively disable all cross-site scripting protection provided by Content
Security Policy.
> The supported method for executing ECMAScript in a protected document is
> to include <script> elements in the document whose sources are permitted
> by the protected document's policy. User-agents /must/ execute all
> external scripts whose |src| attribute refers to a permitted source and
> which are served with a Content-Type of |application/javascript| or
> |application/json|.
suggested rewrite..
The supported method for executing ECMAScript in a protected document is
to include external script resources (see definition) in the document.
These external script resources MUST reference |origins| that are
permitted by the protected document's policy and which are served with
a Content-Type of |application/javascript| or |application/json|.
> Issue:
> Do further Content-Types need to be permitted for ECMAScript?
>
> If a protected resource's policy declares a |report-uri|
> and this base restriction is violated, user-agents /must/ generate a
> violation report with the |violated-directive| field
> set to "Base Restriction Violation: no inline scripts will execute" and
> /must/ send the report to the |report-uri| specified in the policy.
>
>
> 4.1.2 Code /must not/ be created from strings
suggest..
4.1.2 Code is not created from strings
> User-agents /must/ prevent strings from being converted to ECMAScript
> code, including calls to:
>
> * |eval()|
> * |new Function()| constructor
> * |setTimeout()| called with a String argument
> * |setInterval()| called with a String argument
>
> The |eval-script| options directive may be used to disable
> this base restriction, though it is not recommended to do so as the risk
^^^^^^^^^^^
since
> of DOM-based cross-site scripting will be greatly increased.
>
> If a protected resource's policy declares a |report-uri|
> and this base restriction is violated, user-agents /must/ generate a
> violation report with the |violated-directive| field
> set to "Base Restriction Violation: no code will be created from
> strings" and /must/ send the report to the |report-uri| specified in the
> policy.
>
>
> 4.1.3 data: URIs /must not/ be permitted
suggest..
4.1.3 data: URIs are not evaluated
> User-agents /must/ prevent data: URIs from being used to load inline
> content unless the protected document's policy explicitly permits the
> data: protocol for that type of content.
>
> If a protected resource's policy declares a |report-uri|
> and this base restriction is violated, user-agents /must/ generate a
> violation report with fields set appropriately to
> describe the violation and /must/ send the report to the |report-uri|
> specified in the policy.
>
>
> 4.1.4 CSS-ECMAScript bindings /must/ come from chrome: or
> resource: URIs
suggest..
4.1.4 CSS-ECMAScript bindings restrictions
> User-agents which allow external ECMAScript content to be bound to
> document elements via CSS rules /must/ prevent such bindings unless the
> external content is served as a chrome: or resource: URI.
>
> An example of such a CSS-ECMAScript binding technology is XBL. [XBL]
>
> This restriction prevents untrusted remote content from being injected
> into a document via a stylesheet because both the chrome: and resource:
> protocols serve only local, trusted content.
>
> If a protected resource's policy declares a |report-uri|
> and this base restriction is violated, user-agents /must/ generate a
> violation report with fields set appropriately to
> describe the violation and /must/ send the report to the |report-uri|
> specified in the policy.
>
>
> 4.2 Interpreting Multiple Policies
>
> When multiple instances of the Content Security Policy response header
> are present in a single HTTP response, the user-agent /must/ enforce the
> most restrictive intersection of the policies received. This means that
> no action can be taken by the user-agent when rendering the protected
^^^^^^^^^
processing
> document unless every policy directive of every policy header received
> permits such an action. If an action taken by a user-agent will violate
> any of the policy directives received in any response header, that
^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
in-force 's del
> action /must not/ be taken by the user-agent.
^^^^^^^^^^^^^^^^^^
del
>
> Issue:
> Is a description of a policy intersection algorithm necessary?
>
> When differing |report-uri| values are received in multiple policy
> headers the intersection of the policy values is NOT taken. Rather,
^^^^^^
report-uri
> user-agents /must/ send a single report to each valid URI specified in
> any |report-uri| directive received in a policy header.
>
> When multiple Content Security Policy |<meta>| elements are present in
> the |head| section of a protected resource, the first |<meta>| element
> /must/ be parsed as the document's security policy and enforced. All
> subsequent policy |<meta>| elements /must/ be ignored by the user-agent.
>
> Issue:
> What should happen when multiple instances of the same directive but
> with different values occur within a single policy header or meta
> element, i.e. should they be combined or intersected as they are
> successively parsed?
>
>
> 4.3 Handling Policy Parsing Errors
>
> This section describes how user-agents should handle various error
> conditions encountered when parsing Content Security Policies. The error
> conditions described in this section are distinct from the policy
> violations described earlier in this document. While policy violations
> /must/ be reported to servers when a |policy-uri| has been declared,
> policy parsing warnings /should/ be reported locally in the user-agent's
> error console, and /should not/ be reported to the remote server.
>
>
> 4.3.1 Unrecognized Directive
>
> When a user-agent receives a directive name that it does not recognize,
> the user-agent /must/ not parse the directive name or value and /must/
> skip ahead to the next directive name present in the policy or to the
> end of the policy if no further directives are declared.
suggested rewrite..
If a policy contains a directive the UA does not recognize,
the user-agent MUST ignore the directive and its value.
> The user-agent
> /should/ report a warning message to the error console containing the
> unrecognized directive name.
>
>
> 4.3.2 Unrecognized |options| Token
>
> When a user-agent receives a token in an |options| directive that it
> does not recognize, the user-agent /must/ skip over it.
If a policy contains a |options| directive token the UA does not recognize,
the user-agent MUST ignore the token.
> User-agents
^^^^^^^^^^^
The user-agent
> /should/ report a warning message to the error console containing the
> unrecognized token.
>
>
> 4.3.3 Directive Syntax Error
>
> When a user-agent receives a policy directive that violates Content
^^^^^^^^^
del
> Security Policy syntax, the user-agent /must/
> discard the entire policy and enforce a policy of |default-src 'none'|
> on the protected resource. User-agents /should/ report a warning message
> to the error console communicating that an invalid policy was received.
this should just be wrt the entire policy parsing correctly, yes? because
unrecognized but syntactically correct directives are simply ignored.
> 4.3.4 No Directives
>
> When a user-agent receives a policy that contains no directives
> recognized by the user-agent, the user-agent /must/ discard the entire
> policy and enforce a policy of |default-src 'none'| on the protected
> resource. User-agents /should/ report a warning message to the error
> console communicating that an invalid policy was received.
>
> Issue:
> This issue was called out in the directives section and
> remains unresolved. Should an empty policy result in the most
> restrictive policy i.e. |default-src 'none'| or the most permissive
> policy i.e. |default-src *; options disable-xss-protection eval-script|
> being applied?
>
>
> 4.3.5 Other Parsing Errors
>
> Any other parsing errors not described in the above sections /must/
> result in the user-agent enforcing a policy of |default-src 'none'| on
> the protected resource and /should/ result in the user-agent reporting a
> warning message to the error console describing the error.
>
>
> 4.4 Report-Only Mode
>
> This section describes a mode of operation for user-agents in which
> security policies are parsed and violations are logged as they occur,
> but without blocking content from loading or executing as the user-agent
^^^^^^^^
restricting
> would under normal processing of Content Security Policy.
^^^^^^^^^^^^^^^^^^^^^^^
a protected resource.
>
> Content Security Policy can be deployed by servers in report-only mode
> by sending a |X-Content-Security-Policy-Report-Only| response header
> or by placing a |<meta
> http-equiv="X-Content-Security-Policy-Report-Only">| policy element
> in the |<head>| section of a document.
This is done in conjunction with sending a policy?
i.e. two response headers are sent..
X-Content-Security-Policy: ...
X-Content-Security-Policy-Report-Only
?
Does the ordering of the headers matter?
X-Content-Security-Policy-Report-Only has no defined header-field value?
(see more below)
>
> When report-only mode is enabled by a server, the user-agent /must/ log
> all policy violations and policy parsing errors in the same manner that
> it would in normal blocking mode, including sending violation reports
^^^^^^^^^^^^^
processing
> to the server if a report-uri
> directive is present, as well as logging any appropriate errors or
> warnings locally to the error console. In report-only mode, the
> user-agent /must not/ prevent any content from loading or executing
> normally due to violations of the protected document's stated security
> policy.
>
> Note:
> This mode of operation is intended to ease deployment for servers that
> want to experiment with a security policy but aren't ready to take the
> step of policy enforcement. Such sites can develop a security policy
> according to their knowledge and assumptions about how the site
> functions and receive reports when content in the site behaves in a
> manner contrary to the developed policy. Report-only mode can also be
> used in parallel with blocking mode as it is a useful test vehicle for a
> stricter policy. The stricter report-only policy can be deployed in
> production environments with no compatibility risk and feedback can be
> collected from any violation reports received. Once a site has
> confidence that the policy is appropriate, they can promote the
> report-only policy to normal blocking mode.
Ok, so it sounds like the way X-Content-Security-Policy-Report-Only is intended
to work is that the report-only header does convey a policy declaration, and
the report-only header can be used in conjunction with the regular CSP header
according to the above para.
eg..
X-Content-Security-Policy: ...
X-Content-Security-Policy-Report-Only: ...
The implication is ordering doesn't matter.
> 4.5 Other User-Agent Considerations
>
> /This section is non-normative./
>
> This section contains miscellaneous items for consideration by
> user-agent implementers.
>
>
> User Scripts
>
> Content Security Policy should not interfere with the operation of
> user-supplied scripts such as third-party user-agent add-ons and
> JavaScript bookmarklets.
this needs more careful delineation imv in order to differentiate between such
things ("user-supplied scripts") and the components proper of the protected
resource (ie protected web app client side stub).
> Redirecting Content Loads
>
> For any protected document, when a request for a sub-document resource
> is redirected to another location, whether temporary or permanent, all
> locations in the resource's redirect chain, including the initial
> location and all subsequent redirected locations, must be permitted by
> the protected document's security policy in order for the sub-document
> resource to be allowed to load. If any step in the redirect process
> violates the protected document's security policy, the request should be
> terminated immediately and the load canceled.
the above should be re-written with precise terminology and conformance
statements. am assuming it is a MUST.
> Future Directives
>
> In order to support new policy directives in the future, user-agents
> must parse but ignore unrecognized directives. For this reason, this
> document specifies that user-agents /must/ skip over unrecognized
> directives but /should/ report them on the error console.
>
>
> 5. HTTP Server Behavior
>
> This section describes required behavior for conformant servers when
> emitting a Content Security Policy.
>
>
> 5.1 HTTP Header Placement
>
> The Content Security Policy HTTP response header
> /may/ be present in the
> Message Headers section of a server's HTTP response.
>
> The Content Security Policy HTTP response header
> /must not/ be present in
> the Trailer section of a server's HTTP response. If a user-agent
> receives a Content Security Policy as an HTTP Trailer, it /must not/
> parse the policy or attempt to enforce any restrictions on the rendered
> document. ^^^^^^^^
^^^^^^^^
processing of the resource.
but what if the UA receives policy in both headerr/meta and trailer?
in that case the former ought to be enforced and the latter ignored, yes?
> HTTP Message Headers and Trailers are defined in the HTTP 1.1 standard.
> [HTTP11 <#bib-HTTP11>]
---
end
Received on Wednesday, 23 March 2011 23:55:54 UTC