Intent to Implement and Ship: The 'unsafe-dynamic' CSP source expression.

[Mike West]

Note: This is a somewhat belated intent. I started on a prototype in February (https://codereview.chromium.org/1641533006), and it turned out to be trivial enough to build that there's not much implementation left to do.

# Contact Email
mk...@chromium.org

# Spec
https://w3c.github.io/webappsec-csp/#unsafe-dynamic-usage

# Summary
The 'unsafe-dynamic' source expression allows a developer to more easily deploy Content Security Policy with nonce- and hash-based whitelists. This new source expression allows script loaded via nonces or hashes to load more script, which supports widgets and libraries that are otherwise difficult to lock down.

# Motivation
CSP is difficult to deploy, period. It's even harder to deploy safely, especially on sites which depend upon large CDNs and other multi-party origins (`google.com`). See `https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22` for a great set of examples of trivial bypasses to apparently strong whitelists. It's possible to mitigate these risks by adding lots of detail to whitelists, but adding detail is brittle, awkward, and difficult in itself.

Google's security team would like to use nonces and hashes instead, as a mechanism for whitelisting specific scripts, rather than any script on an origin/path. While it's possible to wait for every library and widget to add code to support nonces-as-capability-tokens, Artur has put together https://csp-experiments.appspot.com/unsafe-dynamic, showing how a number of popular widgets and libraries "just work" with this new expression (try it in Chrome with the experimental web platform features flag off, and then on).

# Interoperability and Compatibility Risk
The compatibility risk is very low. The source expression is specified such that it remains backwards compatible for browsers that don't support the expression by disabling any whitelist which is delivered in the same policy. https://w3c.github.io/webappsec-csp/#unsafe-dynamic-usage has an example of how this would work. User agents that support the expression get more comprehensive XSS mitigation, but user agents that don't aren't left out in the cold.

Moreover, Google's security team has actively begun deploying it experimentally on public-facing servers without ill-effect (`bugs.chromium.org` is serving such a policy today), and given their active engagement we should be able to easily adapt Chrome's implementation to match any changes which might crop up in the future.

Other vendors haven't jumped up and down in glee at the opportunity to implement this expression. I'd summarize the thread at https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0048.html as "Sounds interesting, but is it really _necessary?_", with some questions raised about whether or not we should simply wait for libraries and widgets to do this work themselves. My suggestion is that this is a very small change which is equally low-risk, and has the advantage of enabling strong security policies today, with existing code (see Artur's demo above).

# Ongoing technical constraints
None

# Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.

# OWP launch tracking bug
https://crbug.com/589380

# Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5633814718054400

# Requesting approval to ship?
Yes.

-mike

[Rick Byers]

LGTM1

Seems potentially valuable and relatively low risk.  I love the emphasis on pragmatic incremental adoption (rather than requiring co-ordination between consumers and libraries to derive any value)!  Like other bleeding-edge CSP work, worst case and this doesn't pan out to be too valuable (and so we don't achieve interoperability) we can remove it without much negative effect, right?  So it seems worth the cost to me to ship this to make progress on addressing the "is this really necessary" question.

[Jochen Eisinger]

lgtm2

[Dimitri Glazkov]

LGTM3.

[Mike West]

On Mon, Apr 18, 2016 at 7:14 PM, Rick Byers <rby...@chromium.org> wrote:

LGTM1

Seems potentially valuable and relatively low risk.  I love the emphasis on pragmatic incremental adoption (rather than requiring co-ordination between consumers and libraries to derive any value)!  Like other bleeding-edge CSP work, worst case and this doesn't pan out to be too valuable (and so we don't achieve interoperability) we can remove it without much negative effect, right?  So it seems worth the cost to me to ship this to make progress on addressing the "is this really necessary" question.

Two updates here:

1. I think we're making progress towards solidly including the keyword in CSP3. Other vendors were receptive at the most recent WebAppSec face-to-face.

2. Based on those conversations, however, we're renaming the expression from 'unsafe-dynamic' to 'strict-dynamic': https://github.com/w3c/webappsec-csp/commit/3476890664ada8efe2122301e6a4901cb12b520e. I think we might be able to merge that change back to ensure that 'unsafe-dynamic' never hits stable. I've updated https://www.chromestatus.com/feature/5633814718054400 accordingly.

-mike