One Script Tag Just Pwn'd Over 100,000 Websites 

Exactly. Firefox was always praised for following the standards.

> Chrome was just doing what Firefox already started but with the leverage of better UX and more marketshare And more monopoly and more webp and less jpegxl

if I want to use a less popular js package, I have to make myself to read it or else I can't sit with the idea of deploying it. I can't imagine dropping a script tag into a project of mine without an integrity attribute... terrifying.

I thought the subresource integrity spec allows multiple hashes. In theory one could have enumerated all the user agents the cdn would see and hashed the expected polyfills

​@@KyleTen2enumerating all the user agents sounds hard. Easy to capture all the ones you have seen in the past but impossible to comprehensive coverage of the future.

@@KyleTen2 I thought this too, but looking through the MDN at a cursory glance, it's at the very least not common knowledge. It makes a ton of sense as an enhancement though. Dynamic content without the risk would be pretty awesome.

from the producers of "pretending to be a malware analysis environment"!

@@chriss3404 "pretending to be a VM", I actually saw that thing implemented somewhere, I don't remember where tho

Dunno if this was a joke, but uMatrix allows you to block ALL third party JS. Which in this day and age is something you should definitely be doing by default.

Million dollar idea

I wonder about it too.

This is a good question

It is and supply chain attacks to npm aren't new either. It's a shitshow.

I think this happened with npm already. They have protections against it.

@@secret8squirrel316 not nearly enought, protection on npm is like closing the door unlocked instead of letting it open completely

He didn't own it

​@@everythingponyyes he did, then he sold it

​@@Mitch-xo1rd So he didn't own it... when the bad things happened.

Your comment made it sound like you decided to show your boss a tweet/video from some tech RU-vidr instead of a more authoritative source like Cloudflare or the Polyfill maintainer(s)...

@@elhamnazifthis is a much better approach! although Theo is a good source of tech news, to convey the message to a “professional” use the damn direct original source lol

Yes, when you cite a tweet by a hipster-looking youtuber as the most convincing evidence of 100k wide attack, you look like an inexperienced impressionable fanboy. No hate to Theo, but to anyone who isn't familiar with him he's just a random influencer with no credibility. You should've cited Cloudflare.

15 years and he can't see the issue with polyfill?? Crazy, bro must've been sleeping for at least 10 of those years

As an Australian that uses banks, I’d love to know which bank your talking about

It's such a basic knowledge, I don't understand how anybody would even omit it. It's like using installing NPM modules, without specifying a static version. The next dev that's gonna touch it may unknowingly change the entire build' package or even introduce some nasty garbage simply because "npm install" went for the newest thing...

@@shapelessed It's not that they omited it, polyfill io by design could not be checksummed. It generates JS dynamically to polyfill based of the browsers UA-string and a given set of features you need. So the file was always different. The entire sales pitch is that, if the browser is up-to-date, you can skip downloading the polyfill. That's probably what made it a valuable attack target in the first place. But it's still a pretty bad idea regardless. You are trading that little JS overhead for complete trust in the provider of the script. Even with the cloudflare mirror that's not a good idea, and possibly a GDPR violation

People should vet their dependencies before adding them. Insted they just go NPM install

@@shapelessed regular dev with deadline pressure be like: insert external libs to get shit done go brrrr

exactly. they deleted the github issue where people were asking if they got bought by a chinese company, and some completely empty account closed it before the deletion happened and said "polyfill not managed by chinese company, by us based cdn company.".

exactly. they deleted the github issue that was asking whether they got bought out by a chinese company and some completely empty account closed the issue before the deletion saying, "please provide full url with version that is not working, we will clear it from cdn cache." then "polyfill not managed by chinese company, by us based cdn company."

Not a risk unless you actually have an account singed in on that website.

he's probably not using it, so he's not compromised.

It is fairly trivial to disable javascript, which can allow you to go to any site that is compromised without issue.

Plain js cant do much to your host os anyway, most it can do is spam you with alert();. The problem is because the js can just yoink whatever info you put on the website or redirect you to a phishing page, as long as you are just inspecting the website without entering info, though, its fine.

@@BattyBest Unless you are logged in, in which case it can also do extra fun stuff like potentially hijack your account, and do loads of things on the site on your behalf.

That looks like a batik. Originated from Indonesia

@@irumidesu9236 obligatory SEA/Nusantara heritage mention. Indonesia AND Malaysia (also Brunei and Singapore)

This one was Topman pre-acquisition, they’ve fallen apart since Used to love Express as well but they’re collapsing atm Will let people know when I find a good shirt source 🙃🙃

@@t3dotggyou should try Rhoback! i know you’re fashionable so would love to hear about your thoughts

Imagine if this happens with a UI library that uses external scripts, like Bootstrap, Semantic UI, etc.

