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

61–70 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#61

Post by ryan29 »

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 simple as using the builder image from that point in time.

Here's a nice example [1] using Java.

1. https://phauer.com/2019/no-fat-jar-in-docker-image/

Re: Polyfill supply chain attack hits 100K+ sites

#62

Post by rafram »

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

Seems like it. I hope the money was worth it.

Re: Polyfill supply chain attack hits 100K+ sites

#63

Post by adolph »

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 World Economic Forum website is affected here, for example! Absolutely ridiculous

Dammit Jim, we’re economists, not dream weavers!

Re: Polyfill supply chain attack hits 100K+ sites

#64

Post by toast0 »

can16358p wrote: post #8
jstanley wrote: post #3

Always host your dependencies yourself, it's easy to do & even in the absence of a supply chain attack it helps to protect your users' privacy.

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.

In addition to Cache Partitioning, it was never really likely that a user had visited another site that used the same specific versions from the same cdn as your site uses.

Making sure all of your pages were synchronized with the same versions and bundling into appropriate bits for sharing makes sense, and then you may as well serve it from your own domain. I think serving from your www server is fine now, but back in the day there were benefits to having a different hostname for static resources and maybe it still applies (I'm not as deep into web stuff anymore, thank goodness).

Re: Polyfill supply chain attack hits 100K+ sites

#65

Post by willcipriano »

SV_BubbleTime wrote: post #53
program_whiz wrote: post #14

Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…

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

Re: Polyfill supply chain attack hits 100K+ sites

#66

Post by svieira »

koolba wrote: post #38
davidfischer wrote: post #28

Earlier quoted context omitted.

I edited to make my comment more clear but polyfill.io sends dynamic polyfills based on what features the identified browser needs. Since it changes, the SRI hash would need to change so that part won't work.

Ah! I didn’t realize that. My new hot take is that sounds like a terrible idea and is effectively giving full control of the user’s browser to the polyfill site.

And this hot take happens to be completely correct (and is why many people didn't use it, in spite of others yelling that they were needlessly re-inventing the wheel).

Re: Polyfill supply chain attack hits 100K+ sites

#68

Post by chrisweekly »

program_whiz wrote: post #43
program_whiz wrote: post #14

Game theory at work? Someone needs to maintain legacy code for free that hosts thousands of sites and gets nothing but trouble (pride?) in return. Meanwhile the forces of the world present riches and power in return to turn to the dark side (or maybe just letting your domain lapse and doing something else). If security means every maintainer of every OSS package you use has to be scrupulous, tireless, and not screw u…

in a strange way, this almost makes the behavior of hopping onto every new framework rational. The older and less relevant the framework, the more the owner's starry-eyed enthusiasm wears off. The hope that bigcorp will pay $X million for the work starts to fade. The tedium of bug fixes and maintenance wears on, the game theory takes it's toll. The only rational choice for library users is to jump ship once the numbe…

Good point. What's often (and sometimes fairly) derided as "chasing the new shiny" has a lot of other benefits too: increased exposure to new (and at least sometimes demonstrably better) ways of doing things; ~inevitable refactoring along the way (otherwise much more likely neglected); use of generally faster, leaner, less dependency-bloated packages; and an increased real-world userbase for innovators. FWIW, my perspective is based on building and maintaining web-related software since 1998.

Re: Polyfill supply chain attack hits 100K+ sites

#69

Post by mmsc »

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…

>self-host your dependencies behind a CDN service you control (just bunny/cloudflare/akamai/whatever is fine and cheap).

This is not always possible, and some dependencies will even disallow it (think: third-party suppliers). Anyways, then that CDN service's BGP routes are hijacked. Then what? See "BGP Routes" on https://joshua.hu/how-I-backdoored-your-supply-chain

But in general, I agree: websites pointing to random js files on the internet with questionable domain independence and security is a minefield that is already exploding in some places.

Re: Polyfill supply chain attack hits 100K+ sites

#70

Post by bawolff »

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.

Post reply on HN