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

Re: Making it easier to deploy CSP.

From: Mike West <mkwst@google.com>
Date: Wed, 17 Feb 2016 11:34:17 +0100
Message-ID: <CAKXHy=dgw1YJgpG0iPsFpq3mVj=Y0DYx9+1K+=8nzX14vy8Ehg@mail.gmail.com>
To: Artur Janc <aaj@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Lukas Weichselbaum <lwe@google.com>, Michele Spagnuolo <mikispag@google.com>
On Wed, Feb 17, 2016 at 2:12 AM, Artur Janc <aaj@google.com> wrote:

> On Mon, Feb 15, 2016 at 12:55 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>> 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.

Jumping in on this small point: In general, CSP enables pages to opt-into
stricter rules than the platform defaults. That is:

The internets say "Yeah, sure, you can load script X! No worries!" A CSP
whitelist says "No way, script X is totally out of bounds." The
'unsafe-dynamic' keyword we're discussing says "No way, script X is out of
bounds, unless it's inserted in this particular way." This is basically the
same as every other keyword. Take `unsafe-eval`, for instance: it loosens
the default meaning of `script-src`, but only up to the point that it
matches the platform default.

At worst, CSP is exactly the same as the platform default (e.g. `script-src
* blob: 'unsafe-inline' 'unsafe-eval'`). Even in that case, the page can't
do anything it couldn't have done without CSP. That's what I mean when I
talk about CSP as being strictly negative. Carveouts within the negativity
which enhance deployability seem in line with that general philosophy.

Received on Wednesday, 17 February 2016 10:35:07 UTC

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