> Out of curiosity, could this have been a vector for a supply chain attack?
If you were using the CDN without SRIs, then yes, that would have been the most obvious channel. However, I don't believe the attacker ever set up for that and the URLs never resolved due to CloudFlare blocking it.
> there's been some pretty huge breaking changes
Unless you were using the legacy API, there shouldn't be any major impediment [1]. I intentionally tried to keep backwards compatibility as I hate doing library upgrades myself! Drop me an email - allan at the domain in question if you have any questions about doing an upgrade.
> It looks like newer versions of datatables don't import static files from the datatables CDN like this.
I rewrote aspects to use CSS styled elements in place of images, so there were less resources to load.
> Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
Per the above, if you were using the CDN without SRI for the resources, then any version could have been susceptible. However, I've seen no evidence that the attack took that vector.
I thought I was not using the CDN as I had self-hosted the static sources, but some image sources seemed to be imported from the CDN in stylesheets in the version of data tables I linked.
I just updated my application from v1.11 to v1.13 without any trouble (aside from some minor aesthetic changes to padding), so at the very least I now benefit from your styled elements.
Thanks for your dedication on this package, I’ve used it for years and it works very well.
I seem to recall enjoying using datatables. You, or somebody else associated helped me on the forums. Not sure what I asked but I remember two things: positive dev interaction, and the pain of figuring out how to make the OOX/Excel export not lose proceeding zeros. (Had to write my own handler to change the xml)
Yeah - it was a well set up attack. What I don't understand is that there was no obvious follow on. I can only guess that it was a proof that it could be done. Maybe?
Regarding the 1000 error - I didn't have any 1:1 support contact with CloudFlare - the first I knew was they were returning 1000 errors, which I presume they were doing due to a blacklisted IP being used for the DNS resolving. I'm really not sure though.
Yeah, I really wasn't happy about that. I did put it to the registrar that such a policy is wrong and open to such an attack. I got the impression that they weren't going to change their policy though. Such policies are something I'm going to be looking at when considering a new registrar.
Didn't expect to see this here, it was over a month ago this incident happened! Happy to answer any questions about it (author of DataTables here). It was a super stressful event to say the least, and I've been reading along with the recent npm incidents wondering what I can do to make sure my OpSec is as good as it reasonably can be.
Totally OT, but thanks so much for DataTables! I used it for a tiny personal project a few years back and it's been quietly chugging away with barely any maintenance required. It was so easy to get up and running with the documentation, implement and customise to my heart's content -- truly an excellent piece of open source!
Oh, hey! I discovered your library around a month ago, and had a question at the time [0]: why is it mostly sponsored [1] by personal injury lawyers? Are they particularly heavy DataTables users? Or is this an SEO thing for them, since the top sponsorship package comes with a site link?
The blog feed is here: https://datatables.net/feeds/blog.xml . It is advertised on the landing page, but it looks like I've missed having it on the blog page! As you say, that has the releases feed - thanks for pointing that out.
It would be helpful if you would share the name of the registrar so that other people could be aware that this policy exists if you work with that registrar.
Joker.com. Credit to them they fixed it reasonably quickly, but its a horrible policy to default to enact the change if no response if given. Their reasoning was what else would they do if someone got locked out of their email - they need a way to recover their domain somehow, and they ask for ID to be submitted, but as seen, that is trivial to fake.
The only real solution is to tie the accounts to the digital identity of a person/company and enforce strong authentication for these cases. Not sure if there's already some EU level solution to this. This is of course pretty complicated to implement, but it would be a valuable extra service for customers.
Hell Allan, apologies for going fanboy on you but just wanted to tell you that DataTables is amazing and we use it a lot in my circle of friends. You made an awesome product!
Just looked up their stuff again (it's been a while) and they appear to be out of business, although the website is still running. Don't order from them, based on Reddit reviews... Real shame, I loved the Psion keyboard.
The flip side is, if you don't do auto updates and an exploit is published and used against you and you haven't yet tested / pushed the patch, that you would have been protected against if it had auto updated, you are up the creak without a paddle in that situation as well.
To some degree you have to trust the software you are using not to mess things up.
So since I do mission critical healthcare I do run into this concept. But it's not as unresolvable as you portray. Consider for example HIPAA "break the glass" requirement. It says that whatever else you implement in terms of security you must implement a bypass that can be activated by routinely non-authorised staff to access health information if someone's life is in danger.
Similarly, when I questioned, "why can't users turn off ZScaler in an emergency" we were told that it wouldn't be compliant. But it's completely implementable at a technical level (Zscaler even supports this). You give users a code to use in an emergency and they can activate it and it will be logged and reviewed after use. But the org is too scared of compliance failure to let users do it.
Well, if the vault says you have COPD, and the devious bank robber is interested in your continued breathing, perhaps we can just review the footage after the fact.
This is one of those cases where you don't disable emergency systems to defend against rogue employees. If people abuse emergency procedures, you let the legal system sort it out.
> It says that whatever else you implement in terms of security you must implement a bypass that can be activated by routinely non-authorised staff to access health information if someone's life is in danger.
Huh.
I can see why this needs to exist, but hadn't thought of it before. Same deal as cryptography and law-enforcement backdoors.
> logged and reviewed after use
I was going to ask how this has protection from mis-use.
Seems good to me… but then I don't, not really, not deeply, not properly, feel medical privacy. To me, violation of that privacy is clearly rude, but how the bar raises from "rude" to "illegal" is a perceptual gap where, although I see the importance to others, I don't really feel it myself.
So it seems good enough to me, but am I right or is this an imagination failure on my part? Is that actually good enough?
I don't think cryptography in general can use that, unfortunately. A simple review process can be too slow for the damage in other cases.
