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

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 12 Sep 2012 23:33:17 -0700
Message-ID: <CAJE5ia-HVTyk2zTRx1ZqpsDvw6oTSoZ1iLq2yz749-0tUCJJPA@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Cc: W3C Web App Security WG <public-webappsec@w3.org>
On Tue, Sep 11, 2012 at 1:41 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
> Adam replied:
>> 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
>
> Ok.  I suggest, though, that a clear example be added to the spec
> illustrating that (in CSP 1.0)  source-list components of ext-host-source
> syntax (eg http://my-site.com/js/) will be matched as if they were only of
> host-source syntax, i.e. any paths will be ignored.

Done:

http://dvcs.w3.org/hg/content-security-policy/rev/753fefedaf45

Adam
Received on Thursday, 13 September 2012 06:34:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 September 2012 06:34:40 GMT