Subresource Integrity

#1

Post by mastahyeti » Fri, Sep 18, 2015, 6:06 PM UTC

Subresource Integrity
githubengineering.com

Re: Subresource Integrity

#2

Post by adrianmacneil » Fri, Sep 18, 2015, 6:31 PM UTC

This looks like a fantastic technology to protect against maliciously injected javascript. Great to see GitHub leading the charge here and taking their security seriously.

Re: Subresource Integrity

#3

Post by linksbro » Fri, Sep 18, 2015, 6:35 PM UTC

This is great, but only if your CDN is not also serving your HTML files! (static sites)

Re: Subresource Integrity

#4

Post by dchest » Fri, Sep 18, 2015, 6:39 PM UTC

Should be "sha256-..." (without dash between sha and 256)

Re: Subresource Integrity

#5

Post by adrianmacneil » Fri, Sep 18, 2015, 6:48 PM UTC

linksbro wrote: post #3

This is great, but only if your CDN is not also serving your HTML files! (static sites)

For a static site I expect you would be far less concerned about session hijacking or XSS if someone took over that domain. Even a complete single-page app should serve the initial html request from a trusted domain/server.

Re: Subresource Integrity

#6

Post by mastahyeti » Fri, Sep 18, 2015, 6:48 PM UTC

dchest wrote: post #4

Should be "sha256-..." (without dash between sha and 256)

Thanks. I updated the post and opened a PR to fix the README on sprockets-rails. https://github.com/rails/sprockets-rails/pull/273

Re: Subresource Integrity

#7

Post by bsimpson » Fri, Sep 18, 2015, 6:48 PM UTC

What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. (Since you'd now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.)

To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for minor updates, the user often won't notice the difference. Now, these cases are hard failures. That's not necessarily a bad thing, but I wonder if there's a path here to tell the browser "you have an old version of the content; go get the new version."

CDNs and invalidations can be tricky, and it sounds like this could lead to things being broken more often if you're caught in the window where one piece updates before the other.

Re: Subresource Integrity

#8

Post by mastahyeti » Fri, Sep 18, 2015, 6:51 PM UTC

bsimpson wrote: post #7

What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. (Since you'd now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.) To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for…

This isn't a concern with our implementation because a hash of the asset bundle is also included in the URL. This is a pretty common cache-busting technique for static assets and lets you send more aggressive cache directives to the browser.

Re: Subresource Integrity

#9

Post by deftnerd » Fri, Sep 18, 2015, 6:53 PM UTC

You can use https://srihash.org to hash links and update your HTML.

Re: Subresource Integrity

#10

Post by bosdev » Fri, Sep 18, 2015, 6:56 PM UTC

I really wish browsers could leverage this for caching across origins. If my copy of jQuery has the same SHA256 as another file the user has already downloaded, there's no need to load it again