Yeah, it always has been awful. And many seem to think it's okay. Yeah, for a little "lets just slap this in and try it out" sure, but the moment it's more than "hmm thats interesting" you need to be serving it yourself. It's more performant and safer. And easy.

@@bruwyvn bootstrap has almost always suggested to use an integrity attribute if you're just nabbing it via a script tag (and they link out to jsdelivr for it, not self-hosted). But yes, this is why you don't link to anything that doesn't have an integrity attribute to lock it down, and why pollyfil is difficult/impossible to secure; it changes delivery based on UA, so you can't give it a single integrity attribute.

if you use the integrity attribute on the script tag, you can guarantee that they can’t change it, so the worst case scenario is a DOS attack by just not serving the file

They could have updated the HTML for the page though lol That said, they are using Atlassian’s status page service so they would have to pressure them to fix it

@@t3dotgg agree that they could have manually fixed jt. Didn't dig deep into how they served it, just that it would be easy to miss the page that is handled differently from everything else. "Ok... We pushed a fix that mitigates the immediate threat, no longer a critical bug to address all of the pages individually." ... "Oh... Missed a spot"

what was the first one

@@skyjumper4097 I think he is refering to Agent 77 (Jia Tan). Where there is no proof as far as i know that agent 77 is chinese.

XZ Backdoor ​@@skyjumper4097

@@skyjumper4097attack on XZ was found few weeks ago. probably there are more that don't come to mind immediately

Your intuition is correct, this is very dumb to do

The reason they didn't pin it to a specific hash is the most dangerous thing about pollyfill, it changes based on user agent. Each user may be served a different js file, so you can't pin the script to a specific hash. They give full control of what may be PAYMENT PAGES to a script that randomly changes BY DESIGN!

Or using a strict Content Security Policy. The script could run and read whatever they want but nothing could be sent out.

@@OliverPlummer905 CSP is only used for loading resources like images and js though, not for outgoing connections.

@@OliverPlummer905 CSP isn't going to help, the script served from the URL is already "trusted" by the website, otherwise it wouldn't work in the first place. There's no way to specify CSP policy that says "if this resource's contents changes, then deny access to it".

​@@dealloc You can do it using the integrity attribute, it's generally a hash of the script, so any time the script changes and the hash doesn't, it fails to load the script. However in this case it's impossible to do because the script changes based on the user's browser so you can't know the hash in advance.

"Everything is bad so let's make no effort to fix it" nihilism is a cancer

wow, same (I think, not sure what site redirected me to a betting site)

I actually abandoned a person for running windows 98 in 2012

@@MattHudsonAtx Thank you for your service! o7

IE7 need isn't very common, but there are lots of corporate webapps. I had to support IE6 long after it was replaced. When you have 10 companies using your products, just having one of them refuse to upgrade is enough to require having to support them. Web apps are used for a lot more than public internet websites.

Not unique to npm, but yes that is a valid concern and is why a lot of companies, who care about security and have the resources, invest those resources in maintaining their own internal mirrors and vet any dependency being mirrored. This is unfortunately not so easy for majority of small companies to do, so they would have to trust a third-party anyway.

It's not like you can't check the code

@@juliansoto2651best of luck manually analysing 5k packages everytime you npm install

@@juliansoto2651 Oh yes ofcourse, let me just go through a couple million lines of code in the libraries in my dependency graph, and re-check at every update. Why didnt i think of that?

@@juliansoto2651 "It's not like you can't check the code" when you have like 100 dependencies, they will most probably have 1000 of unique dependencies itself, imagine putting a one liner backdoor in one of the backone packages, image like "is-odd" package, its simple, its everywhere. the thing the package does is simple, so adding one more line and jank code will most probably trigger some people, but if you manage to do it in a way that the code seems legit, you are good to go

Windows? I've always seen him using Mac

You cloud vlock it at DNS level

It would be weird for a react native app to use polyfills.

Rookie mistake, should've used C! /j

I don't think the script can do anything meaningful without a logged in account etc. Nothing to steal there.

yes

If you use Hulu, yes.

ublock origin already has it filtered out, you can try access polyfill dot io and you'll see

uBlock updated their filter list to include the polyfill domain as of June 26th. So likely not anymore. But it would seem prudent to change your passwords on sites that were affected.

No, the point of pollyfill is that it changes based on user agent, so each user may be served a different file depending on browser versions. You can't pin that to a specific hash, only hope you get served a safe js file.

Good point. The integrity doesn't work towards a stack. So if the original js file loads random js, that could be whatever. Kind of scary idea in the first place to use something like that.

Well that's how open source software works half of the time

Yes, users of sites that haven't patched it - the only way to check is disabling JS or going in incognito, View Source, and checking if the compromised URL is there