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

Re: Making it easier to deploy CSP.

From: Artur Janc <aaj@google.com>
Date: Wed, 17 Feb 2016 02:12:14 +0100
Message-ID: <CAPYVjqr3qYT-V35aUfkQyKPDb_G3LgtsWubM+3Gu4cVnyxbr7A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Lukas Weichselbaum <lwe@google.com>, Michele Spagnuolo <mikispag@google.com>
On Mon, Feb 15, 2016 at 12:55 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 14 February 2016 at 16:39, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
> > Personally, my preference for increasing complexity is in the order---web
> > apps and then browsers and then standards.
>
> The priority of constituencies would (perfectly) disagree on this point.
>
> https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>
> The thing I'm trying to wrap my head around is how this fits with the
> general CSP design pattern.  How does adding this directive narrow the
> set of things that are permitted?  It actually appears to do the
> opposite.  The purpose being to give dynamically inserted scripts an
> exemption.
>

In a way, the directive would indeed expand the set of scripts which can be
loaded -- because scripts added dynamically to the page by previously
trusted scripts wouldn't be be subject to the script-src whitelist. At the
same time, point #2 in Mike's original description proposes ignoring the
whitelist altogether in the presence of unsafe-dynamic. This, in turn,
narrows down which scripts can be loaded by the page so that *only* those
with a nonce/hash, and their descendants, would be allowed to load.

In principle, unsafe-dynamic could propagate trust to dynamically created
scripts without affecting the whitelist, so that you could have *both* a
script-src whitelist and unsafe-dynamic to allow loading of additional
trusted scripts from outside of the whitelist. The problem with that
approach is that it doesn't allow you to create a policy that would be both
secure and backwards-compatible for browsers which don't support
unsafe-dynamic; if you remove the whitelist then the page will break in
older browsers, and if you keep both the whitelist and unsafe-dynamic then
the policy will still be as insecure as your original whitelist.

BTW, a side assumption is that if you can add nonces to static <script>
elements to "bless" them for unsafe-dynamic, it is feasible to add them to
all static script blocks on the page. This way you can fully rely on nonces
to confer trust, rather than on the whitelist.
Received on Wednesday, 17 February 2016 01:13:18 UTC

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