- From: Artur Janc <aaj@google.com>
- Date: Fri, 28 Oct 2016 15:20:18 +0200
- 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>
- Message-ID: <CAPYVjqpErOaV==0L1z4QAZj0NEVkWPuBO3-aVpvCPc9sqvXycg@mail.gmail.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