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

21–30 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

#21

Post by stusmall »

davidfischer wrote: post #15
stusmall wrote: post #6

I'm surprised there is no mention of subresource integrity in the article. It's a low effort, high quality mitigation for almost any JS packages hosted by a CDN. EDIT: Oh, it's because they are selling something. I don't know anything about their offerings, but SRI is made for this and is extremely effective.

SRI generally won't work here because the served polyfill JS (and therefore the SRI hash) depends on the user agent/headers sent by the user's browser. If the browser says it's ancient, the resulting polyfill will fill in a bunch of missing JS modules and be a lot of JS. If the browser identifies as modern, it should return nothing at all. Edit: In summary, SRI won't work with a dynamic polyfill which is part of the…

Oooft. I didn't realize it's one that dynamically changes it's content.

Re: Polyfill supply chain attack hits 100K+ sites

#22

Post by karaterobot »

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.

Re: Polyfill supply chain attack hits 100K+ sites

#23

Post by ok123456 »

fkyoureadthedoc wrote: post #16
mihaic wrote: post #9

I had this conversation countless times with developers: are you really ok if someone hijacks the CDN for the code you're including? They almost always seem to be fine with it, simply because everyone else is doing it like this. At the same time they put up with countless 2FAs in the most mundane places. The follow up of "you know that the random packages you're including could have malware" is even more hopeless.

yes you just put integrity="sha384-whatever" and you're good to go

Can't do that with this one because it generates the polyfill based on the user agent.

Re: Polyfill supply chain attack hits 100K+ sites

#26

Post by stusmall »

koolba wrote: post #20
davidfischer wrote: post #15

Earlier quoted context omitted.

SRI generally won't work here because the served polyfill JS (and therefore the SRI hash) depends on the user agent/headers sent by the user's browser. If the browser says it's ancient, the resulting polyfill will fill in a bunch of missing JS modules and be a lot of JS. If the browser identifies as modern, it should return nothing at all. Edit: In summary, SRI won't work with a dynamic polyfill which is part of the…

It absolutely would work if the browser validates the SRI hash. The whole point is to know in advance what you expect to receive from the remote site and verify the actual bytes against the known hash. It wouldn’t work for some ancient browser that doesn’t do SRI checks. But it’s no worse for that user than without it.

Their point is that the result changes depending on the request. It isn't a concern about the SRI hash not getting checked, it is that you can't realistically know the what you expect in advance.

Re: Polyfill supply chain attack hits 100K+ sites

#27

Post by reubenmorais »

koolba wrote: post #20
davidfischer wrote: post #15

Earlier quoted context omitted.

SRI generally won't work here because the served polyfill JS (and therefore the SRI hash) depends on the user agent/headers sent by the user's browser. If the browser says it's ancient, the resulting polyfill will fill in a bunch of missing JS modules and be a lot of JS. If the browser identifies as modern, it should return nothing at all. Edit: In summary, SRI won't work with a dynamic polyfill which is part of the…

It absolutely would work if the browser validates the SRI hash. The whole point is to know in advance what you expect to receive from the remote site and verify the actual bytes against the known hash. It wouldn’t work for some ancient browser that doesn’t do SRI checks. But it’s no worse for that user than without it.

The CDN in this case is performing an additional function which is incompatible with SRI: it is dynamically rendering a custom JS script based on the requesting User Agent, so the website authors aren't able to compute and store a hash ahead of time.

Re: Polyfill supply chain attack hits 100K+ sites

#28

Post by davidfischer »

koolba wrote: post #20
davidfischer wrote: post #15

Earlier quoted context omitted.

SRI generally won't work here because the served polyfill JS (and therefore the SRI hash) depends on the user agent/headers sent by the user's browser. If the browser says it's ancient, the resulting polyfill will fill in a bunch of missing JS modules and be a lot of JS. If the browser identifies as modern, it should return nothing at all. Edit: In summary, SRI won't work with a dynamic polyfill which is part of the…

It absolutely would work if the browser validates the SRI hash. The whole point is to know in advance what you expect to receive from the remote site and verify the actual bytes against the known hash. It wouldn’t work for some ancient browser that doesn’t do SRI checks. But it’s no worse for that user than without it.

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.

Re: Polyfill supply chain attack hits 100K+ sites

#29

Post by irrational »

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

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.

Post reply on HN