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

191–200 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#191

Post by akira2501 »

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.

Yes, but if you reduce your overall risk, your chances of actually receiving a payout increase immensely.

Re: Polyfill supply chain attack hits 100K+ sites

#192

Post by simonw »

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.

Before ESM I wasn't nearly as sold on skipping the build step, but now it feels like there's a much nicer browser native way of handling dependencies, if only I can get the files in the right shape!

The Rails community are leaning into this heavily now: https://github.com/rails/importmap-rails

Re: Polyfill supply chain attack hits 100K+ sites

#193

Post by akira2501 »

diego_sandoval wrote: post #158

The phrase "supply chain attack" makes it sound like it's some big, hard to avoid problem. But almost always, it's just developer negligence: 1. Developer allows some organization to inject arbitrary code in the developer's system 2. Organization injects malicious code 3. Developer acts all surprised and calls it an "attack" Maybe don't trust 3rd parties so much? There's technical means to avoid it. Calling this situ…

It's called a supply chain attack to displace the blame on the profitable organization that negligently uses this code onto the unpaid developers who lost control of it.

As if expecting lone OSS developers that you don't donate any money towards somehow being able to stand up against the attacks of nation states is a rational position to take.

Re: Polyfill supply chain attack hits 100K+ sites

#194

Post by simonw »

pityJuke wrote: post #10
can16358p wrote: post #8

Earlier quoted context omitted.

But if the dependency from a CDN is already cached, it will skip an extra resource and site will load faster. I agree with the points though.

That’s not been true since Site Isolation IIRC e: Not sure it’s Site Isolation specifically, but it’s definitely still not true anymore: https://news.ycombinator.com/item?id=24745748 e2: listen to the commenter below, its Cache Partitioning: https://developer.chrome.com/blog/http-cache-partitioning

Right - and site isolation is about five years old at this point. The idea that CDNs can share caches across different sites is quite out of date.

Re: Polyfill supply chain attack hits 100K+ sites

#195

Post by josephg »

progmetaldev wrote: post #184
josephg wrote: post #152

Earlier quoted context omitted.

I don’t think it ever even improved page load speeds, because it introduces another dns request, another tls handshake, and several network round trips just to what? Save a few kb on your js bundle size? That’s not a good deal! Just bundle small polyfills directly. At these sizes, network latency dominates download time for almost all users.

I believe you could download from multiple domains at the same time, before HTTP/2 became more common, so even with the latency you'd still be ahead while your other resources were downloading. Then it became more difficult when you had things like plugins that depended on order of download.

You can download from multiple domains at once. But think about the order here:

1. The initial page load happens, which requires a DNS request, TLS handshake and finally HTML is downloaded. The TCP connection is kept alive for subsequent requests.

2. The HTML references javascript files - some of these are local URLs (locally hosted / bundled JS) and some are from 3rd party domains, like polyfill.

3a. Local JS is requested by having the browser send subsequent HTTP requests over the existing HTTP connection

3b. Content loaded from 3rd party domains (like this polyfill code) needs a new TCP connection handshake, a TLS handshake, and then finally the polyfills can be loaded. This requires several new round-trips to a different IP address.

4. The page is finally interactive - but only after all JS has been downloaded.

Your browser can do steps 3a and 3b in parallel. But I think it'll almost always be faster to just bundle the polyfill code in your existing JS bundle. Internet connections have very high bandwidth these days, but latency hasn't gotten better. The additional time to download (lets say) 10kb of JS is trivial. The extra time to do a DNS lookup, a TCP then TLS handshake and then send an HTTP request and get the response can be significant.

And you won't even notice when developing locally, because so much of this stuff will be cached on your local machine while you're working. You have to look at the performance profile to understand where the page load time is spent. Most web devs seem much more interested in chasing some new, shiny tech than learning how performance profiling works and how to make good websites with "old" (well loved, battle tested) techniques.

Re: Polyfill supply chain attack hits 100K+ sites

#196

Post by [deleted] »

cqqxo4zV46cp wrote: post #180
ChrisMarshallNY wrote: post #149

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…

In most professional development contexts your puritan approach is simply unjustified. You’re obviously feeling very smug now, but that feeling is not justified. I note that you say “in all my repos”. What is the context in which these repositories exist? Are they your hobby projects and not of any real importance? Do you have literally anyone that can call you out for the wasted effort of reimplementing a web server…

[deleted]

Re: Polyfill supply chain attack hits 100K+ sites

#197

Post by bawolff »

smaudet wrote: post #100
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…

> Does it even reduce latency that much Absolutely: https://wondernetwork.com/pings/ Stockholm Tokyo is at least 400ms here, anytime you have multi-national sites having a CDN is important. For your local city, not so much (and of course you won't even see it locally).

I understand that ping times are different when geolocated. My point was that in fairly typical scenarios (worst cases are going to be worse) it would be hidden by backend latency since the fetch could be concurrent with link headers or http 103. Devil in details of course.

Re: Polyfill supply chain attack hits 100K+ sites

#198

Post by linclark »

yesimahuman wrote: post #32
baxtr wrote: post #7

Important context given by the author of polyfill: > If your website uses http://polyfill.io , remove it IMMEDIATELY. I created the polyfill service project but I have never owned the domain name and I have had no influence over its sale. (1) Although I wonder how the GitHub account ownership was transferred. (1) https://x.com/triblondon/status/1761852117579427975

Does this person telling us not to use polyfill.io, and the guy who sold polyfill.io to the chinese company both work at Fastly? If so, that's kind of awkward...

Neither of them had ownership of the project, so neither of them were responsible for the sale or benefited from it.

They both simply dedicated a lot of time, care and skill to the project. It's really a shame to see what they spent so much time building and maintaining now being used as a platform to exploit people. I'm sure its extremely disappointing to both of them.

Re: Polyfill supply chain attack hits 100K+ sites

#199

Post by bawolff »

jsheard wrote: post #134
a2800276 wrote: post #123

Earlier quoted context omitted.

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.

Content: 50KB Images: 1MB Javascript: 35MB Fonts: 200KB Someone who is good at the internet please help me budget this. My bounce rate is dying.

While there are lots of bad examples out there - keep in mind its not quite that straight forward as it can make a big difference whether those resources are on the critical path that blocks first paint or not.

Re: Polyfill supply chain attack hits 100K+ sites

#200

Post by laurent123456 »

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 can't find the reference now, but I think I read somewhere it only redirects when the user got there by clicking on an ad. In that case it would make a bit more sense - the script essentially swaps the intended ad target to that sport gambling website. Could work if the original target was a gaming or sport link.
Post reply on HN