For those who haven’t seen this trending elsewhere, a popular npm library executed malicious code on victims’ computers. To summarize the thread (though it is worth a read) the maintainer of the library gave control to an unknown individual who claimed they wanted to maintain it. This individual added a dependency designed to execute some sort of malicious code, and people are still trying to figure out what the payload does. While a lot of people are playing the blame game, I’m interested in discussing what practical steps can be taken to limit this vector of attack. Should we establish a more rigorous process for giving up control of an npm module? Is our only hope better audit tools? I’m interested in any idea that addresses this security concern.
I feel like in the article when he talks about having any sensitive information going through a separate iFrame is a solid start. Within that little bit of JS code you can write all of it yourself as opposed to pulling in a bunch of npm modules. I feel like more steps need to be taken but it is at least a quick way to add a decent amount of security.
I don’t think we can put this on the shoulders of the maintainer. The most strict we get with package contribution the less open source we get :<
But as an application owner there are some things you can do, as tedious as it is-- I’m sure there are parsers out there to look for obvious vulnerabilities in your build output-- like looking for iFrames nick mentioned. Also looking for imports of request or implementations of network requests- hopefully there are not that many besides your main package you use to make network requests. You could look for imports of “http” as a big red flag. Also on the server using same domain or trusted domains for network requests. If some build safety parser doesn’t exist we should build it
I think looking at the code https://github.com/dominictarr/event-stream/issues/116#issuecomment-441746370 there are some very red flags.