Harvesting credit card numbers and passwords from your site (2018)
david-gilbertson.medium.com
david-gilbertson.medium.com
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.
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?
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."
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.
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.
[0] https://medium.com/hackernoon/what-if-we-could-verify-npm-pa...
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."
[0] https://bugs.chromium.org/p/chromium/issues/detail?id=801561
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=140644...
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...)
What is the solution?
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.