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: Mike West <mkwst@google.com>
Date: Fri, 28 Oct 2016 13:53:16 +0200
Message-ID: <CAKXHy=cMfsiy_TPQcp2jGD8StobcMhRK8M9tDP7+8gbjx9LQGg@mail.gmail.com>
To: Lukas Weichselbaum <lwe@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:50 PM, Lukas Weichselbaum <lwe@google.com> wrote:

> 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.
>

Doesn't surprise me. Someone should write a test and file a bug. :)


>
>>
>>> 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 Friday, 28 October 2016 11:54:11 UTC

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