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

On Fri, Oct 28, 2016 at 3:20 PM, Artur Janc <aaj@google.com> wrote:

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

I agree that consistency is very important, but I am afraid current CSP
spec is already *not* consistent in that case. E.g. we allow unsafe-eval as
well as unsafe-inline to appear in script-src as well as in default-src,
but we only allow nonce to appear within script-src but not in default-src,
right? The fact that strict-dynamic only works with a valid nonce (which is
only allowed within script-src) and further that strict-dynamic is proposed
as a Cross-Site-Scripting protection mechanism which should apply only to
scripts makes me really want to restrict strict-dynamic to only appear
within script-src. Further, in my opinion, we should not complicate things
for developers as well as for browser vendors. I think my example above,
where srcs are invalidated only for script loads but not for other loads
(e.g. image loads) is really confusing for everyone.

As Arthur points out, every sane developer would place strict-dynamic
within script-src anyway, why not restrict it to script-src? Reason I am so
tenacious is because I would like to avoid corner cases. Firefox got it
wrong initially and it seems also chrome invalidated srcs not only for
scripty requests. Thanks to Dan for pointing out that problem when
reviewing Firefox's implementation. If everyone else feels different, than
fine by me but I would really like us to reconsider if allowing
strict-dynamic within default-src is a good idea or just creates confusion
and corner cases.


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