Re: Making it easier to deploy CSP.

On Sat, Feb 13, 2016 at 7:44 AM, Mike West <mkwst@google.com> wrote:

> On Sat, Feb 13, 2016 at 4:47 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>
>> Hey Mike
>>
>> I am probably confused but would we get something similar by just using a
>> nonce- source and some UA detection to send the big whitelist for browsers
>> that don't support nonces?
>>
>
> I'd prefer to avoid forcing folks into UA detection. I recognize that it's
> important, given bugs in various UAs, but I'm reluctant to give up on
> backwards compatibility entirely.
>
>
>> Is 'unsafe-dynamic' needed only for backwards compatibility for browsers
>> that don't support nonce source?
>>
>
> The new keyword would serve as an explicit opt-in to cascading the nonce's
> capability down to scripts loaded by scripts you've chosen to trust. That
> doesn't _actually_ add any new power to nonces, as any running script can
> grab the nonce (as noted in the polyfill). It does add a little bit of
> power to hashes (as that behavior can't be polyfilled). It's also a
> significant win in terms of deployability, as very little code would
> actually need to change. Again, anecdotally, a significant subset of the
> Google properties that folks spot-checked could use this mechanism without
> changing any JavaScript code at all, just by turning on a nonce-generator
> in their templating library.
>

To illustrate this I put together a small testbed which enables
'unsafe-dynamic' and loads a dozen popular JS APIs: Facebook/Twitter
sharing buttons, Google Maps, etc:

https://csp-experiments.appspot.com/unsafe-dynamic
(needs Chrome Canary with experimental platform features enabled in
chrome://flags)

With 'unsafe-dynamic', scripts dynamically added to the page by a trusted
script (one which we allowed to run by giving it a crypto nonce or
whitelisting its hash) will be allowed to execute without requiring each JS
library to explicitly pass around nonces when loading such sub-scripts.

Based on a quick look at the behavior in the testbed it seems that most of
the popular widgets work properly with such a policy. Our hope is that this
will allow developers to add nonces to their static <script> blocks and
have a safe CSP without having to worry about whitelisting all
domains/paths used by JS APIs included on their pages (more often than not
that would lead to an unsafe policy because of JSONP endpoints in the same
domains).

Cheers,
-Artur