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

81–90 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#81

Post by irskep »

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

I'm predisposed to agree with the diagnosis that incompetence is ruining a lot of things, but the article boils down to "diversity hiring is destroying society" and seems to attribute a lot of the decline to the Civil Rights Act of 1964. Just in case anybody's wondering what they would get from this article.

> By the 1960s, the systematic selection for competence came into direct conflict with the political imperatives of the civil rights movement. During the period from 1961 to 1972, a series of Supreme Court rulings, executive orders, and laws—most critically, the Civil Rights Act of 1964—put meritocracy and the new political imperative of protected-group diversity on a collision course. Administrative law judges have accepted statistically observable disparities in outcomes between groups as prima facie evidence of illegal discrimination. The result has been clear: any time meritocracy and diversity come into direct conflict, diversity must take priority.

TL;DR "the California PG&E wildfires and today's JavaScript vulnerability are all the fault of Woke Politics." Saved you a click.

Re: Polyfill supply chain attack hits 100K+ sites

#82

Post by simonw »

spankalee wrote: post #56
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…

As you might know, Lit offers a single bundled file for the core library.

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

Re: Polyfill supply chain attack hits 100K+ sites

#84

Post by lifeisstillgood »

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?

Re: Polyfill supply chain attack hits 100K+ sites

#85

Post by Cthulhu_ »

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.

If you have hundreds of millions of pageviews, go with a trusted party - someone you actually pay money to - like Cloudflare, Akamai, or any major hosting / cloud party. But not to increase cache hit rate (what CDNs were originally intended for), but to reduce latency and move resources to the edge.

Re: Polyfill supply chain attack hits 100K+ sites

#86

Post by baobabKoodaa »

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.

Re: Polyfill supply chain attack hits 100K+ sites

#87

Post by matsemann »

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…

> For performance reasons alone, you definitely want to host as much as possible on the same domain.

It used to be the opposite. Browsers limit the amount of concurrent requests to a domain. A way to circumvent that was to load your resources from a.example.com, b.example.com, c.example.com etc. Paying some time for extra dns resolves I guess, but could then load many more resources at the same time.

Not as relevant anymore, with http2 that allows sharing connections, and more common to bundle files.

Re: Polyfill supply chain attack hits 100K+ sites

#89

Post by ttyprintk »

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…

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?

Re: Polyfill supply chain attack hits 100K+ sites

#90

Post by spankalee »

simonw wrote: post #82
spankalee wrote: post #56

Earlier quoted context omitted.

As you might know, Lit offers a single bundled file for the core library.

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.

Post reply on HN