Intent to Implement and Ship: CSP hash expressions matching external scripts.

121 views
Skip to first unread message

Mike

unread,
Mar 29, 2017, 9:26:24 AM3/29/17
to blink-dev, Marc Treib

Contact emails

tr...@chromium.org, mk...@chromium.org


Spec

https://w3c.github.io/webappsec-csp/#external-hash


Summary

CSP3 allows hash expressions to match external scripts, by relying on SRI as underlying infrastructure. That is, given `Content-Security-Policy: script-src 'sha256-abc123' 'sha512-321cba'`, `<script integrity="sha256-abc123" crossorigin ...></script>` will be allowed.

Motivation

Developers at places like GitHub are interested in moving from a list of allowed script origins to a content-based mechanism that sits on top of their existing usage of Subresource Integrity. Other folks have expressed interest in building out a "trusted loader" mechanism, combining hashes with `strict-dynamic` to verify the script that's being empowered to load more script.


In general, folks that are using SRI can quite easily begin allowing only those trusted hashes to execute on their pages, which seems like a pretty clear win.


Interoperability and Compatibility Risk

This is a new feature with low compatibility risk. There is a risk that developers will attempt to rely on it in browsers that don't yet support the matching mechanism, but that can be best resolved by other browsers implementing the feature.


Edge: No signals

Firefox: Public support in https://github.com/w3c/webappsec-csp/issues/78.

Safari: No signals

Web developers: Positive signals from GitHub and Dropbox, also in https://github.com/w3c/webappsec-csp/issues/78. Also, I was only able to convince treib@ to implement this because he needs it for a revamp of Chrome's new tab page... so. :)


Ongoing technical constraints

None


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

Yes or no. If no, explain why certain platforms will not be included in your implementation.


OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=706380


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4626666856906752


Requesting approval to ship?

Yes.


-mike

Dimitri Glazkov

unread,
Mar 29, 2017, 11:00:55 AM3/29/17
to Mike, blink-dev, Marc Treib
LGTM1

Chris Harrelson

unread,
Mar 29, 2017, 11:45:16 AM3/29/17
to Dimitri Glazkov, Mike, blink-dev, Marc Treib
LGTM2

LGTM1
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

PhistucK

unread,
Apr 2, 2017, 3:15:36 AM4/2/17
to Chris Harrelson, Dimitri Glazkov, Mike, blink-dev, Marc Treib
Since this may have severe security consequences (pages that only rely on hashes in their policies but do not block domains can enable cross site scripting in unsupported browsers), I think it might makes sense to coordinate shipping this feature with other browsers.


PhistucK

Mike

unread,
Apr 6, 2017, 5:41:13 AM4/6/17
to blink-dev, chri...@chromium.org, dgla...@chromium.org, mk...@chromium.org, tr...@chromium.org, ckersc...@mozilla.com, fre...@mozilla.com
On Sunday, April 2, 2017 at 9:15:36 AM UTC+2, PhistucK wrote:
Since this may have severe security consequences (pages that only rely on hashes in their policies but do not block domains can enable cross site scripting in unsupported browsers),

I think the failure case would be the opposite of your suggestion. That is, given a page with a policy like `script-src 'sha256-abc'`, a browser that supports this feature would allow execution of `<script src="https://example.com/yay.js" integrity="sha256-abc"></script>`, while a browser that didn't support the feature would block execution.

Have I misunderstood your suggestion?
 
I think it might makes sense to coordinate shipping this feature with other browsers.

I would love other vendors to implement this mechanism. :)

Firefox is the only other browser that supports SRI, and their developers were positive on this change in the discussion at https://github.com/w3c/webappsec-csp/issues/78 (and in person at TPAC last year). I'll CC some of their developers explicitly, but I suspect they're not going to be able to commit to a timeline.

Given that this mechanism will allow us to ship some changes to Chrome's new tab page with a more robust policy than we'd otherwise be able to achieve, and given that we have clear demand from external developers (at GitHub in particular), I'm comfortable with the level of risk we'd be taking on by being first. The tests Marc adds in his implementation will make it easier for those other vendors to build their own implementations, hopefully speeding things along.

-mike

Jochen Eisinger

unread,
Apr 6, 2017, 5:42:35 AM4/6/17
to Mike, blink-dev, chri...@chromium.org, dgla...@chromium.org, tr...@chromium.org, ckersc...@mozilla.com, fre...@mozilla.com
lgtm3

PhistucK

unread,
Apr 6, 2017, 6:47:40 AM4/6/17
to Mike, blink-dev, Chris Harrelson, Dimitri Glazkov, Marc Treib, ckersc...@mozilla.com, fre...@mozilla.com
Right, I misunderstood. :)
So new browser versions will actually be sort of opening an attack vector (rather than blocking it)... That is a bit controversial to me, but, oh, well...


PhistucK

--

Mike West

unread,
Apr 6, 2017, 7:06:29 AM4/6/17
to PhistucK, blink-dev, Chris Harrelson, Dimitri Glazkov, Marc Treib, Christoph Kerschbaumer, fre...@mozilla.com
On Thu, Apr 6, 2017 at 12:46 PM, PhistucK <phis...@gmail.com> wrote:
Right, I misunderstood. :)
So new browser versions will actually be sort of opening an attack vector (rather than blocking it)... That is a bit controversial to me, but, oh, well...

The site is allowing specific content based on the hash. Do you think it adds an attack vector if that content is delivered over the network as opposed to being delivered inline in the document?

To me, the important thing is that the content matches the developer's expectations. I don't think that the content's provenance matters at all if we ensure that verification, which I think SRI does pretty cleanly.

-mike

PhistucK

unread,
Apr 6, 2017, 7:29:59 AM4/6/17
to Mike West, blink-dev, Chris Harrelson, Dimitri Glazkov, Marc Treib, Christoph Kerschbaumer, fre...@mozilla.com
The risk is really low (site wide policies for scripts that may affect an unintended certain page in a different way), which is why it is only "a bit controversial", but still controversial.


PhistucK
Reply all
Reply to author
Forward
0 new messages