W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2012

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

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Tue, 03 Jul 2012 16:41:05 -0700
Message-ID: <4FF38311.6030400@KingsMountain.com>
To: Adam Barth <w3c@adambarth.com>
CC: W3C Web App Security WG <public-webappsec@w3.org>

 > On Tue, Jul 3, 2012 at 1:52 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
 >> when reviewing the recent "CSP 1.1: More granular source list definitions"
 >> thread, I had these questions regarding CSP 1.0...
 >>
 >> 1. unless I've missed it, there does not appear to be any suggestion in the
 >> spec regarding whether the user agent to log and/or report CSP Policy parse
 >> errors, nor discussion whether a directive with a source-expression
 >> violating the grammar -- such as Odin's example..
 >>
 >>   script-src: http://my-site.com/js/
 >>
 >> ..which a lenient parser would likely match to the host-source production --
 >> must/should be enforced or ignored by the user agent.
 >
 > There's no requirement to log errors to the console, but a bunch of
 > implementations do.  I guess we could send violation reports, but
 > logging to the developer console seems to be effective in helping
 > folks author good policies.

understood. In any case, the spec is silent about parsing errors AFAICT (yes?). 
  Mentioning them (in the framework section), and their ramifications would be 
a good idea it seems.

Plausibly, given the present spec language, might one implementation chose to 
successfully honor something like "script-src: http://my-site.com/js/" as 
"script-src: http://my-site.com", while another impl doesn't honor it at all 
due to not strictly matching the host-source production?  If so, the spec 
should probably stipulate behavior.

Also, proposing (very simply) how parse error occurrences might be conveyed 
("via user agent error console") in the Implementation Considerations section, 
is perhaps worthwhile. This sort of impl suggestion is made in various other 
specs. Of course adding it formally to violation reports is more work, and I'm 
not suggesting that (was just an idea).


 >> 2. Why does the directive production have a rigid requirement on one space
 >> char between directive-name and directive-value ?  given that directives
 >> have the ";" separator, why not..
 >>
 >>   directive         = *WSP [ directive-name [ 1*WSP directive-value ] ]
 >>
 >> which is more lenient for site operators to get right?
 >
 > It's just to make the parsing unambiguous.

yeah, i see that in step 2.3 of "parse a CSP policy"

 > Notice that source-list
 > allows leading WSP, which means any non-zero amount of WSP is allowed
 > here anyway.

doh.  nevermind.


=JeffH
Received on Tuesday, 3 July 2012 23:41:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2012 23:41:30 GMT