Re: Comments on Content Security Policy 1.0 Editor's Draft

Thanks Adam.

Replies to selected portions of your reply inline below. Elided portions are 
"works-for-me", and your clarifications/explanations where I had 
misunderstandings are helpful (thx)...


Adam replied..
 >
 > On Thu, Jun 21, 2012 at 3:09 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
 >> Comments on Content Security Policy 1.0 Editor's Draft
 >> 
http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-1.0-specification.html
 >>
<snip/>
 >> Substantive comments:
 >> ---------------------
 >>
 >> Overall..
 >>
 >> Are there any salient differences between HTML5 and HTML4 resources that
 >> browser implementers will have to code for in terms of implementing CSP
 >> policy enforcement?  Other than <applet> ?
 >
 > Not that I know of.  HTML5 defines most of these things as legacy
 > features.  We've used HTML5 as the "base" version of HTML in CSP, but
 > I don't think causes any problems.  Did you have anything specific in
 > mind?

No, nothing specific, was mostly curious given that there's some amount :) of 
legacy HTML4 in the wild, and the CSP spec calls out (only) the <applet> tag 
from HTML4 explicitly, but otherwise doesn't say anything specific about HTML4. 
So while reading the CSP spec I was wondering whether if I had a non-trivial 
HTML4 web app whether CSP would cover all the HTML4 bases, that's all. CSP 
implies "yes" but doesn't say so explicitly AFAICT.


<snip/>
 >> the spec should probably mention that it applies to today's state of the
 >> world, as described by it and it's normative references, at time of
 >> publication. Thus if someone e.g. invents some new javascript/DOM gizmo
 >> that's a possible avenue for exploitation, and it gets implemented in some
 >> web user agents (new stuff is apparently getting added and "shipped" all the
 >> time it seems), the CSP spec, UAs' CSP implementations, and existing web
 >> application CSP policies may not account for it.
 >
 > Correct.

Perhaps the CSP spec should say something explicit about this in its Security 
Considerations.


 >> This raises the question of "does the spec accurately and completely
 >> specify, as of Last Call exit time, all the various facets of
 >> HTML/DOM/javascript that are applicable for all the directive enforcement
 >> algorithms?" -- it may be good to get some appropriate experts (who haven't
 >> yet been directly involved in CSP) to do a fine-grained double-check (during
 >> Last Call say) just to make sure (?).
 >
 > Agreed.  Hopefully some of the folks who review the spec during Last
 > Call will be able to help us out in this way.

The above is sort of a nudge to the WG chairs (and the WG at large) to see 
about buttonholing appropriate folks for such review :)


<snip/>
 >> within "3.1 Policy Delivery"
 >>
<snip/>
 >>
 >> Additionally, the final paragraph of section 3.1.2 beginning "A server may
 >> monitor one policy while enforcing another policy." should arguably be a
 >> subsection on it's own, i.e. as section 3.1.3.
 >
 > I've actually just moved it to the Processing Model section, which is
 > a more sensible place for it.
 >
 >> The spec implies that the CSP/CSPRO header fields are not
 >> mutually-exclusive, but doesn't explicitly state that.
 >
 > That's what that paragraph is intended to state explicitly.

yeah, it sorta does if one follows the indirection (in the spec). also that 
section "3.3 Processing Model" is written in terms of user agent behavior until 
it reaches the "A server.." paragraph.


 > Should we try to make it clearer?

Perhaps (I can go either way). Here's a stab at a revised first sentence for 
that "A server.." paragraph..

   "A server MAY cause user agents to monitor one policy while enforcing 
another policy by returning both Content-Security-Policy and 
Content-Security-Policy-Report-Only header fields."


<snip/>
 >> within "3.2.2 script-src"..
 >>
<snip/>
 >> given the language the directive enforcement algorithm employs for
 >> 'unsafe-inline' and 'unsafe-eval', i.e. "If <one of them> is not in allowed
 >> script sources..", then given a directive of say..
 >>
 >>  script-src example.com 'unsafe-inline'
 >>
 >> ..then the 'unsafe-inline' effectively obviates inline script protection,
 >> _but_ eval will be blocked for all sources other than from example.com.
 >
 > Well, eval will be blocked from example.com too.  It's just that you
 > can load scripts from example.com, not that those scripts can use
 > eval.

Ok. I wonder if that ought to be made more clear?


