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

Re: CSP 1.1: Behavior when presented with an invalid plugin-types directive?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Mon, 23 Jul 2012 16:09:22 -0700
Message-ID: <CAPfop_0C=k8e-uxzgy1UNEs0XPWcPj+QS2_3UGDtaCEMuR7gXQ@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Odin HÝrthe Omdal <odinho@opera.com>, public-webappsec@w3.org
I agree with Mike and like #2 more. If I am not wrong (please correct
me!), new mime types can be and are added all the time, but the
`grammar' for mime types (2 part identifier) is pretty constant.

Note that Mike's suggestion allows for application/foobar, where
application/foobar is not a mime type that the browser knows what to
do with (and the browser could say that in the console). But it will
fail loudly for just application (e.g., if developer mistakenly put a
space and typed out application / foobar )


On 23 July 2012 14:07, Adam Barth <w3c@adambarth.com> wrote:
> On Mon, Jul 23, 2012 at 7:32 AM, Odin HÝrthe Omdal <odinho@opera.com> wrote:
>> On Mon, 23 Jul 2012 07:28:46 +0200, Mike West <mkwst@google.com> wrote:
>>> I lean towards #2 as it seems less likely to leave a developer with the
>>> mistaken impression that her directive is working the way she expects (and
>>> tweaked the editor's draft to that effect over the weekend[2]).
>>>
>>> Still, the security risk of simply ignoring invalid items is probably
>>> quite low, so expansion of the syntax might be a good reason to opt for #1
>>> instead.
>>
>> I always like having a road open for expansion. Especially on something as
>> expansible as mime types.
>>
>> Ignoring invalid tokens wouldn't exclude printing out the error in the error
>> console. With all the useful stuff that is turning up in that console these
>> days, web developers gets more and more reasons to check it ;-)
>
> Yeah, that makes sense to me.  The situation is different with
> script-nonce, which we expect folks to generate programmatically.
>
> Adam
>
Received on Monday, 23 July 2012 23:10:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 July 2012 23:10:10 GMT