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: Adam Barth <w3c@adambarth.com>
Date: Thu, 5 Jul 2012 14:47:29 -0700
Message-ID: <CAJE5ia925AcnN057DWtOp7yxwtGY0ELT7u3yRFXeUOr2bYqryQ@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Cc: W3C Web App Security WG <public-webappsec@w3.org>
On Thu, Jul 5, 2012 at 8:42 AM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
>>> 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.
>>
>> There isn't a notion of a parse error in the spec.  There's the set of
>> strings that servers ought to generate and a requirements for how user
>> agents must interpret every possible input.
>
> Ok, thx, if i understand correctly, directive value tokens that don't match
> the source-expression ABNF is ignored by the "parse a source list" algorithm
> and is simply not added  to the resultant set of source expressions in step
> 3.
>
> So for CSP 1.0, if one has a directive with a value like so..
>
>    script-src http://my-site.com/js/
>
> ..which doesn't match any source-expression grammar,

Ah, you're right that there's a subtle bug.

"For each token returned by splitting source list on spaces, if the
token matches the grammar for source-expression, add the token to the
set of source expressions."

should read

"For each token returned by splitting source list on spaces, if the
token matches the grammar for source-expression or ext-host-source,
add the token to the set of source expressions."

Then the net result will be treating it like the following:

script-src http://my-site.com

Adam
Received on Thursday, 5 July 2012 21:48:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 July 2012 21:48:29 GMT