Mvc: Subresource Integrity TagHelper [Discuss]

Created on 21 Sep 2015 · 9Comments · Source: aspnet/Mvc

Something for ScriptTagHelper and maybe a StyleSheetTagHelper?

The website author includes an integrity attribute on JavaScript and CSS tags, specifying the cryptographic digest of the resource being loaded from the third party. When the browser fetches the resource, it computes the file's digest and compares it with the value from the integrity attribute. If the values match, the resource is loaded. Otherwise, the browser refuses to load the resource.

W3C Working Draft http://www.w3.org/TR/SRI/

GitHub blog on it: http://githubengineering.com/subresource-integrity/

Could have a compute hash with local file type approach

enhancement needs design

Source

benaadams

Most helpful comment

I'd like to vote to bring this back...

Unclear what we could do that was correct and worked at runtime.

Given:

<script src="~/dist/vendor.js" asp-append-version="true"></script>

You're already generating a SHA256 hash on the file contents.

This value, base64 encoded, could be exposed as the integrity attribute along with adding the appropriate crossorigin attribute.

ctolkien on 11 Feb 2018

👍4

All 9 comments

Sounds pretty cool. This isn't in the plan for this release, but certainly worth looking at in the future.

Eilon on 22 Sep 2015

Unclear what we could do that was correct and worked at runtime.

dougbu on 12 Sep 2017

I'd like to vote to bring this back...

Unclear what we could do that was correct and worked at runtime.

Given:

<script src="~/dist/vendor.js" asp-append-version="true"></script>

You're already generating a SHA256 hash on the file contents.

This value, base64 encoded, could be exposed as the integrity attribute along with adding the appropriate crossorigin attribute.

ctolkien on 11 Feb 2018

👍4

Re-opening for discussion. The bug triage team will review again.

Eilon on 12 Feb 2018

👍1

@Eilon - FYI this issue is still closed.

Buuuut I was thinking about this. If we're generating the SRI based on the hash of the file, and our system is compromised, it doesn't actually provide a huge a mount of benefit - we'll just generate a new hash which matches the compromised file and the browser will happily carry on.

It might help in the case where someone meddles with the resource on the wire, but given HTTPS is taking over I'm not sure how much of a concern this is.

ctolkien on 20 Feb 2018

Oops, I must have pressed the wrong button! Actually re-opened now.

Eilon on 21 Feb 2018

Moved this out to 2.2.0 as we won't be doing this earlier than that.