19 ms·
Do not let your CDN betray you: use subresource integrity (2015)
- ejcx 10y agoNot just CDN, there's benefits to rolling out SRI for lots of your third parties. Your stripe js, scary ad networks js, front-end analytics companies. SRI is really neat and helps protect yourself from these many 3rd parties being pwned.
- untog 10y agoExcept that when the third party changes that script you'll stop loading it. Unless they adopt strict versioning in their files you'll have to be careful.
- bpicolo 10y agoAnd they won't, because (reasonable so) being update-able is half the point of the way they're doing it.
- hdhzy 10y agoSRI may be a double edged sword. What if stripe fixes a bug and rolls a new version of their JS? Your page stops accepting payments. That's bad. If jQuery is compromised you'll detect it and download from different location but for stripe there is no fallback.
- cryptarch 10y agoWell, if Stripe wants you to stop accepting payments, you will. They already can take the resource offline, I don't see how this is a new/additional problem. If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag.
- LukeShu 10y agoYou, as the web developer, want to start using subresource-integrity. Stripe, as a depended-upon 3rd party, has not yet bought in to subresource-integrity hype-train. Stripe rolls out a fix for a security issue or other bug in their JS. This breaks your subresource-integrity check. The didn't want you to stop accepting payments, they wanted to fix a vuln. That hampers the usefulness of using subresource-integrity on 3rd-party resources today (which is what yeldarb suggested). Perhaps in the future the 3rd party would provide a script that emits the URL/SRI, but that isn't today.
- jffry 10y agothe 3rd party would provide a script that emits the URL/SRI And we're back to square one - we can't trust _that_ script to not get pwned
- cryptarch 10y agoNot really, isn't packaging and securely distributing PHP/Node.js libraries a solved problem?
- johncolanduoni 10y agoIf you're not updating the PHP/Node.js library, and you're not updating any data you give it, where does it get the information it needs to update the URL/SRI tag? And if you are doing any of those things when Stripe pushes an update, how is it any different that having to update the URL/SRI tag?
- cryptarch 10y agoOk, so how about caching the Stripe script and serving it yourself, then polling for new versions and then updating the cache and the SRI? You might break payment for $polling_interval if the script is incompatible with Stripe's server, so perhaps you could have retry logic there, to bridge $polling_interval more smoothly. You could also manually review the new Stripe code this way, by polling only by hand or by not automatically updating the cache and SRI.
- MichaelBurge 10y agoI thought those 3rd-party links are just to make it easier to get started. I've been checking Javascript files into my project repository, since it seemed unwise to add N different points of failure for no reason. And anything important like your financial provider is usually very risk-averse to breaking changes, and should give plenty of notice for an update. And if you're including a hash, you don't care about automatic updates anyways. I can understand trusting one CDN for performance reasons. But do people really add so many different dependencies on their sites? Should I be doing that instead?
- hdhzy 10y agoI don't think so. Especially with HTTP 2 fetching resources from the same domain will be very fast. I guess the main audience of CDNs are huge sites that will see immediate benefits. For them SRI is good. But using CDN from day 1 seems to me like a premature optimization. SRI solves some problems (CDN compromise) in exchange for different set of problems (resource not loaded, what now?). And old saying comes to mind... "I had a problem and decided to use regular expressions... Now I have two problems".
- vog 10y agoThe title should have a "(2015)" suffix.
- throwaway2048 10y agoDate tags are only relevant when the information they contain is of a time sensitive nature. This article would say exactly the same thing if it was written today.
- elgenie 10y agoSomeone who reads the title and thinks "Hmm, this new article sounds like that Mozilla security engineer's article from a few years ago" would still appreciate the date tag.
- sctb 10y agoThanks! We've updated the title.
- Klathmon 10y agoIf you use webpack, just drop in webpack-subresource-integrity [0] for basically "free" SRI tags on all scripts. It's not really as useful if you are serving your static assets from the same place as the HTML (and you always use HTTPS) but if you load your js/css on another server SRI can still provide some protection. [0] https://github.com/waysact/webpack-subresource-integrity https://github.com/waysact/webpack-subresource-integrity
- CraftThatBlock 10y agoAnd IIRC, it's built-in to creat-react-app.
- julian37 10y agoIt used to be, briefly, unfortunately it had to be removed again because create-react-app has a zero-configuration policy and SRI can break pages served without TLS unless Cache-Control: no-transform is set on the server [1]. [1] https://github.com/waysact/webpack-subresource-integrity#proxies https://github.com/waysact/webpack-subresource-integrity#pro...
- yeldarb 10y agoIt'd be cool if the browser used this to allow cross-origin caching as well. Say I have jQuery previously loaded a page that included jQuery from CDNJS and now I'm in China and another site tries to load jQuery from Google's CDN. Currently that request would get blocked by the great firewall. But since the browser should know that this file matches one it has seen (and cached) before it should be able to just serve the cached file. This could also save a network request even if I'm linking to a self-hosted file on my own servers if I include the hash.
- renesd 10y agoYeah, that would be cool. They could also even potentially save JIT typing, specialization, and even parsing. This is a big deal on mobile. There is Cache-Control: immutable https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to... https://bitsup.blogspot.de/2016/05/cache-control-immutable.html https://bitsup.blogspot.de/2016/05/cache-control-immutable.h...
- tetrep 10y ago> It'd be cool if the browser used this to allow cross-origin caching as well. As a caveat, there's info leaking here depending on whether the cache hits/misses, so this would need to be opt-in from the cache source, e.g. You set up subresource integrity and also say "allow other domains to load this resource from the cache." Call it subresource sharing? Edit: opt-in would need to be on both "sides" (sharer and sharee).
- throwaway2048 10y agoThis still wouldnt be enough, because you could still target the unique mix of script/script versions some specific site has, and have a high chance of being accurate, or at least high enough for statistical purposes.
- problems 10y agoGiven the accumulation of scripts from many sites it might work out alright, those specific versions could come from anywhere - not like only 1 site around uses a specific version of jquery or something. It might be enough, but would need testing to prove it out either way.
- AdamN 10y ago"The security properties of a collision resistant hash function, ensure that a modification results in a very different hash." I really appreciate the clarity of this post. The author is building up the groundwork without skipping steps that may be obvious to many readers. I of course knew the purpose of a hash before reading the article, but some people don't - and that sentence clearly let those users know why the hash matters without making it less readable for knowledgeable readers. Writing clarity matters.
- default-kramer 10y agoHonestly, I thought this line wasn't very clear, at least if I understand it correctly. It is not important that modification produces a "very" different hash, even a minimally different hash is still different enough. What is important is that it is computationally infeasible to generate a collision. So if your evil plan is to modify someone's .js file and then play with comments/whitespace until the hashes match, you and the website will both be dead before you find the collision.
- braveo 10y agono, it be "very different" means you can't do things like generate a hash of all dictionary entries and identify when someone has a password that's only a slight change from a known dictionary entry. It's absolutely important in the security of hashes.
- noway421 10y agoAvalanche effect is a sign of a good hashing algorithms, but not necessarily all of them. It is very vital in case of SRI indeed, as because SRI also intended to shield from potential MITM somewhere in CDN stack. But SRI is useful in other areas too. For example for really bare version handling and for handling (somewhat) gracefully corrupted cdn responses (including errors, empty responses etc). For that, avalanche effect is not all that necessary and CRC32 could do an ok job too.
- bartl 10y ago
- theandrewbailey 10y agoSee also Content-Security-Policy require-sri-for https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
- dane-pgp 10y agoBy combining this with an extended form of SRI that supports hashes signed by a private key, it would be possible to bring the security model of web apps almost up to the level of desktop apps. You might still have to Trust On First Use whatever key/identity was signing a given version of a web app (at least the client-side component of it) but a browser could ask you "Do you want to update to version X.Y of this web app?" before running any JavaScript that you might want to check the release notes or reviews for first. Ideally this would be combined with something like Binary Transparency, where the new version has to have appeared in a public log for some time, and with no trusted third parties publishing a "Do not trust version X.Y" warning in another public log, acting as a sort of distributed immune system for the web.
- tofflos 10y agoPrevious discussion: https://news.ycombinator.com/item?id=10310594 https://news.ycombinator.com/item?id=10310594
- recursive 10y ago"An important side note is that for Subresource Integrity to work, the CDN must support Cross-Origin Resource Sharing (CORS)." This doesn't make sense to me. Why shouldn't I be able to perform integrity checking on resources from non-CORS domains?
- yjftsjthsd-h 10y agoInformation leakage? Just guessing
- epriest 10y agoAttackers could otherwise verify that resources on private networks or retrievable only with the victim's cookies have certain content. See, e.g., <https://github.com/w3c/webappsec/issues/418> https://github.com/w3c/webappsec/issues/418> for some broader discussion.
- LethargicStud 10y agoThanks for the link, but the closing '>' should not be part of it.
- bzbarsky 10y agoThat's a bug in ycombinator's linkification code. A quite frustrating one, since <> is _the_ standard way to delimit URLs in plaintext (going back to earlier than section 2.2 of RFC 1738, back in 1994!), so having linkifiers that still fail to respect it is really unfortunate.
- zitterbewegung 10y agoI wonder if it would be a good idea that if the SRI detected a modified javascript file that a warning should be presented to a web user when this occurs?
- icebraining 10y agoWhat would the user do with that information?
- arghwhat 10y agoThis only helps for JavaScript (and soon CSS) resources. If your HTML goes through a CDN (say, you use the full Cloudflare package), the CDN can of course just remove or modify these integrity attributes, or add new scripts altogether.
- homakov 10y agoSRI shouldn't use static hashes, it should set pub keys of different people and the response must have N/M signatures. This way updates are possible and you know N people confirmed the source as safe.
- nwmcsween 10y agoIt would be infinitely better if I could use a small hash instead of the giant sha variants, imagine 40 or so resources x sha-x length.
- dlss 10y agoThere's no point in using a hashing algorithm that can be maliciously collided.
- nighthawk454 10y agoLooks like it has good support in Firefox and Chrome, but none in IE/Safari. http://caniuse.com/#feat=subresource-integrity http://caniuse.com/#feat=subresource-integrity
- depr 10y agoAnd get all your resources requested twice on Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=677022 https://bugs.chromium.org/p/chromium/issues/detail?id=677022
- labster 10y agoWell, that sounds twice as secure!
- forgotpwtomain 10y agoThis might have been mentioned somewhere else but - will browsers remove or make an exception instead of blocking mixed-content[0] when a sub-resource integrity check is present? I mean there really is no reason to be paying the TLS over-head for commonly used libraries. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_...
- Klathmon 10y agoIntegrity is only 1/3 of the major benefits of TLS. The other 2 (privacy and authentication) are very important as well and for many are the main reason TLS is wanted.
- forgotpwtomain 10y agoDo you care about privacy and authentication when downloading react.js from a CDN?
- Klathmon 10y agoYou might not, but some may. Others still may care about keeping their ISP or the public WiFi they are on from seeing they are downloading some scripts from CDNs. Things like that are great for fingerprinting (only 2 sites happen to use these 6 scripts with these specific versions, so if someone downloads those they are on one of those sites). Plus it still leaks tons of data in the headers. Request time, cache length, useragent, cookies (maybe, hopefully not), accept-* headers, if modified since leaking the last download time, and possibly a lot more.
- Narkov 10y agoWhat about confidentiality? The integrity portion of TLS may become redundant but the confidentiality portion could still be required. If you are just loading jQuery you might not care.
- awqrre 10y agoor even better, avoid CDNs? it might even be cheaper when you account for the extra work... and faster when you don't have to load data from 10 servers to load just 1 web page
- sedatk 10y agofyi, Edge and Safari has yet to support this feature.
- gszathmari 10y agoThis tool lets you quickly assess whether third-party assets are protected by SRI: https://sritest.io/ https://sritest.io/ Disclaimer: I am the developer of sritest