Separately, I'm thinking it might be a good idea to boldface the "not"s in..

   If 'unsafe-inline' is not in allowed script sources:

   If 'unsafe-eval' is not in allowed script sources:

(eg boldface "not" is used in 3.2.2.2 Matching)


 >> It might be worth it to explain such nuances more explicitly. Perhaps could
 >> expand example 3 (which needs more full explanation anyway wrt the 'unsafe-'
 >> keyword-sources), maybe add an example 4 using script-src and 'unsafe-', and
 >> reference them from the directive sections that mention the 'unsafe-'
 >> keyword-sources.
 >
 > I've added more explanation to Example 3, but I haven't added another
 > example.  I'd rather not encourage folks to use 'unsafe-inline'
 > because that defeats the XSS protections afforded by CSP.

doh, yeah.  Hm, should we even put either of the "unsafe" directives in an example?

Or, if we feel we ought to do so (do we?), perhaps we should reiterate the 
"this obviates XSS protection" admonition?


 >> within 3.2.10 sandbox (Optional)
 >>
<snip/>
 >
 >> Also, it seems that HTML5 doesn't actually define any explicit profiles of
 >> required flags in a "forced sandboxing flag set", saying only near the end
 >> of step 20 of "5.6.1 Navigating across documents" that
 >>
 >>   "A resource by default has no flags set in its forced sandboxing flag
 >>    set, but other specifications can define that certain flags are set."
 >>
 >> So is there an explicit profile of required flags in a "forced sandboxing
 >> flag set" that CSP can reference and user agents can implement?  Otherwise
 >> it seems that it will be difficult to be able to implement sandbox
 >> enforcement in an interoperable fashion.  Or am I misunderstanding this?
 >
 > There aren't any profiles.  There's just the set of sandbox flags
 > defined in 
http://www.w3.org/TR/html5/the-iframe-element.html#attr-iframe-sandbox

Ok, sorry, I'm obviously confused by both the CSP sandbox section and the HTML5 
spec.

Is the below (closer to) correct? (this is not necessarily suggested CSP spec 
text)...


The value of the CSP sandbox directive (if a directive-value is present) may be 
a set of "keywords" specified in the HTML5 "parse a sandboxing directive" 
algorithm 
<http://dev.w3.org/html5/spec/single-page.html#parse-a-sandboxing-directive>.

These HTML5 sandboxing directive keywords are: allow-popups, 
allow-top-navigation, allow-same-origin, allow-forms, allow-scripts.

Each keyword maps to a particular flag or flags in the "sandboxing flag set" 
<http://dev.w3.org/html5/spec/single-page.html#sandboxing-flag-set>, and is 
only used to _turn off_ that flag or flags. Not all flags in the "sandboxing 
flag set" have corresponding keywords and thus cannot be turned off.

Each resource obtained by HTML5's "navigate" algorithm 
<http://dev.w3.org/html5/spec/single-page.html#navigate> has a "forced 
sandboxing flag set" 
<http://dev.w3.org/html5/spec/single-page.html#forced-sandboxing-flag-set> 
which by default has no flags set in it, but CSP implicitly defines all flags 
in the "sandboxing flag set" as being in the "forced sandboxing flag set" if 
the "sandbox" directive is set in a CSP Policy, modulo any sandboxing directive 
keywords that appear in the sandbox directive value.

Thus, an example CSP header sporting a sandbox directive, causing all 
sandboxing flags in the protected resource's "forced sandboxing flag set" to be 
set, would be..

   Content-Security-Policy: sandbox

Another example CSP policy where the "sandboxed auxiliary navigation browsing 
context flag" is _not_ set in the protected resource's "forced sandboxing flag 
set" (but all other flags are set) is..

   Content-Security-Policy: sandbox allow-popups


yes/sorta/no ?

If yes, then perhaps a bit more context ought to be added to the CSP 4.10 
sandbox section (seems to me).


 >> within "3.2.11 report-uri"..
 >>
<snip/>
 >
 >> I find this confusing (until reading to the Note at the very end)..
 >>
 >>  "Fetch the report URI from origin of the protected resource, with the
 >>   synchronous flag not set, using HTTP method POST, with a Content-Type
 >>   header field of application/json with an entity body consisting of the
 >>   violation report. The user agent must not follow redirects when fetching
 >>   this resource. (Note: The user agent ignores the fetched resource.)"
 >>
 >> In that we're trying to simply say "send the report to the address given by
 >> the web origin of the protected resource, using HTTP POST method" (yes?)
 >
 > Correct.
 >
 >> i.e. the term "Fetch" threw me off, and here it isn't linked to the HTML5
 >> "fetching" algorithm.  If in W3C parlance "fetch" is the right thing to use
 >> even here, perhaps parenthetically explain that this will result in
 >> "sending" the report.
 >
 > I've added a link to the HTML5 spec.  It's just meant to invoke the
 > HTML5 fetch algorithm to get the HTTP request set up properly (e.g.,
 > with the right referrer).

