Live data from Hacker News

Polyfill supply chain attack hits 100K+ sites

sansec.io

271–280 of 387 posts

Re: Polyfill supply chain attack hits 100K+ sites

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

If you're running uBlock Origin, you can also add it to your filters.

discussed here: https://news.ycombinator.com/item?id=40792322

I wonder if it would just better to edit your /etc/hosts file and add something like to this to it:

    127.0.0.1 polyfill.io 
    127.0.0.1 www.polyfill.io
    127.0.0.1 cdn.polyfill.io
     
I use both FF and Chrome, and I use multiple profiles on Chrome, so I have to go in an add the filter for each profile and browser. At least for my personal laptop where I can do this. Not sure about my work one.

edit: looks like uBlock is already blocking it: https://news.ycombinator.com/item?id=40796938

Re: Polyfill supply chain attack hits 100K+ sites

#274
I think JS (well, ES6) has a ton of positive qualities, and I think it's a great fit for many of its current applications. However, this is a pretty good example of what bothers me about the way many people use it. I see a lot of folks, in the name of pragmatism, adopt a ton of existing libraries and services so they don't have to think about more complex parts of the problem they're solving. Great! No need to reinvent the wheel. But, people also seem to falsely equate popularity with stability-- if there's a ton of people using it, SURELY someone has vetted it, and is keeping a close eye on it, no? Well, maybe no? It just seems that the bar for what people consider 'infrastructure' is simply too low. While I don't think that, alone, is SO different from other popular interpreted languages, the light weight of JS environments means you need to incorporate a LOT of that stuff to get functionality that might otherwise be part of a standard library or ubiquitous stalwart framework, which dramatically increases the exposure to events like this.

I think a lot of people conflate criticism of JS with criticism of the way it's been used for the past number of years, putting a nuanced topic into a black-and-white "for or against" sort of discussion. I've done a number of projects heavily using JS-- vanilla, with modern frameworks, server-side and in the browser-- and aside from some fundamental annoyances with it's approach to a few things, it's been a great tool. There's nothing fundamental about JS itself that makes applications vulnerable to this like a buffer overflow would, but the way it is used right now seems to make it a lot easier for inexperienced, under-resourced, or even just distracted developers to open up big holes using generally accepted techniques.

But I've never been a full-time front-end-web or node dev, so maybe I'm mistaken? Compared to the server-side stuff I've worked with, there's definitely a concerning wild west vibe moving into modern JS environments. I think there was a casual "well, it's all in client-side userspace" attitude about the way it was used before which effectively shifted most of the security concerns to the browser. We should probably push a little harder to shake that. Think about how much JS your bank uses in their website? I'll bet they didn't write all of their own interaction libraries.

Re: Polyfill supply chain attack hits 100K+ sites

#276

One of these days we're going to learn our lesson and just write our own damned code.

One has to admit the game of cat and mouse that the web browser brought about has been quite valuable for advancing security as a field, unfortunately this sort of thing seems like we have to get burned to learn the pan is hot and mother warning us is not enough.

Pay your security teams more, people.

Re: Polyfill supply chain attack hits 100K+ sites

#278
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

Unless you design your own silicon, build your own pc and peripherals, and write all your own software, there's always going to be a level of trust involved. But at least NoScript is FOSS so you can in theory examine the source code yourself.

https://github.com/hackademix

Re: Polyfill supply chain attack hits 100K+ sites

#279

> "If you own a website, loading a script implies an incredible relationship of trust with that third party," he Xeeted at the time. Are people actually calling Tweets "Xeets" now?

I propose "X-crete" as the new verb and "X-cretion" for the final product.

Re: Polyfill supply chain attack hits 100K+ sites

#280
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

I think there’s a toggle to just disable JavaScript entirely somewhere in the menus, but it is sort of inconvenient, because you can’t selectively enable sites that are too poorly coded to run without JavaScript.

Mozilla has marked NoScript as a recommended extension, which is supposed to mean they reviewed the code. Did they do it perfectly? I don’t know. But the same logic could be applied to the patches they receive for their browser itself, right? It’s all just code that we trust them to audit correctly.

Post reply on HN