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

141–150 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#141

Post by josephg »

spankalee wrote: post #115
PaulHoule wrote: post #105

Earlier quoted context omitted.

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.

Yep. And so does unpkg. If you’re using JavaScript code through unpkg, you’re still using npm and your code is still bundled. You’re just getting someone else to do it, at a cost of introducing a 3rd party dependency.

I guess if your problem with npm and bundlers is you don’t want to run those programs, fine? I just don’t really understand what you gain from avoiding running bundlers on your local computer.

Re: Polyfill supply chain attack hits 100K+ sites

#142

Post by progmetaldev »

hinkley wrote: post #107
bawolff wrote: post #70

Earlier quoted context omitted.

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.

Definitely for browser extensions. It's become more difficult with needing to set up CORS, but like with most things that are difficult, you end up with developers that "open the floodgates" and allow as much as possible to get the job done without understanding the implications.

Re: Polyfill supply chain attack hits 100K+ sites

#143

Post by modeless »

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…

Another downside of SRI is that it defeats streaming. The browser can't verify the checksum until the whole resource is downloaded so you don't get progressive decoding of images or streaming parsing of JS or HTML.

Re: Polyfill supply chain attack hits 100K+ sites

#144

Post by EasyMark »

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.

You’d think they’d contract with some hacker group or government and use it as a vector to inject something more nefarious if money was their goal

Re: Polyfill supply chain attack hits 100K+ sites

#145

Post by PaulHoule »

matsemann wrote: post #87
toddmorey wrote: post #49

Earlier quoted context omitted.

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…

Years ago I had terrible DNS service from my ISP, enough to make my DSL sometimes underperform dialup. About 1 in 20 DNS lookups would hang for many seconds so it was inevitable that any web site that pulled content from multiple domains would hang up for a long time when loading. Minimizing DNS lookups was necessary to get decent performance for me back then.

Re: Polyfill supply chain attack hits 100K+ sites

#146

Post by nephanth »

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…

> I always prefer to self-host my dependencies

Js dependencies should be pretty small compared to images or other resources. Http pipelining should make it fast to load them from your server with the rest

The only advantage to using one of those cdn-hosted versions is that it might help with browser caching

Re: Polyfill supply chain attack hits 100K+ sites

#147

Post by PaulHoule »

advael wrote: post #137
program_whiz wrote: post #79

Earlier quoted context omitted.

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

Directly security-focused products like lastpass are the only things that have any market pressure whatsoever on this, and that's because they're niche products for which the security is the only value-add, marketed to explicitly security-conscious people and not insulated by a whole constellation of lock-in services. The relevant security threats for the overwhelming majority of people and organizations are breaches…

I wouldn’t point to LastPass as an exemplar…

https://www.theverge.com/2024/5/1/24146205/lastpass-independ...

Re: Polyfill supply chain attack hits 100K+ sites

#148

Post by josephg »

a2800276 wrote: post #123
bawolff wrote: post #93

Earlier quoted context omitted.

Does it even reduce latency that much (unless you have already squeezed latency out of everything else that you can)? Presumably your backend at this point is not ultra optimized. If you send a link header and using http/2 the browser will download the js file while your backend is doing its thing. I'm doubtful that moving js to the edge would help that much in such a situation unless the client is on the literal oth…

I'm so glad to find some sane voices here! I mean, sure, if you're really serving a lot of traffic to Mombasa, akamai will reduce latency. You could also try to avoid multi megabyte downloads for a simple page.

It’s not an either or thing. Do both. Good sites are small and download locally. The CDN will work better (and be cheaper to use!) if you slim down your assets as well.

Re: Polyfill supply chain attack hits 100K+ sites

#149

Post by ChrisMarshallNY »

I tend to avoid [other people's] dependencies like the plague. Not just for security, but also for performance and Quality. I think I have a grand total of two (2), in all my repos, and they are ones that I can reengineer, if I absolutely need to (and I have looked them over, and basically am OK with them, in their current contexts).

But I use a lot of dependencies; it's just that I've written most of them.

What has been annoying AF, is the inevitable sneer, when I mention that I like to avoid dependencies.

They usually mumble something like "Yeah, but DRY...", or "That's a SOLVED problem!" etc. I don't usually hang around to hear it.

Re: Polyfill supply chain attack hits 100K+ sites

#150

Post by hypeatei »

PaulHoule wrote: post #116
SV_BubbleTime wrote: post #102

Earlier quoted context omitted.

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…

Okay but your entire comment is riddled with mentions of complex systems (flight envelope system?) which proves the point of the parent comment. "Management" here is a group of humans who need to deal with all the complexity of corporate structures, government regulations, etc.. while also dealing with the complexities of the products themselves. We're all fallible beings.
Post reply on HN