Developers are pretty bad about this sort of thing. Back when this article was written, GitHub didn’t have its automatic scanning and you could just search “site:github.com intext:sk_live_” to find hundreds of Stripe live secret keys that would give you full access to someone’s hard earned cash.
Surprised this article doesn’t mention it but a scary amount of desktop apps use Electron nowadays which has considerably fewer protections than Chrome (and usually what protections it has are turned off by lazy devs). Since it runs at an OS level with very little safeguard there’s a lot of damage you could do, for example electron.shell can be turned into an easy RAT.
And every developer without access to a secret, will complain about how all this unnecessary bureaucracy is getting in the way and preventing them from shipping faster.
I love this article. It's funny and informative in a consice manner.
As a javascript dev with a security mindset the npm package repository and similar ones are kind of scary since it's very hard if not impossible to inspect every package for every update etc.
As soon as you run any framework or basically any bigger library at all you're in the hands of hundreds if not thousands of other people. It's like something big is just around the corner to happen and it can be used to make massive damage. If I were a state actor for example, I would use npm and similar tools to be able to shut down sites and systems on a massive scale at will if a war would break out or similar.
The thing is that if you would not use any libraries and similar it would be much harder to compete against the people and companies that do use all the libraries.
So what can you do? I guess the main thing is to use a language that has a massive standard library which you don't need so many external packages. That way, every change is at least audited and perhaps it's possible to audit all the external packages you need yourself?
I've asked myself the same a couple years ago, auditing yourself is impossible, it could be done by a third party but it'd be expensive if they do it for your particular use case.
Another possibility, still by third parties, but auditing udates to open source code for the public to use, they'd have to use certificates to sign updates, we'd need a secure version of NPM which only contains audited packages. There would exist good audits and bad ones so you'd have to choose depending on level of quality, and you'd have to pay them too somehow.
And there's a solution that would be a cheap way of finding the most obvious problems: AI-augmented audit, easy to automate, but could probably be fooled by some code changes.
I don't know why you are being silently downvoted, as I think it is worth talking about the potential of using static analysis to improve things.
One promising approach is Endo[0] which "uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies."
> who’s to say that what you see in /lib/package.min.js is the real result of minifying /src/package.js?
This is why NPM really needs to start demanding that packages (with more than N downloads per month) are reproducibly buildable from source.
Someone did actually produce a tool for performing these checks[0], specifically with the linked article in mind, but unfortunately the online service connected to the tool has been discontinued.
I've been building Packj [1] to address exactly these types of supply chain attacks. It can audit PyPI/NPM/Rubygems packages and flag hidden malware or "risky” code behavior such as spawning of shell, exfiltration of data, mismatching repo code vs packaged code (provenance).
The article mentions that CSP would be a complete defence against this attack, except that there's a "prefetch trick" that bypasses that defence in Chrome.
Coincidentally, last month the Chrome team decided to abandon[0] plans to implement the prefetch-src CSP directive, in favour of a "least-restrictive" directive[1].
The new approach is being tracked on Chrome's feature status website[2], which says: "This allows developer to use resource hints without needing to tweak their content security policy, while giving a tool to prevent exfiltration by having default-src block prefetches."
So, the solution is to keep all your NPM repos out of the page.
But the issue is not really solved, as your backend either has NPM [Node], Composer [PHP], PyPI [Python], etc. AFAIK all of these have worse sandboxing than the browser does.
(I recognize that the threat envelope is different.
Eg. a Stripe form never sends the credit card info to your back-end, so it may be better. On the other hand, the server can access the Stripe key, which is a crown jewel...)
There are some brilliant levels of sarcasm going on in this article. Sarcasm inside of sarcasm. An infinite recursion of sarcasm, an out-and-out brainfsck. All the while, with the question still lingering in your head, "This is all just hypothetical, right? RIGHT?"
NPM is a mess. And we haven't even discussed what's happening in all the other repositories like nuget, pypi, maven, docker hub, crates.io, gems, etc.
Not really related but, i signed up for work at a temp service once and i was asked to sit down at their laptops and enter my direct deposit details. i started clicking on the fields on by one and the edge browser they used pulled up a list of every single bank account and routing number along with the name address and SSN of every. single applicant that had applied there. if i where a bad person i could have easily taken a picture of each list with my phone and stolen probably 50 peoples identities.
I just read it as a cheeky way of not disclosing where it happened, try not to take everything so seriously. Do you turn of the TV when you read "any resemblance to actual persons or events are pure coincidence"?
Surprised this article doesn’t mention it but a scary amount of desktop apps use Electron nowadays which has considerably fewer protections than Chrome (and usually what protections it has are turned off by lazy devs). Since it runs at an OS level with very little safeguard there’s a lot of damage you could do, for example electron.shell can be turned into an easy RAT.