Some great tips in this thread and I've been collecting them all at https://github.com/bodadotsh/npm-security-best-practices
Axios compromised on NPM – Malicious versions drop remote access trojan
261–270 of 894 posts
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#262"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…
This is a rather superlative and tunnel vision, "everything is a nail because I'm a hammer" approach. The truth is this is an exceedingly difficult problem nobody has adequately solved yet.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#263NPM should learn from Linux distribution package managers.
Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these.
Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#264Not 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.
Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse. It's what we call in France "la fête du slip". PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLis…
Because fat std is rigid, impractical, and annoying.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#265"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…
Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#266NPM should learn from Linux distribution package managers. Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these. Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.
NPM is one big AUR, where anyone can submit arbitrary unverified code. The difference is that AUR is intentionally harder to use to prevent catastrophic one-line installs.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#267I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…
I like the idea of bubblewrap, but my pain point is that it is work to set it up correctly with bind mounts and forwarding necessary environment variables to make the program actually work usefully. Could you share your pip bwrap configuration? It sounds useful.
can't really share a file here, feel free to email me
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#268Earlier quoted context omitted.
What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.
Their analysis was triggered by open source projects upgrading en-masse and revealing a new anomalous endpoint, so, it does require some pioneers to take the arrows. They didn't spot the problem entirely via static analysis, although with hindsight they could have done (missing GitHub attestation).
A security company could set up a honeypot machine that installs new releases of everything automatically and have a separate machine scan its network traffic for suspicious outbound connections.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#269I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…
I think firejail is a much more flexible security sandbox than bwrap. It also comes with pre-defined profiles
bwrap is as secure as you want it to be which I think is the primary advantage over anything else.
Re: Axios compromised on NPM – Malicious versions drop remote access trojan
#270Earlier quoted context omitted.
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…
Interceptors are just wrappers in disguise. const myfetch = async (req, options) => { let options = options || {}; options.headers = options.headers || {}; options.headers['Authorization'] = token; let res = await fetch(new Request(req, options)); if (res.status == 401) { // do your thing throw new Error("oh no"); } return res; } Convenience is a thing, but it doesn't require a massive library.
That fetch requires so many users to rewrite the same code - that was already handled well by every existing node HTTP client- says something about the standards process.