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

821–830 of 894 posts

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

#821

Post by arghwhat »

nailer wrote: post #549
arghwhat wrote: post #284

Earlier quoted context omitted.

It could also be trivially written for XMLHttpRequest or any node client if needed. Would be nice if they had always been the same, but oh well - having a server and client version isn't that bad. Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually than import a library and write interceptors for that ... (Not only because the integration with the library would…

> Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually Mine's about 100 LOC. There's a lot you can get wrong. Having a way to use a known working version and update that rather than adding a hundred potentially unnecessary lines of code is a good thing. https://github.com/mikemaccana/fetch-unfucked/blob/master/sr... > import a library and write interceptors for t…

Your wrapper does do a bunch of extra things that aren't necessary, but pulling in a library here is a far greater maintenance and security liability than writing those 100 lines of trivial code for the umpteenth time.

So yes you should just write and keep those lines. The fact that you haven't touched that file in 3 years is a great anecdotal indicator of how little maintenance such a wrapper requires, and so the primary reason for using a library is non-existent. Not like the fetch API changes in any notable way, nor does the needs of the app making API calls, and as long as the wrapper is slim it won't get in the way of an app changing its demands of fetch.

Now, if we were dealing with constantly changing lines, several hundred or even thousand lines, etc., then it would be a different story.

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

#822

Post by Andrex »

nananana9 wrote: post #114

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 majori…

Thought experiment: a language that enforces dependencies to be 2 levels deep or less.

I wonder if dependencies would flatten out with this limitation in mind.

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

#823

Post by la_fayette »

vovavili wrote: post #753
mrits wrote: post #695

Earlier quoted context omitted.

Python, .NET, and Java are not examples of batteries included. Django and Spring

Python's standard library is definitely much more batteries-included than JavaScript's.

depends, JavaScript in the Browser has many useful things available, which I miss with python, e.g., fetch, which in Python you need a separate package like requests to avoid a clunky API. Java had this issue for long time as well, since Java 11 there is the HttpClient with a convenient API.

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

#824

Post by staticassertion »

efilife wrote: post #817
staticassertion wrote: post #483

Earlier quoted context omitted.

Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).

https://docs.npmjs.com/configuring-two-factor-authentication > Important: Publishing to npm requires either: Two-factor authentication (2FA) enabled on your account, OR A granular access token with bypass 2FA enabled

I'm assuming the author must have been grandfathered in to TOTP?

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

#825

Post by staticassertion »

erikerikson wrote: post #665
moebrowne wrote: post #627

Earlier quoted context omitted.

TOTP isn't phishing resistant

No it's not but it's better than nothing. Don't let the perfect be the enemy of the good.

It's not much better than nothing. It basically solves "I reused my password across sites" exclusively, that's it. If you're going to go through the effort of TOTP, it seems odd that you wouldn't just use a unique password.

If you use a unique password it's questionable if it adds any value at all. Perhaps in very niche situations like "password authentication is itself vulnerable due to a timing attack/ bug" or some such thing... but we've rarely seen that in the wild.

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

#826

Post by hu3 »

Groxx wrote: post #801
lokar wrote: post #797

Earlier quoted context omitted.

Golang seems to do a good job of keeping the standard library up to date and clean

Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…

This looks like an ad for batteries included to me.

Libraries also don't get it right the first time so they increment minor and major versions.

Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON?

The benefits are worth it judging by how ubiquitous Go, Java and .NET are.

I'd rather leverage billions of support paid by the likes of Google, Oracle and Microsoft to build libraries for me than some random low bus factor person, prone to be hacked at anytime due to bad security practices.

Setting up a large JavaScript or Rust project is like giving 300 random people on the internet permission to execute code on my machine. Unless I audit every library update (spoiler: no one does it because it's expensive).

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

#827

Post by Yokohiii »

Groxx wrote: post #801
lokar wrote: post #797

Earlier quoted context omitted.

Golang seems to do a good job of keeping the standard library up to date and clean

Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…

Another downside of a large stdlib, is that it can be very confusing. Took my a while how unicode is supposed to work in go, as you have to track down throughout the APIs what are the right things to use. Which is even more annoying because the support is strictly binary and buried everywhere without being super explicit or discoverable.

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

#828

Post by Yokohiii »

mrits wrote: post #696
zymhan wrote: post #692

Earlier quoted context omitted.

> They are going to be out of date whenever a standard changes (HTML, etc.) You might want to elaborate on the "etc.", since HTML updates are glacial.

glaciers change faster than HTML

because there is more human effort

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

#829

Post by jvwww »

ptx wrote: post #337
_pdp_ wrote: post #307

I am not saying this is the reason for this compromise but the sudden explosion of coding assistant like claude code, and tools like openclaw is teaching entire crop of developers (and users) that it is ok to have sensitive credentials .env files.

Where would you suggest putting the sensitive credentials?

infisical is a great solution

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

#830

Post by erikerikson »

staticassertion wrote: post #825
erikerikson wrote: post #665

Earlier quoted context omitted.

No it's not but it's better than nothing. Don't let the perfect be the enemy of the good.

It's not much better than nothing. It basically solves "I reused my password across sites" exclusively, that's it. If you're going to go through the effort of TOTP, it seems odd that you wouldn't just use a unique password. If you use a unique password it's questionable if it adds any value at all. Perhaps in very niche situations like "password authentication is itself vulnerable due to a timing attack/ bug" or some…

I disagree.

I use a password manager and systemically use long random passwords. An attacker would need to compromise my password manager, phish me, wrench me, or compromise the site the credential is associated with to get that.

Using local only TOTP (no cloud storage or portability for me, by choice) they would have to additionally phish me, wrench me, compromise my phone, or compromise my physical security to get the code.

None of these are easy except the wrench which is high risk. My password manager had standard features which make me more phishing resistant, and together they are more challenging than either apart. For example the fact that my password manager will not fill in the password on a non associated site means I am much less likely to fill in a TOTP code on an inappropriate site. Though there are vulnerable scenarios they aren't statistically relevant in the wild and the bar is higher regardless.

Now I happen to have a FIDO key which I use for my higher security contexts but I'm a fairly low value target and npm isn't one of my high security contexts. TOTP improves my security stance generally and removing it from npmjs.org weakened my security stance there.

Post reply on HN