Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Polyfill supply chain attack hits 100K+ sites

sansec.io

Post reply on HN
Print view View original

111–120 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#111

Post by silverwind »

simonw wrote: post #52
pimterry wrote: post #17

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

The assumption of many npm packages is that you have a bundler and I think rightly so because that leaves all options open regarding polyfilling, minification and actual bundling.

Re: Polyfill supply chain attack hits 100K+ sites

#112

Post by bornfreddy »

karaterobot wrote: post #22

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

This assumes that advertisers know how the traffic came to their site. The malware operators could be scamming the advertisers into paying for traffic with very low conversion rates.

Re: Polyfill supply chain attack hits 100K+ sites

#113

Post by bryanlarsen »

j1elo wrote: post #57
m0llusk wrote: post #48

Earlier quoted context omitted.

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: https://go.dev/ref/mod#vendoring

We've seen a lot more attacks succeed because somebody has vendored an old vulnerable library than supply chain attacks. Doing vendoring badly is worse than relying on upstream. Vendoring is part of the solution, but it isn't the solution by itself.

Re: Polyfill supply chain attack hits 100K+ sites

#114

Post by the8472 »

toddmorey wrote: post #49
irrational wrote: post #29

Earlier quoted context omitted.

> self-host your dependencies I can kind of understand why people went away from this, but this is how we did it for years/decades and it just worked. Yes, doing this does require more work for you, but that's just part of the job.

For performance reasons alone, you definitely want to host as much as possible on the same domain. In my experience from inside companies, we went from self-hosting with largely ssh access to complex deployment automation and CI/CD that made it hard to include any new resource in the build process. I get the temptation: resources linked from external domains / cdns gave the frontend teams quick access to the librarie…

Maybe people have been serving those megabytes of JS frameworks from some single-threaded python webserver (in dev/debug mode to boot) and wondered why they could only hit 30req/s or something like that.

Re: Polyfill supply chain attack hits 100K+ sites

#115

Post by spankalee »

PaulHoule wrote: post #105
spankalee wrote: post #90

Earlier quoted context omitted.

This is why I don't think it's very workable to avoid npm. It's the package manager of the ecosystem, and performs the job of downloading dependencies well. I personally never want to go back to the pre-package-manager days for any language.

One argument is that Javascript-in-the-browser has advanced a lot and there's less need for a build system. (ex. ESM module in the browser) I have some side projects that are mainly HTMX-based with some usage of libraries like D3.js and a small amount of hand-written Javascript. I don't feel that bad about using unpkg because I include signatures for my dependencies.

npm is a package manager though, not a build system. If you use a library that has a dependency on another library, npm downloads the right version for you.

Re: Polyfill supply chain attack hits 100K+ sites

#116

Post by PaulHoule »

SV_BubbleTime wrote: post #102
willcipriano wrote: post #65

Earlier quoted context omitted.

It's a competence crisis not a complexity one. https://www.palladiummag.com/2023/06/01/complex-systems-wont...

We haven’t gotten smarter or dumber. But we have exceeded our ability to communicate the ideas and concepts, let alone the instructions of how to build and manage things. Example: a junior Jiffy Lube high school dropout in 1960 could work hard and eventually own that store. Everything he would ever need to know about ICE engines was simple enough to understand over time… but now? There are 400 oil types, there are cl…

The problem w/ Boeing is not the inability of people to manage complexity but of management's refusal to manage complexity in a responsible way.

For instance, MCAS on the 737 is a half-baked implementation of the flight envelope protection facility on modern fly-by-wire airliners (all of them, except for the 737). The A320 had some growing pains with this, particularly it had at least two accidents where pilots tried to fly the plane into the ground, thought it would fail because of the flight envelope protection system, but they succeeded and crashed anyway. Barring that bit of perversity right out of the Normal Accidents book, people understand perfectly well how to build a safe fly-by-wire system. Boeing chose not to do that, and they refused to properly document what they did.

Boeing chose to not develop a 737 replacement, so all of us are suffering: in terms of noise, for instance, pilots are going deaf, passengers have their head spinning after a few hours in the plane, and people on the ground have no idea that the 737 is much louder than competitors.

Re: Polyfill supply chain attack hits 100K+ sites

#117

Post by jjulius »

bangaladore wrote: post #51

It seems like Cloudflare predicted this back in Feb. https://blog.cloudflare.com/polyfill-io-now-available-on-cdn...

CF links to the same discussion on GitHub that the OP does. Seems less like they predicted it, and more like they just thought that other folks concerns were valid and amplified the message.

Re: Polyfill supply chain attack hits 100K+ sites

#118

Post by krageon »

program_whiz wrote: post #79
causal wrote: post #58

Earlier quoted context omitted.

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.

agreed, but if a company is making millions for the security of software, the incentive is to keep it secure so customers stick with it. Remember the lastpass debacle, big leak and lost many customers...

Oh yeah, corporations are so accountable. We have tons of examples of this.

Re: Polyfill supply chain attack hits 100K+ sites

#119

Post by alephnerd »

ttyprintk wrote: post #89
alephnerd wrote: post #74

Earlier quoted context omitted.

> I always prefer to self-host my dependencies Ime this has always been standard practice for production code at all the companies I've worked at and with as a SWE or PM - store dependencies within your own internal Artifactory, have it checked by a vuln scanner, and then called and deployed. That said, I came out of the Enterprise SaaS and Infra space so maybe workflows are different in B2C, but I didn't a differenc…

Would an unwisely-configured site template or generator explain the scale here? Or, a malicious site template or generator purposefully sprinkling potential backdoors for later?

But wouldn't some sort of SCA/SAST/DAST catch that?

Like if I'm importing a site template, ideally I'd be verifying either it's source or it's source code as well.

(Not being facetious btw - genuinely curious)

Re: Polyfill supply chain attack hits 100K+ sites

#120

Post by hinkley »

toddmorey wrote: post #49
irrational wrote: post #29

Earlier quoted context omitted.

> self-host your dependencies I can kind of understand why people went away from this, but this is how we did it for years/decades and it just worked. Yes, doing this does require more work for you, but that's just part of the job.

For performance reasons alone, you definitely want to host as much as possible on the same domain. In my experience from inside companies, we went from self-hosting with largely ssh access to complex deployment automation and CI/CD that made it hard to include any new resource in the build process. I get the temptation: resources linked from external domains / cdns gave the frontend teams quick access to the librarie…

Using external tools can make it quite a lot harder to do differential analysis to triage the source of a bug.

The psychology of debugging is more important than most allow. Known unknowns introduce the possibility that an Other is responsible for our current predicament instead of one of the three people who touched the code since the problem happened (though I've also seen this when the number of people is exactly 1)

The judge and jury in your head will refuse to look at painful truths as long as there is reasonable doubt, and so being able to scapegoat a third party is a depressingly common gambit. People will attempt to put off paying the piper even if doing so means pissing off the piper in the process. That bill can come due multiple times.

Post reply on HN