{{announcement.body}}
{{announcement.title}}

Deep Dive Into NPM Security

DZone 's Guide to

Deep Dive Into NPM Security

In this article, we take a deep dive into NPM security by focusing on common vulnerabilities in packages and tools to monitor them.

· Security Zone ·
Free Resource

The Node Package Manager, abbreviated as NPM, is the premier registry for software packages in the Node.js ecosystem and has become one of the largest registries for software packages in the tech world.  

It provides the JavaScript developer with a plethora of choices for accomplishing a particular task during the software development process and enables the developer to focus on what really matters — the development of the application logic. As a result of this, it becomes easy for software teams to move fast and accomplish more work in a short period of time.

NPM official website
NPM packages are easily available through the web. Therefore, searching for a package to accomplish a particular task becomes a no-brainer, as a simple Google search would return a couple of packages that can perform the required task.

Google search for NPM package
However, security consciousness when dealing with NPM packages is expedient, as they have become a target for attack vectors from malicious entities. These attack vectors could result in significant damage once they find their way into the production systems of organizations.

Security in NPM Packages

The npm Inc., the company behind the NPM registry and CLI tool, has a dedicated security team through which all packages go before they are published on the NPM registry. The team possesses a well-defined guide that directs their security practices to ensure that only secure packages are made available to the public. 

Adam Baldwin, vice president of security at NPM Inc., in his interview with the Daily Swig said “Internally, we have tooling that reviews where packages are published from as well as dynamic and static analysis, to try to gain an understanding of the intent of the package and if there are any anomalies,”. He also spoke of NPM’s machine learning-powered API, which helps with spam-related packages and maintainers.

These strict practices and innovative tools used by the NPM Inc. team enable NPM packages to be used by Node.js development teams and individuals without having to worry much about security. 

However, as cybercriminals always seem to devise new ways of breaking security defenses, further steps may need to be taken in ensuring that the product produced by teams or individuals is free of security vulnerabilities from third-party sources. 

Common NPM Security Vulnerabilities and How To Fix Them

The NPM security team constantly works on discovering security vulnerabilities in NPM packages and notifies the package publisher if there is a vulnerability detected. 

Some common NPM software vulnerabilities include:

Prototype Pollution

This involves the pollution of an object’s prototype with data to cause weird code behavior. A malicious entity could use this to bypass validation rules which enforce access as seen in versions of @commercial/subtext prior to 5.1.2.

As seen in this StackOverflow answer, distributing compiled executables that communicate via interprocess APIs and exposing the library through service may be the only way to fully protect code from prototype pollution.

Denial of Service

According to Wikipedia

  • denial-of-service attack (DoS attack) is a cyber-attack in which the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to the Internet

Denial of Service security vulnerabilities could occur in NPM packages when a function throws an error which, if left unhandled, could open up opportunities for an attacker to launch an attack that replicates the unhandled error situation to shut down services rendered by the package in a codebase. This was observed in versions of @hapi/hapi prior to 18.4.1 or 19.1.1, versions of @hapi/ammo prior to 3.1.2 or 5.0.1, and a couple of other NPM packages. 

Cross-Site Scripting

As described by Wikipedia,

  • Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

Cross-site Scripting is quite common in NPM packages, as it appears a lot in the NPM security advisory. Examples of such include versions of @hapi/boom prior to 0.3.8,  versions of node-red prior to 0.20.8, among others. 

XSS vulnerabilities in NPM packages vary from failing to properly escape an error message to improper sanitization of page elements and attributes. 

XSS vulnerabilities could be prevented by filtering user input to ensure only valid inputs are allowed, encoding user-controllable data in the output of HTTP responses, using appropriate HTTP headers, and implementing Content Security Policy (CSP) to mitigate the occurrence of any more XSS vulnerabilities in the future. 

Command Injection

This occurs when parameters to a function in a package aren’t properly sanitized before the package is published. If this value is supplied by a user-controlled input, it might allow an attacker craft commands to be injected into the system which could result in unwanted code behavior. This could be seen in versions of hot-formula-parser prior to 3.0.1.

Command injection could be prevented by validating untrusted inputs, neutralizing meta-characters with meaning in the operating systems’ command line, and implementing permission levels where necessary.

Regardless of the NPM vulnerability, software developers could avoid falling prey to malicious attackers by introducing the following points in their development workflow.

Most NPM security vulnerabilities could be resolved by updating the package’s version to a more recent one. This process could be automated with Renovate, a tool that helps in the automation of dependency updates in software projects. It is easily customizable and could also run the software project’s existing test suite to ensure there are no regression errors due to dependency updates. 

How to Find Vulnerabilities in NPM Packages

In the previous section, we looked at various software vulnerabilities commonly found in NPM modules and a couple of ways we could mitigate the occurrence of these vulnerabilities.

Finding vulnerabilities in NPM packages used as third-party sources before pushing code to production will help avert possible breaches and keep malicious entities away. 

In this section, we look at possible ways of staying ahead of security vulnerabilities from NPM packages. 

NPM Audit

Recent versions of NPM feature a tool, NPM Audit, which automatically scans through third-party libraries in your Node.js application for security vulnerabilities. Audit reports are provided after the command, $ npm audit, is run, which provides some insight into the nature of software vulnerabilities that the application could be exposed to as a result of its third-party libraries. 

npm audit command output

The NPM Audit documentation provides a host of commands that could be employed in fixing these vulnerabilities.

However, this cannot fix all vulnerabilities. A couple of other security vulnerabilities would require some manual steps to be taken to ensure a fix is in place. 

Conclusion

NPM packages have greatly enhanced developer productivity and reduced the time taken by Node.js software teams to produce a Minimum Viable Product (MVP). 

However, great care should be taken when using these open source packages as software vulnerabilities they contain could also be targeted for malicious attackers. By employing techniques discussed in this article, companies can stay ahead of vulnerabilities that may arise in open source NPM packages. 

Further Reads:

Topics:
javascript ,node.js ,npm ,open source ,security ,vulnerabilites

Published at DZone with permission of Anton Lawrence . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}