4 ms·

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

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/ https://www.srihash.org/.

fulafel 5y ago
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.
- robin_reala 5y ago
  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.
- bugmen0t 5y ago
  The reasonable approach is to listen for error events of such scripts and switch the `src` to a self-hosted fallback URL.
terinjokes 5y ago
If you click the "copy script tag" icon on a library page (such as https://cdnjs.com/libraries/lodash.js https://cdnjs.com/libraries/lodash.js), it will include the integrity attribute for you.
Jach 5y ago
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...
SEJeff 5y ago
Reading for people not aware of it: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

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/ https://www.srihash.org/.

fulafel 5y ago

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.

robin_reala 5y ago
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.
bugmen0t 5y ago
The reasonable approach is to listen for error events of such scripts and switch the `src` to a self-hosted fallback URL.

terinjokes 5y ago

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

Jach 5y ago

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

SEJeff 5y ago

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