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: Daniel Veditz <dveditz@mozilla.com>
Date: Mon, 31 Oct 2016 14:10:52 -0700
Message-ID: <CADYDTCDYT6_R13prseG40hEM_0vAOB6-VEcx5BWsSG1xutFbjw@mail.gmail.com>
To: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>
Cc: Artur Janc <aaj@google.com>, Mike West <mkwst@google.com>, Lukas Weichselbaum <lwe@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>, Michele Spagnuolo <mikispag@google.com>
On Sun, Oct 30, 2016 at 3:18 AM, Christoph Kerschbaumer <
ckerschbaumer@mozilla.com> wrote:

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

​I don't see that restriction in either CSP2 or CSP3, though both specs are
complex and maybe I missed a section that modifies the sections I did find.​

CSP2 says "The term allowed script sources refers to the result of parsing
the script-src directive’s value as a source list
<https://w3c.github.io/webappsec-csp/2/#parse-a-source-list> if the policy
contains an explicit script-src, or otherwise to the default sources
<https://w3c.github.io/webappsec-csp/2/#default-sources>." Didn't see
anything in the section on nonces or default-src that made an exception.

CSP3 defines nonces in the generic "source list" section, and the script
section says
Inline script <https://html.spec.whatwg.org/multipage/scripting.html#script>
blocks MUST pass through §4.2.3 Should element’s inline type behavior be
blocked by Content Security Policy?
<https://w3c.github.io/webappsec-csp/#should-block-inline>. Their behavior
will be blocked unless every policy allows inline script, either implicitly
by not specifying a script-src (or default-src) directive, or explicitly,
by specifying "unsafe-inline", a nonce-source
<https://w3c.github.io/webappsec-csp/#grammardef-nonce-source> or a
hash-source <https://w3c.github.io/webappsec-csp/#grammardef-hash-source>
that matches the inline block.
... which seems pretty clear that default-src supports the same directives.

​'strict-dynamic' ought to work the same way.​

​Dan Veditz​
Received on Monday, 31 October 2016 21:11:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:58 UTC