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

101–110 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#101

Post by tracker1 »

baobabKoodaa wrote: post #86
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.

I'm genuinely puzzled that a group with the ability to hijack 100k+ websites can think of nothing more lucrative to do than this.

Even with low rates, my first thought would probably be crypto mining via wasm. I'd never do it, but would have been less noticeable.

Re: Polyfill supply chain attack hits 100K+ sites

#102

Post by SV_BubbleTime »

willcipriano wrote: post #65
SV_BubbleTime wrote: post #53

Earlier quoted context omitted.

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.

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 closed source computers on top computers, there are specialty tools for every vehicle brand, and you can’t do anything at all without knowing 10 different do-work-just-to-do-more-work systems. The high school dropout in 2024, will never own the store. Same kid. He hasn’t gotten dumber. The world just left him by in complexity.

Likewise… I suspect that Boeing hasn’t forgotten how to build planes, but the complexity has exceeded their ability. No human being on earth could be put in a room and make a 747 even over infinite time. It’s a product of far too many abstract concepts in a million different places that have come together to make a thing.

We make super complex things with zero effort put into communicating how or why they work a way they do.

We increase the complexity just to do it. And I feel we are hitting our limits.

Re: Polyfill supply chain attack hits 100K+ sites

#104

Post by pcthrowaway »

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…

This supply chain attack had nothing to do with npm afaict.

The dependency in question seems to be (or claim to be) a lazy loader that determines browser support for various capabilities and selectively pulls in just the necessary polyfills; in theory this should make the frontend assets leaner.

But the CDN used for the polyfills was injecting malicious code.

Re: Polyfill supply chain attack hits 100K+ sites

#105

Post by PaulHoule »

spankalee wrote: post #90
simonw wrote: post #82

Earlier quoted context omitted.

Yes! Love that about Lit. The problem is when I want to add other things that have their own dependency graph.

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.

Re: Polyfill supply chain attack hits 100K+ sites

#107

Post by hinkley »

bawolff wrote: post #70
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…

The shared CDN model might have made sense back when browsers used a shared cache, but they dont even do that anymore. Static files are cheap to serve. Unless your site is getting hundreds of millions of page views, just plop the js file on your webserver. With HTTP/2 it will probably be almost the same speed if not faster than a cdn in practise.

Aren't we also moving toward not even letting cross-origin scripts having very little access to information about the page? I read some stuff a couple years ago that gave me a very strong impression that running 3rd party scripts was quickly becoming an evolutionary dead end.

Re: Polyfill supply chain attack hits 100K+ sites

#108

Post by hinkley »

ryan29 wrote: post #61
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…

The same concept should be applied to container based build pipelines too. Instead of pulling dependencies from a CDN or a pull through cache, build them into a container and use that until you're ready to upgrade dependencies. It's harder, but creates a clear boundary for updating dependencies. It also makes builds faster and makes old builds more reproducible since building an old version of your code becomes as si…

I get the impression this is a goal of Nix, but I haven't quite digested how their stuff works yet.

Re: Polyfill supply chain attack hits 100K+ sites

#109

Post by apitman »

lifeisstillgood wrote: post #84
apitman wrote: post #34

Sigstore is doing a lot of interesting work in the code supply chain space. I have my fingers crossed that they find a way to replace the current application code signing racket along the way.

Sorry - I must have missed this - what’s the application code signing racket?

Shipping an app that runs on Windows without scary warnings required ~400USD/year code signing certificate, unless you release through the Microsoft Store.

Re: Polyfill supply chain attack hits 100K+ sites

#110

Post by swatcoder »

alephnerd wrote: post #74
simonw wrote: post #52

Earlier quoted context omitted.

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…

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

> I guess my question is why your employer or any other org would not follow the model above?

Frankly, it's because many real-world products are pieced together by some ragtag group of bright people who have been made responsible for things they don't really know all that much about.

The same thing that makes software engineering inviting to autodidacts and outsiders (no guild or license, pragmatic 'can you deliver' hiring) means that quite a lot of it isn't "engineered" at all. There are embarrassing gaps in practice everywhere you might look.

Post reply on HN