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