Hacker News Reader

Comment by alexlur | Hacker News Reader

Great job on finding the vulnerability. Anyone who uses a CDN link should use the integrity attribute, which can be generated by https://www.srihash.org/.

View on HN

If you click the "copy script tag" icon on a library page (such as https://cdnjs.com/libraries/lodash.js), it will include the integrity attribute for you.

Reading for people not aware of it: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

What would likely happen if the SRI hash check triggered? The devs would have to be pretty savvy to suspect CloudFlare has actually been breached and refrain from just remaking the hash for the new updated content, in the middle of a production outage.

What other conclusion could you come to apart from a CDN breach? That’s the entire point of SRI.

What’s harder is persuading devs to architect systems with reasonable fallbacks in case CDN loading fails.

>What other conclusion could you come to apart from a CDN breach?

"Ah fuck, hundreds of users are suddenly calling/emailing/tweeting at us saying they can't load the site, and I see a bunch of errors in the console while testing from a fresh browser. Looks like it's only affecting browsers that don't currently have this CDN JS file in cache. The CDN must have broke something, but things seem to work okay when including the script with a standard script tag. I'll just remove this SRI attribute thing for now to stop the bleeding."

Or, if they have a bit more knowledge/do a bit more research:

"Looks they might have pushed a change that minifies the JS file slightly differently or something, or maybe the script got upgraded to patch some issue? And I guess the change probably broke the SRI thing? I don't know if the file is going to change again in the near future so I'll just remove this annoying thing for now until they provide some recommendations." (Or: "I'll just hash the current version of the file and change it to that, and prepare to change it again ASAP if the errors re-appear.")

Someone more experienced/knowledgeable would obviously not operate that way, but given how popular cdnjs is, seems fairly likely at least a few administrators would do something like that. Especially if they don't fully understand what the intitialism really means or what a hash is or how integrity is defined in this context and what the implications might be. Their instinct might just be to see something breaking the site for lots of users and to "fix the problem" as quickly and easily as possible.

Wouldn't it be better to switch to a self-hosted copy of the file and retain the SRI attribute ("reasonable fallbacks" as robin_reala said), until you get time to investigate it thoroughly?

To be specific, that should be the default :) By “reasonable fallbacks”, I meant more that your application should fail gracefully when modules / components fail to load. Escalators become stairs as their failure mode.

Yes, that would be the appropriate thing to do, for sure. The parent poster rhetorically asked about other responses people might have, so I was just giving a few examples of what a less experienced person might try.

I think the issue is that a lot of devs won't care, they are contractors and some project leader calls and says something is down, they see a failed hash, download it again and restart.. and the hash check in the first place was probably a copy/paste from a SO question..

I'm sorry for the cynicism but I'm pretty sure this is the reality for the bulk of internet companies out there.. :/

> What other conclusion could you come to apart from a CDN breach?

The majority of alerts from security systems and mechanisms are in the end false positives in that the reason is a misconfiguration or some pther non malicious reason. Sad but true.

An update.

You wouldn’t use an SRI integrity attribute on a non-versioned resource from a CDN.

I don’t recall ever seeing ‘don’t use SRI on non versioned resources’ - don’t get me wrong, it makes sense, but I’m a pentester and my clients know less than I do

True, that was somehow expected as obvious characteristics when writing this down. There is now an issue on the spec at https://github.com/w3c/webappsec-subresource-integrity/issue...

The reasonable approach is to listen for error events of such scripts and switch the `src` to a self-hosted fallback URL.

They should also consider whitelisting libraries individually in their CSP header (or meta tag if the header gets too long), instead of a blanket whitelist for an entire domain/subdomain or not having a CSP at all...

Reply on news.ycombinator.com