yeah, ok .... but..


 >> unfortunately, it seems the HTML5 spec doesn't, other than form submission
 >> (which is defined it seems such that it's pretty strictly tied to the <form>
 >> element processing), define an algorithm for "sending" arbitrary data, and
 >> thus we have the above tortured use of "fetch" to mean "send"  (I suppose
 >> this is a comment on an arguably missing piece in the HTML5 spec?)
 >
 > The fetch algorithm is pretty widely used in HTML5 and in other specs.
 >  Maybe it would help to move the bit about ignoring the response
 > earlier in the paragraph so that the reader's expectations are set
 > more clearly?

we could try that, plus we could add more text to explain the rationale 
(footnote? appendix?) for using an algorithm named for "fetching" stuff to 
instead "send" stuff (since the ref'd spec doesn't do that, and doesn't present 
an alternative).

This'll be pretty confusing to anyone who's new to the 
html(-and-http)-user-agent world.



 >> within "3.4 Security Considerations"..
 >>
 >> The privacy leakage aspects of the violation reports (c.f. the list
 >> discussion) should be noted.
 >
 > I've added the following text:
 >
 >       <section>
 >         <h3>Violation Reports</h3>
 >
 >         <p>The violation reporting mechanism in this document has been
 >         designed to mitigate the risk that a malicious web site could use
 >         violation reports to probe the behavior of other servers. For example,
 >         consider a malicious web site that white lists
 > <code>https://example.com</code>
 >         as a source of images. If the malicious site attempts to load
 >         <code>https://example.com/login</code> as an image, and the
 >         <code>example.com</code> server redirects to an identity provider (e.g.,
 >         <code>idenityprovider.example.net</code>), CSP will block the request.
 >         If violation reports contained the full blocked URL, the violation
 >         report might contain sensitive information contained in the
 > redirected URI,
 >         such as session identifiers or purported identities. For this
 > reason, the
 >         user agent includes only the origin of the blocked URI.</p>
 >       </section>

excellent.

In terms of completeness, I'm thinking we should have a bit more of an 
introduction to the security consdierations section -- something indicating 
that this entire spec concern security, and that the rest of the sec cons 
section illustrates specific facets.

Also, in looking at RFC3552 section "5. Writing Security Considerations 
Sections" <https://tools.ietf.org/html/rfc3552#section-5>, it seems we ought to 
note stuff in sec cons regarding..

   dependence on DNS (what if DNS is poisoned? Secure DNS (aka DNSSEC) helps..)

   all bets are off if CSP-protected resources are not fetched over secure
   transport

   the item about the world possibly changing underneath/around this spec
   (from near the beginning of this msg)

   etc.


 >> Should provide (informative?) reference(s) for:
 >>
 >> resource representation
 >
 > Done.
 >
 >> content injection vulnerabilities
 >
 > This is used only in the introduction.  Did you have a reference in mind?

only perhaps a parenthetical "(such as cross-site scripting (XSS))"

(I could not find a good reference for that particular term)


 >> cross-site scripting (XSS)
 >>
 >> bookmarklets
 >
 > These seem valuable to reference, but I'm not sure there are great
 > references for them other than what you can find easily with a search
 > engine.

how about..

cross-site scripting (XSS)
http://cwe.mitre.org/data/definitions/79.html

Bookmarklet
http://en.wikipedia.org/wiki/Bookmarklet

(I note that academic papers ref wikipedia...)



 >> editorial items:
 >> ---------------
 >>
 >> overall..
 >>
<snip/>
 >
 >> the header fields defined in this spec are formally "HTTP response header
 >> fields" and should be designated as such (at least in the first occurrences
 >> in section 3.1)
 >
 > Previously when I did something like that, Julian complained that
 > there was no such thing as a "response" header field.  There were just
 > header fields.

really? ok, fine....


HTH,

=JeffH

Received on Thursday, 28 June 2012 02:41:42 UTC