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

Re: Finalizing the shape of CSP ‘unsafe-dynamic’

From: Mike West <mkwst@google.com>
Date: Mon, 6 Jun 2016 17:48:25 +0200
Message-ID: <CAKXHy=czEqkGwKSB+5E_QYqJtcDhJm=bTdDJdMdiYOK6yeK+Vw@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Artur Janc <aaj@google.com>, Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Daniel Bates <dabates@apple.com>, Devdatta Akhawe <dev@dropbox.com>
On Mon, Jun 6, 2016 at 4:45 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
> Are there use-cases for these separately? I'm all for adding things to the
>> platform if they're useful, but I'm not convinced from this thread that
>> these keywords add anything other than complexity. That is, Brad can
>> accomplish the things he's interested in with two policies, which I think
>> actually turns out to be a more powerful primitive than splitting the
>> keywords.
> hmm .. the use case I am interested in is script-src
> https://www.dropbox.com/script/require.js 'allow-dynamic'
> Right now, this would force me to use a nonce. The nonce then is a
> leakable token present in the HTML of the page. Not a huge risk, but still.

I see. That makes sense to me: you want the loader functionality, but you
don't want the added surface area of the capability token.

I think I agree that there are two orthogonal concerns here (loading an
initial script via a nonce, hash, or URL on the one hand, and allowing that
initial script to load other things on the other), and splitting them up
makes sense. I worry a bit that folks would simply slap the dynamic keyword
onto an already weak policy and call it done, but I suppose that doesn't
make things any worse than they are today.

'allow-dynamic' (or just 'dynamic', maybe?) and 'nonce-only'?
'drop-whitelist' is a little too broad, since nonces are part of the
whitelist, and we're not dropping those. 'ignore-hosts'?

Concretely, would Dropbox use one (or both?) of these keywords if we
>> implemented them?
> Not really sure yet. But, I am inclined towards the script-src example
> above.

Cool, good to hear, thanks!

While we're on the topic, I'd like to harden that example via externalized
hashes (e.g. `sha256-abc...` would allow `<script integrity="sha256-abc..."
...>` to load). I'd like to find a mechanism to do so in a backwards
compatible way. We discussed it briefly at our last meeting. Anyone have
any good ideas? :)

Received on Monday, 6 June 2016 15:49:14 UTC

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