It seems like Cloudflare predicted this back in Feb.
https://blog.cloudflare.com/polyfill-io-now-available-on-cdn...
Polyfill supply chain attack hits 100K+ sites
51–60 of 387 posts
Re: Polyfill supply chain attack hits 100K+ sites
#52> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…
I always prefer to self-host my dependencies, but as a developer who prefer to avoid an npm-based webpack/whatever build pipeline it's often WAY harder to do that than I'd like.
If you are the developer of an open source JavaScript library, please take the time to offer a downloadable version of it that works without needing to run an "npm install" and then fish the right pieces out of the node_modules folder.
jQuery still offer a single minified file that I can download and use. I wish other interesting libraries would do the same!
(I actually want to use ES Modules these days which makes things harder due to the way they load dependencies. I'm still trying to figure out the best way to use import maps to solve this.)
Re: Polyfill supply chain attack hits 100K+ sites
#53Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…
Real solution?
We’re in a complexity crisis and almost no one sees it.
It’s not just software dependencies of course. It’s everything almost everywhere.
No joke, the Amish have a point. They were just a few hundred years too early.
Re: Polyfill supply chain attack hits 100K+ sites
#54Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…
Alternatively, if you rely on some code then download a specific version and check it before using it. Report any problems found. This makes usage robust and supports open source support and development.
I guess that would work if new exploits weren’t created or discovered.
Otherwise all your plan to “run old software” is questionable.
Re: Polyfill supply chain attack hits 100K+ sites
#55> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…
I don't think SRI would have ever worked in this case because not only do they dynamically generate the polyfill based on URL parameters and user agent, but they were updating the polyfill implementations over time.
Re: Polyfill supply chain attack hits 100K+ sites
#56> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…
I always prefer to self-host my dependencies, but as a developer who prefer to avoid an npm-based webpack/whatever build pipeline it's often WAY harder to do that than I'd like. If you are the developer of an open source JavaScript library, please take the time to offer a downloadable version of it that works without needing to run an "npm install" and then fish the right pieces out of the node_modules folder. jQuery…
As you might know, Lit offers a single bundled file for the core library.
Re: Polyfill supply chain attack hits 100K+ sites
#57Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…
Alternatively, if you rely on some code then download a specific version and check it before using it. Report any problems found. This makes usage robust and supports open source support and development.
Vendoring should be the norm, not the special case.
Something like this ought to be an essential part of all package managers, and I'm thinking here that the first ones should be the thousands of devs cluelessly using NPM around the world:
Re: Polyfill supply chain attack hits 100K+ sites
#58Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…
It seems when proprietary resources get infected it's because hackers are the problem, but when open source resources get infected its a problem with open source.
But there isn't any particular reason why a paid/proprietary host couldn't just as easily end up being taken over / sold to a party intending to inject malware. It happens all the time really.
Re: Polyfill supply chain attack hits 100K+ sites
#59> this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io I've said it before, and I'll say it again: https://httptoolkit.com/blog/public-cdn-risks/ You can reduce issues like this using subresource intergrity (SRI) but there are still tradeoffs (around privacy & reliability - see article above) and there is a better solution: self-host your dependencies behind a CDN servic…
That was my thought too but polyfill.io does do a bit more than a traditional library CDN, their server dispatches a different file depending on the requesting user agent, so only the polyfills needed by that browser are delivered and newer ones don't need to download and parse a bunch of useless code. If you check the source code they deliver from a sufficiently modern browser then it doesn't contain any code at all (well, unless they decide to serve you the backdoored version...)
https://polyfill.io/v3/polyfill.min.js
OTOH doing it that way means you can't use subresource integrity, so you really have to trust whoever is running the CDN even more than usual. As mentioned in the OP, Cloudflare and Fastly both host their own mirrors of this service if you still need to care about old browsers.
Re: Polyfill supply chain attack hits 100K+ sites
#60It's amazing to me that anyone who tried to go to a website, then was redirected to an online sports betting site instead of the site they wanted to go to, would be like "hmm, better do some sports gambling instead, and hey this looks like just the website for me". This sort of thing must work on some percentage of people, but it's disappointing how much of a rube you'd have to be to fall for it.
It plants a seed. Could be a significant trigger for gambling addicts.