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

561–570 of 894 posts

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

#561

Post by friendzis »

sverhagen wrote: post #375
wongarsu wrote: post #319

Earlier quoted context omitted.

Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes. I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler

I came here to argue the opposite. Expressing it in seconds takes away questions about time zones and DST. I think you're incorrect to say that second are also ambiguous. Maybe what you mean is that days are more practical, but that seems very much a personal preference.

I understand the [flawed] reasoning behind "x seconds from now is going to be roughly now() + x on this particular system", but how does defining the cooldown from an external timestamp save you from dealing with DST and other time shenanigans? In the end you are comparing two timestamps and that comparison is erroneous without considering time shenanigans

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

#562

Post by reactordev »

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…

But you said so yourself they are necessary… otherwise you would just use fetch. This reasoning is going around in circles.

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

#563

Post by staticassertion »

philipwhiuk wrote: post #557
staticassertion wrote: post #387

Earlier quoted context omitted.

They're not a failed experiment. No one has ever "experimented" by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far: 1. Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment. 2. Publishers to official registries should…

> Publishers to official registries should be forced to use 2FA. I proposed this a decade ago for crates.io and people lost their minds, like I was suggesting we drag developers to a shed to be shot. How is this enforced when it's pushed via a pipeline?

Your account is separate from your publishing. That is, in order to go to my account to change configuration values, 2FA must be required.

Publishing should be handled via something like Trusted Publishing, which would leverage short lived tokens and can integrate with cryptographic logs for publish information (ie: "Published from the main branch of this repo at this time").

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

#566

Post by reactordev »

mhio wrote: post #55
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 } })

What does an interceptor in the RequestInit look like?

A wrapper function around fetch… that’s what interceptors are…

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

#567

Post by matltc »

ecshafer wrote: post #477
friendzis wrote: post #189

Earlier quoted context omitted.

Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call. (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

When I worked in Finance our internal Date extension did actually have Workdays that took into account Stock Market and Bank Holidays.

I tried to write this function in Power Query (Excel hell). Gave up after an hour or so.

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

#568

Post by staticassertion »

otterley wrote: post #517
staticassertion wrote: post #497

Earlier quoted context omitted.

Attackers going "low and slow" when they know they're being monitored is just standard practice. > Why do you believe that motivated threat hunters won’t continue to analyze and find threats in new versions of open source software in the first week after release? I'm sure they will, but attackers will adapt. And I'm really unconvinced that these delays are really going to help in the real world. Imagine you rely on `…

What, in your view, is a better solution?

There are many options. Here's a post just briefly listing a few of the ones that would be handled by package managers and registries, but there are also many things that would be best done in CI pipelines as well.

https://news.ycombinator.com/item?id=47586241

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

#569

Post by cozzyd »

bob1029 wrote: post #241

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

or you don't use a package manager where anyone can just publish a package (i.e. use your system package manager). There is still some risk, but it is much smaller. Like, if xz were distributed by PyPI or NPM, everyone would have been pwned, but instead it was (barely) found.

It's true that system repos doesn't include everything, but you can create your own repositories if you really need to for a few things. In practice Fedora/EPEL are basically sufficient for my needs. Right now I'm deploying something with yocto, which is a bit more limited in slection, but it's pretty easy to add my own packages and it at least has hashes so things don't get replaced without me noticing (to be fair, I don't know if the security practices of open-embedded recipes are as strong as Fedora...).

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

#570

Post by nailer »

augusto-moura wrote: post #476
cyco130 wrote: post #459

Earlier quoted context omitted.

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Hm, I don't think axios would do much better here. `fetch` is the official replacement for axios. If both are flawed that's another topic

> `fetch` is the official replacement for axios.

No. Axios is still maintained. They have not deprecated the project in favor of fetch.

Post reply on HN