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

`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:01:22 +0200
Message-ID: <CAKXHy=fKCo2R4-4rwqjJXtDan_E-ZdhJDMMaDR8XUhNXnSMjyw@mail.gmail.com>
To: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>
Cc: 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>, Lukas Weichselbaum <lwe@google.com>, Michele Spagnuolo <mikispag@google.com>
(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).


> 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:02:17 UTC

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