NPM Release Security

Authored by Nazar Hussain

JavaScript is the most popular programming language in the world, and as such, it gets a lot of use in open source projects. This popularity has brought more attention from bad actors in the Javascript open-source ecosystem, and hence the ecosystem is more at risk simply by virtue of public access. Indeed, numerous open-source projects were exposed to hundreds of vulnerabilities in the last year alone.

Experiencing a vulnerability of one of your dependencies is one thing, but getting infected by a vulnerability intentionally in your javascript package releases is another. In the first scenario, there are many guidelines for choosing better dependencies⁠ - ones that have a more active user base, better test coverage, and, importantly, a quick release cycle.

In the second scenario, the fix is less straightforward. Yet, it's essential to protect your code from bad actors who may infect or expose your work to different vulnerabilities. And to do that, you must understand the threats involved in releasing code through node package manager (npm) or other registries and then develop the steps to mitigate them.

NOTE: The threats and guidelines mentioned below are not restricted to the npm or JavaScript ecosystem. They're equally important for other ecosystems as well.

Defending against common threats

There are quite a few threats to maintaining any project in the open-source ecosystem. Listed below are some of these and issues specific to the npm ecosystem.

Code obfuscation attack

A bad actor can publish a package with obfuscated code that exploits anyone who uses your code. You may be auditing or looking over the repository and miss that when the package dependency is installed, it uses an obfuscated version instead. We can minimize this threat vector by:

1. Make sure not to use any dependency with obfuscated code

2. While reviewing the packages, audit the compiled and obfuscated code

3. If needed, compile that dependency locally and see if it matches the same output

Git impersonation attack

Git allows any user to make any commit with the author and email address set to any (valid) value. One can also set the commit date as long as it's a valid timestamp. So, in this case, an attacker can push a commit in a long going pull request (PR) with the same author name/email address in a public repository. This may end up with an unintended inclusion of a code snippet. Here's how to protect against this:

1. Make sure all release branches are locked

2. Verify the authenticity of your organization's git users carefully

3. Enforce the rule that all users must sign commits with their GPG keys

4. Never merge a PR that includes any unsigned commits

Typosquatting attack

Typosquatting and combosquatting are examples of software supply chain attacks, where malicious packages are published with the intent of free-riding on the trust people put onto their third-party components. The use of open-source packages is quite popular in the NodeJS ecosystem, and it all lies in the trust of the developers. A few years ago, a fake babelcli was published to attack the original babel-cli and gained a couple of downloads in a few weeks. Here's what to do:

1. While using dependencies, double and triple check the dependency's name

2. Verify the dependency info with the npm info

3. Scan exiting public registry for the package names similar to your library

4. Ask the community to report any package which they found confusing or with a similar name

5. Setup a bot or service to monitor new package registration for the same purpose

Account takeover (ATO) attack

Account takeover fraud is a type of cybercrime or identity theft where a malicious third party gains access to (or "takes over") an online account. In the npm ecosystem, ATO is less frequent, but the impact is widespread.

Once an ATO happens, the attacker releases a patch version with infected code, and since most of the JS ecosystem depends on auto-version updates, the infected package spreads quickly. In the past, we saw ua-parser-js, coa, and rc packages like this. It does not matter if you use npm or Github registry. Both can affect ATO. To mitigate this threat:

1. Ensure that all users in Github use 2FA.

2. Ensure that all users on npm use 2FA.

Guidelines

NPM Security

Each time you log in to the npm CLI, a security token is created. That token can perform registry-related actions during CI and automated processes. It's possible that a token gets compromised during some data transfer or shared system usage. We can defend ourselves by:

1. Limit who has access to the npm registry

2. When one user is not intended to publish, always create a "read-only" mode npm token.

3. When one user is intended to publish, packages must assign a token to a particular IP. `npm token create - cidr=192.1.1.2

Audit and monitor vulnerabilities

The npm ecosystem is vast, and the more open and diverse it becomes, the more prone it is to vulnerabilities. In the past, most popular npm packages were found to be vulnerable. Some notable examples are request and jsonwebtoken. So staying on top of the security for all our dependencies would allow for a timely alarm before a new version injects a malicious code into your library. Therefore, it's important to:

1. Keep updating your dependencies to get more stable and secure versions

2. Use a vulnerability monitoring service like sync.io to keep an eye on all dependencies

Avoid publishing sensitive data on Github

It's not uncommon for developers to have sensitive data on their development machines - for instance, API keys. And this opens the possibility that such information can be mistakenly committed to Github or any other version control you use. To prevent this:

1. Create a special file or structure for sensitive data. E.g. a directory .secrets/keys. This will ensure everyone knows if they want to use some keys that can be put in this file.

2. Add such files to ‘.gitignore' to make sure these never become part of the SVC.

3. While doing code reviews on Github, pay special attention to collapsed files. In Pull Request review mode, Github collapses very large files, and such files are often accidentally skipped during a review.

The above mitigation steps and guidelines are not a bulletproof plan to protect your npm package release but will at least protect you from commonly known factors. As a package release manager, you must always keep a vigilant eye on your package releases. Having a well-defined security and vulnerability reporting mechanism for the community can also be a good addition. We wish you all safe releases!

Disclaimer: The suggestions above cover some of the fundamentals and are not fit for every project or situation.

About ChainSafe

ChainSafe is a leader in blockchain development and infrastructure solutions for Web3. We're working toward a more decentralized future by building client implementations for Ethereum, Filecoin, Polkadot, and Mina. We're also maintaining the Web3.js library, working on a gaming SDK that connects NFTs to Unity, building a distributed cloud storage application, and bootstrapping a multi-chain bridge. To learn more, click here.

Want to help build the foundations of Web3? Join us!

Have a question, comment, or suggestion? Drop into our Discord and join the conversation! We're also always looking for talented people. Check out our open positions and get in touch ➡️➡️ careers@chainsafe.io

Website |Youtube |Medium |Twitter |Linkedin |GitHub

Acknowledgments

Special thanks to M. Junaid Taj and Colin Adams for their help writing this article.