W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2016

Re: `default-src` and 'strict-dynamic' (was Re: 'strict-dynamic' syntax (was Re: On the Insecurity of Whitelists and the Future of CSP))

From: Lukas Weichselbaum <lwe@google.com>
Date: Fri, 28 Oct 2016 13:50:06 +0200
Message-ID: <CAKz2OCsVBFTZCXEPb+wyH8e5szEzALSkDEVt34OTuhcNR25hJw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Daniel Veditz <dveditz@mozilla.com>, Artur Janc <aaj@google.com>, Anne van Kesteren <annevk@annevk.nl>, "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C Web App Security WG <public-webappsec@w3.org>, Craig Francis <craig.francis@gmail.com>, Michele Spagnuolo <mikispag@google.com>
On Fri, Oct 28, 2016 at 1:01 PM, Mike West <mkwst@google.com> wrote:

> (Forking the thread for clarity)
>
> On Fri, Oct 28, 2016 at 12:36 PM, Christoph Kerschbaumer <
> ckerschbaumer@mozilla.com> wrote:
>
>> When reviewing Firefox patches for strict-dynamic I considered a few
>> cases how someone could write a CSP policy using strict-dynamic. Let's have
>> a look:
>>
>
> Interesting!
>
> With the caveat that I haven't checked Chrome's behavior (and I don't
> think I ever thought about `default-src`... oops!), this is how I'd
> interpret these policies:
>
>
>> 1) default-src 'strict-dynamic' foo.com; script-src 'nonce-asdf'
>>
>
> For scripty requests, the check resolves into comparing against
> `'nonce-asdf'` with no special dynamic behavior  (as `script-src` overrides
> `default-src` entirely).
>
>
>> 2) default-src 'strict-dynamic' foo.com
>>
>
> For scripty requests, this would be equivalent to `'none'`, as we'd drop
> the list of sources, and be left with nothing.
>
> For non-scripty requests, this would be equivalent to `foo.com`, as
> `'strict-dynamic'` only has effect when processing `script-src` (
> https://w3c.github.io/webappsec-csp/#script-src-pre-request).
>
Seems that Chrome currently drops the whitelist in presence of
'strict-dynamic' also for non-scripty requests.

>
>
>> In order to craft a valid or somehow useful CSP policy relying on
>> 'strict-dynamic' one has to at least specify a valid nonce, right? The
>> first case does that and it seems somehow intuitive.
>>
>
> Note that the first case would not apply `'strict-dynamic'`, as it
> overrides `default-src`.
>
>
>> The second case however misses to specify a nonce. In that case foo.com
>> needs to be invalidated for script loads but not for image loads, which
>> seems counter intuitive. Since one needs to define a valid nonce anyway
>> (which is only allowed within script-src), why do we also allow
>> strict-dynamic to also appear within default-src? In my opinion it would be
>> clearer to only allow strict-dynamic to appear within script-src, or am I
>> missing something? Thoughts?
>>
>
> I'd agree that we should warn the user if they use `'strict-dynamic'`
> without a nonce or a hash source.
>
> I think I disagree that we shouldn't allow it to appear in `default-src`.
> Consider '`unsafe-eval`', which also only has effect for `script-src`.
> `default-src 'unsafe-eval' foo.com` is valid, even though it has slightly
> different behavior when considering scripts than other types of resources.
> I'd suggest that the same applies here.
>

> -mike
>
Received on Sunday, 30 October 2016 13:46:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:21 UTC