3 ms·

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 rea

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.

l33tman 5y ago
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.. :/
meowface 5y ago
>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.
- Arnavion 5y ago
  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?
  - robin_reala 5y ago
    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.
  - meowface 5y ago
    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.
hsbauauvhabzb 5y ago
An update.
- robin_reala 5y ago
  You wouldn’t use an SRI integrity attribute on a non-versioned resource from a CDN.
  - hsbauauvhabzb 5y ago
    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
    - bugmen0t 5y ago
      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/issues/102 https://github.com/w3c/webappsec-subresource-integrity/issue...
fulafel 5y ago
> 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.

l33tman 5y ago

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.. :/

meowface 5y ago

>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.

Arnavion 5y ago
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?
- robin_reala 5y ago
  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.
- meowface 5y ago
  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.

hsbauauvhabzb 5y ago

An update.

robin_reala 5y ago
You wouldn’t use an SRI integrity attribute on a non-versioned resource from a CDN.
- hsbauauvhabzb 5y ago
  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
  - bugmen0t 5y ago
    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/issues/102 https://github.com/w3c/webappsec-subresource-integrity/issue...

fulafel 5y ago

> 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.