Live data from Hacker News

Polyfill supply chain attack hits 100K+ sites

sansec.io

261–270 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#261

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

Only if they have competition. Which long term is not the default state in the market.

> Which long term is not the default state in the market

Why not?

Re: Polyfill supply chain attack hits 100K+ sites

#262

Earlier quoted context omitted.

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.

Sounds like a bad idea to me. I would expect latency (network round trip time) to make this entire exercise worthless. Most polyfills are 1kb or less. Splitting polyfill code amongst a bunch of small subresources that are loaded from a 3rd party domain sounds like it would be a net loss to performance. Especially since your page won’t be interactive until those resources have downloaded. Your page will almost certain…

In practice when this wasn't a Chinese adware service, it proved to be faster to use the CDN.

You are not loading a "bunch" of polyfill script files, you selected what you needed in the URL via a query parameter, and the service took that plus user agent of the request to determine which were needed and returned a minified file of just the necessary polyfills.

As this request was to a separate domain it did not run into the head of line / max connections per domain issue of Http 1.1 which was still the more common protocol at the time this service came out.

Re: Polyfill supply chain attack hits 100K+ sites

#263
post #77

I’ll go ahead and make an assumption that the Chinese government was involved. Countries badly need to figure out a way to punish bad actors in cybersecurity realms. It seems that this type of attack, along with many others, are quickly ramping up. If there isn’t competent policy in this area, it could become very dangerous.

Why would the Chinese government use this to load a gambling website? I'm sure there are many better uses that would be more subtle that they could come up with this opportunity.

The problem is that they have a CDN that can serve up custom JS depending on the headers and IP of the visitor, which enables remarkably precise targeting. No reason why they couldn’t, for example, send a targeted payload to people in a specific geographic area (by IP) and/or a specific language (by Accept-Language header). The sports betting stuff could be diversion in that case.

Of course, I don’t personally believe this to be the case; Occam’s Razor says this is a straightforward case of someone deciding they want to start monetizing their acquisition.

Re: Polyfill supply chain attack hits 100K+ sites

#265
post #160

Sadly this is how the Web works. We need a much more decentralized alternative, that lets static files be served based on content hashes. For now browser extensions are the only way. It’s sad but the Web doesn’t protect clients from servers. Only servers from clients.

Before getting on your soapbox about the decentralised web, please look at what Polyfill actually did. I’m not sure what you’re actually suggesting, but the closest remotely viable thing (subresource integrity) already exists. It simply wouldn’t work in Polyfill’s case because Polyfill dynamically selected the ‘right’ code to send based on user agent. As usual this problem has nothing to do with centralisation v dece…

You seem to have a lot of hate for decentralized solutions. Even ones as simple as browsers providing an alternative to DNS and serving static files.

You don’t seem to care about protecting the user.

In a secure environment for the user why the f should the only option be to trust a server to choose which file to send based on the user-agent-reported ID?

The user-agent knows its own ID and can request the static file of its choice from the network. Vetted static Javascript running in the static website can do that.

You are so whipped by the Web’s inversion of power, that you can’t even seriously consider that alternative when writing your post.

You say it’s too hard for every person to vet static JS bundles and verify that they have no instructions to phone home or otherwise mess with you. Well, that’s why there are third party auditing companies, they can just sign and publicly post approvals of specific bundle hashes, that your browser can then check and make sure at least 2 reputable audits approved that version. Just like it does for chains of certificates when loading a site. In fact, you are currently sleepwalkinf into learned helplessness by AI models hosted by others, the same way.

At least the HN crowd drew the line at Web Environment Integrity by Google. It’s like you are an enthusiastic defender of mild slavery but oppose beating and killing the slaves.

Re: Polyfill supply chain attack hits 100K+ sites

#270
post #268

Clientside mitigation: install noscript. https://addons.mozilla.org/en-US/firefox/addon/noscript/ You can’t expect to remain secure on the modern web while running arbitrary javascript from anyone and everyone.

Nice: to be secure on the web, you just need to install an add-on which needs to:

Access browser tabs Store unlimited amount of client-side data Access browser activity during navigation Access your data for all websites

Post reply on HN