Posted by David Bohannon on May 17, 2017
Before jumping into the final post within our discussion on vulnerabilities in the MEAN stack, look back at the other four posts within this series discussing MongoDB, ExpressJS (Core), ExpressJS (Sessions and CSRF), and AngularJS.
By default, Express applications run in development mode unless the NODE_ENV environmental variable is set to another value. In development mode, Express returns more verbose errors which can result in information leakage. For example, the error message below returns the full path to the requested file. This also provides an attacker with information about the host system.
Verbose error leaks full path to requested file
If the NODE_ENV variable is set to ‘production’ (or any value other than ‘development’), the Express server no longer returns the verbose message.
Setting NODE_ENV variable at runtime
Express returns generic error message
On Unix systems, non-root users cannot bind to low-numbered ports. This means that NodeJS must be run as root to bind to port 80. However, if we sudo to root to start our web server then our application will be running with unnecessary privileges. To remedy this, invoke the process.setgid and process.setuid methods in the callback function after binding to port 80 as shown below.
Using this approach, we can still start the application with root privileges allowing us to bind to low-numbered ports before downgrading to a less-privileged user ID.
A common concern with open source technologies is using vulnerable components. The Node Security Platform maintains a record of NodeJS plugins with known security issues. This is an active project that even provides a command line tool to scan projects for vulnerable dependencies by inspecting the package.json file. Checking a project is literally as easy as typing “nsp check.”
Using ‘nsp’ command line tool to identify vulnerable NodeJS dependencies
The vulnerabilities covered during this series are not an exhaustive list. They exhibit some of the more common vulnerabilities encountered when using these technologies, especially with default configurations. Hopefully this information can be used to assist developers in creating more secure applications as well as help security testers identify bugs and flaws within existing applications.
Get the latest Software Integrity news, thought leadership, and more.