Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

Post reply on HN
Print view View original

111–120 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#111

Post by cromka »

pier25 wrote: post #87
vsgherzi wrote: post #63

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

If the fat std library is not viable you can only increase security requirements. Axios has like 100M downloads per week. A couple of people with MFA should have to approve changes before it gets published.

This is the actual answer: stupid cost saving creating an operational risk.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#112

Post by cromka »

friendzis wrote: post #104
wps wrote: post #50

Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in? It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.

[flagged]

What a weird way to virtue signal.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#113

Post by [deleted] »

vsgherzi wrote: post #63

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

[deleted]

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#114

Post by nananana9 »

Package managers are a failed experiment.

We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size.

The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majority of the attack surface. If you get rid of transitive dependencies, you get rid of the need of a package manager, as installing a package becomes unzipping a few files into a vendor/ folder.

There's so many C libraries like this. Off the top of my head, SQLite, FreeType, OpenSSL, libcurl, libpng/jpeg, stb everything, zlib, lua, SDL, GLFW... I do game development so I'm most familiar with the ones commonly used in game engines, but I'm sure other fields have similarly high quality C libraries.

They also bindings for every language under the sun. Rust libraries are very rarely used outside of Rust, and C#/Java/JS/Python libraries are never used outside their respective language (aside form Java ones in other JVM langs).

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#115

Post by wps »

friendzis wrote: post #104
wps wrote: post #50

Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in? It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.

[flagged]

Hello. You missed the point I was making drastically. Of course for software that I build personally I can do all that, but not for all the random stuff in my system that I’m trusting maintainers to package for me, or otherwise good PKGBUILDS in the AUR. You physically cannot have the bandwidth to be on top of these supply chain issues all the time.

Also, semantic versioning is not some golden goose that fixes this issue, update embargoes help, but that doesn’t require semver. Vendoring dependencies is not a scalable solution for all the software people use.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#117

Post by moi2388 »

nathanmills wrote: post #67
p1mrx wrote: post #25

Earlier quoted context omitted.

Stop trying to make Fetch happen.

No, I will not stop trying to create a more standardized and secure software ecosystem.

It’s a quote from the movie mean girls ;)

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#119

Post by shevy-java »

pjmlp wrote: post #110

The amount of people still using this instead of fetch. Nonetheless when wasn't axios, it would be something else. This is why corporations doing it right don't allow installing the Internet into dev machines. Yet everyone gets to throw their joke about PC virus, while having learnt nothing from it.

> The amount of people still using this instead of fetch.

People are lazy. And sometimes they find old stuff via a google search and use that.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#120

Post by anon7000 »

zdragnar wrote: post #97
reactordev wrote: post #21

Earlier quoted context omitted.

You can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })

There are pretty much two usage patterns that come up all the time: 1- automatically add bearer tokens to requests rather than manually specifying them every single time 2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page. There's no reason to repeat this logic in every single place you make an API call. Likewise, every respo…

Helper functions seem trivial and not like you’re reimplementing much.
Post reply on HN