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: Artur Janc <aaj@google.com>
Date: Fri, 28 Oct 2016 15:20:18 +0200
Message-ID: <CAPYVjqpErOaV==0L1z4QAZj0NEVkWPuBO3-aVpvCPc9sqvXycg@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Lukas Weichselbaum <lwe@google.com>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Daniel Veditz <dveditz@mozilla.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:53 PM, Mike West <mkwst@google.com> wrote:

> 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.
>>>
>>
I agree with Mike that 'strict-dynamic' should be consistent with the
behavior of other keywords which apply only to script-src, such as
'unsafe-eval'. If they are respected when specified in default-src, we
should do the same here.

The fact that you can use them in default-src is a little surprising to me,
but consistency seems more important. In practice, developers tend to use
script-src anyway so I don't think there are many deployed policies with
such keywords in default-src.
Received on Friday, 28 October 2016 13:21:12 UTC

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