💪 Exhaustive checklist to assist in a security review of a Node.js web service code. Focused on Express and Hapi environments.

The next documents have been using as main references:

• The SANS SWAT (Securing Web Applications Technologies) checklist.
• The CWE (Common Weakness Enumeration) dictionary.

Related: ☠️ Awesome Node.js for penetration testers

Express: By default (if not in "production" mode) exposes the stack trace of the error to the client.

Hapi: Not exposed by default.

• They could allow an attacker to detect it as part of a more sophisticated attack.
• Define a custom error handler. The way to achieve this is using a middleware.

Express:

• The Default Error Handler
• http-errors:

  Create HTTP errors for Express, Koa, Connect, etc. with ease".

Hapi:

• Custom implementations: https://stackoverflow.com/a/28044412/2087521, https://stackoverflow.com/a/32185406/2087521
• Boom: Easy consistent HTTP errors.

• This kind of exceptions mean that the application is in an undefined state. So don't try to simply restart the application again without properly recovering from the exception or fixing the bug. This could head to additional unforeseen and unpredictable issues.

• So what's the best way of dealing with uncaught exceptions? There are many opinions floating around on this.
• You application shouldn't have uncaught exceptions. This is clearly insane.
• You should let your application crash, find uncaught exceptions and fix them. This is clearly insane.
• You should swallow errors silently. This is what lots of people do and it is bad.
• You should let your application crash, log errors and restart your process with - something like upstart, forever or monit. This is pragmatic.
• You should start using domains to handle errors. Clearly the way to go, although this is an experimental feature of Node.

• (from Uncaught Exceptions in Node.js)
• Last two cases can be considered safe.
• Further reading: About how to handle errors by Joyent -> https://www.joyent.com/developers/node/design/errors

Hapi: Poop: "hapi plugin for handling uncaught exceptions".

Heroku: Auto-restart through the Dyno crash restart policy.

• A common example is a response like: "Invalid login" vs. "User not found". If we use the second we are allowing a possible brute-force of our usernames.
• Some modules can help to send consistent ones (easier to reason about).

Express/Hapi: See point 1.4

• A common example is when the combination "username/password" is "good/bad" vs "bad/bad".
• To detect it:
  • Use this ESLint rule : "detect-possible-timing-attacks".
  • Some tools to automate it: nanown, time_trial
• To prevent it use secure libraries to compare like:
  • "cryptiles" (Hapi project)
  • "credential"
  • "safe-compare"

• Control all our errors, massaging them if needed to avoid the risks commented in these last points.
• Use mature modules.
• Use secure modules. Add checks to your development workflow with a tool like audit-ci or auditjs.

• To avoid the framework fingerprinting.

Express: Enabled by default, two options:

• Use app.disable('x-powered-by').
• Use Helmet middleware ("hide-powered-by" plugin).

Hapi: Disabled by default.

Express: The middleware "body-parser" provides a comfortable mechanism to support this.

Hapi: Multiple options can be set for an specific route ("parse" option).

If parsing is enabled and the 'Content-Type' is known (for the whole payload as well as parts), the payload is converted into an object when possible

• Use the HTML input "autocomplete" Attribute in the client side to avoid be cached by the browser.

Express: Use Helmet middleware ("nocache" plugin). Remember to also disable the Etag ("noEtag").

Hapi: All kind of cache disabled by default, just confirm the code it's not using anyone included here. They can also be enabled for an specific route.

Express: Use Helmet middleware ("xssFilter" plugin) to improve protection in new browsers.

Hapi: Disabled by default, the framework supports it through the route options "security" ("xss" field).

Handlebars: The function "escapeExpression" is used by default.

Handlebars HTML-escapes values returned by a {{expression}}. If you don't want Handlebars to escape a value, use the "triple-stash", {{{"*).

Dust.js: Enabled by default.

All output values are escaped to avoid Cross Site Scripting (XSS) unless you use filters"*).

Swig: The options "autoescape" is needed.

Always use an validator for all the parameters used in each route:

Express: express-validator

Hapi: joi

However, contextual escaping is missing in most template frameworks including Handlebars JS, React JSX, and Dust JS.

(by Yahoo’s Paranoid Labs).

Their solutions: secure-handlebars, express-secure-handlebars.

• "Blindly-escaping is insufficient" (by Yahoo)
• Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems (Google, 2009)
• Deep explanation and demo included in the section A3 of NodeGoat tutorial.

Express: Use Helmet middleware ("ienoopen" plugin). Hapi: Disabled by default, the framework supports it through the route options "security" ("noOpen" field).

• Use escaped values:
  • MySQL.
  • PostreSQL
• Deep explanation and demo included in the section A1 (section B) of NodeGoat tutorial.

ESLint rule: "strict".

ESLint rules:

• "no-eval".
• "detect-eval-with-expression".

ESLint rule: "no-implied-eval".

ESLint rule: "detect-child-process".

ESLint rule: "detect-non-fs-filename".

ESLint rule: "detect-non-literal-require".

ESLint rule: "detect-non-literal-regexp".

Deep explanation and demo included in the section A8 of NodeGoat tutorial.

Express: csurf

Hapi: crumb

Express: Use Helmet middleware ("csp" plugin).

Hapi: blankie module.

Express: Use Helmet middleware ("frameguard" plugin).

Hapi: Disabled by default, the framework supports it through the route options "security" ("xframe" field).

CVE-2014-7939 Detail

Express: Use Helmet middleware ("nosniff" plugin).

Hapi: Disabled by default, the framework supports it through the route options "security" ("noSniff" field).

The core "path" module "extname" method is a simple option.

I want to restrict a path to something within a given root dir, I usually do something like this

(from createWriteStream vulnerable to path traversal?)

var safePath = path.join(safeRoot, path.join('/', unsafePath));

ie: email, Slack, etc. (CWE-778)

By importance ("warn", "info", etc.) and/or file ("server").

Use an independent logger or a debugger with a debug level as the default to print always. So we're using the term "logger" (or "logging") to refer to both from now.

"debug": Using it all logs will have the same structure and we can change what to see using the "DEBUG" environment variable. Moreover it's the same used in Express.

ie: When you run a worker or standalone script.

Use log rotation and increate the limits until you consider it's safe. BTW the free plan of the wide used cloud services (over 48 h.) is not enough.

• "Logging v. instrumentation"

Look for another input (ie: session, DB) if possible or sanitize them before. The reason is to avoid an attacker impersonation and/or track covering (CWE-117)

• To avoid a possible modification from attacker writing in them.
• Use secure tools to inspect automate the log inspection.

Log encryption (or part of them, ie: using a secure hash). Please refer to next section ("Cryptography").

• We also need to store these server logs in a secure environment.
• A cloud service is comfortable here, this way you transfer the risk to them.
• If the log service has a management panel, a 2-factor authentication mechanism is mandatory.

Specially before the user authentication (ie: sending a password).

Express: express-force-ssl

• Extremely simple middleware for requiring some or all pages to be visited over SSL.

Hapi: hapi-require-https

• hapi http -> https redirection for servers behind a reverse proxy.

Heroku & SSL:

• Addon: Expedited SSL
• HowTo: https://www.youtube.com/watch?v=OcyR7Yus4pc

Express: Use Helmet middleware ("hsts" plugin).

Hapi: Disabled by default, the framework supports it through the route options "security" ("hsts" field).

A tool that can help to find them is GitRob.

• Simply don't roll your own crypto!, except for fun/learn. All frameworks include their own solutions to manage the login system and npm is full of them, just use one mature enough. Even we have other good standalone options, like the Passwordless middleware.
• An interesting option is to avoid using passwords at all (CWE-309). Most of actual web applications connect user social accounts, so I think it's better to rely on them using a mature module (Passport or Bell). Better in one with mechanisms to figth against fake profiles.

• Remember, in general, MD5, SHA1, SHA256, SHA512, SHA-3, etc are not fully secure to other thing but check the integrity of the data. it's better to use bcrypt or pbkdf2 based libraries.
• How To Safely Store A Password. The main advantage of pbkdf2 is to be platform independent.

• More specific:

  Note that the upgrade to OpenSSL 1.0.1s in Node.js v0.12.11 removed internal SSLv2 support. The change in this release was originally intended for v0.12.11. The --enable-ssl2 command line argument now produces an error rather than being a no-op."

  • Node v0.12.12 (LTS) release
• Use an updated version of Node.js.
• Refer to point 3.4 tips.
• Just in case, check TLS Node.js core module "secureProtocol" option which is being used.
• To exclude one cipher from the allowed ones use the option "cipher" in the TLS module.

• Confirm the server is using a correct value for these options when requesting through the TLS Node.js core module: "rejectUnauthorized" (default:true),"checkServerIdentity", "secureProtocol".

• A good to verify possible problems is "sslyze".

• A good option: Let's Encryt, an open CA. Automatic HTTPS Certificates for Node.js.

  Automatic live renewal.

  On-the-fly HTTPS certificates for Dynamic DNS (in-process, no server restart).

  Works with node cluster out of the box.

  Free SSL (HTTPS Certificates for TLS) 90-day certificates.

Express: letsencrypt-express.

Hapi and Hapi middleware: letsencrypt-hapi.

• A tool that can help again is GitRob.
• The correct way to avoid hardcoding the credentials of the different microservices is to use environment/application variables. Only the one in charge of the deployment should have access to get/set them through a secure channel.

• Please, refer to the point 4.6 of this document, just use a mature option.
• An important specific check is to validate the security of the generated token sent to the user email.

• We should ask them for a new better option if it doesn't reach our expectations.
• Please, refer to the point 4.6, use a mature solution.
• By the way we have some good modules to check the strength of the passwords set by the users.

Implement it manually, no serious solution found out there to help with this.

• node-ratelimiter: It uses Redis, supports reset.
• To locate an IP address: node-geoip, but there're multiple options.

Express middlewares:

• node-ipgeoblock: "blacklist of IPs, the blacklist of countries or the whitelist of countries.""
• express-limiter: Built on Redis, whitelists support.
• express-brute: Support multiples stores, "increasing the delay with each request in a fibonacci-like sequence".

Hapi:

• hapi-ratelimit: Built on Redis.
• Manual implementation: https://gist.github.com/whisher/d6e3db7c11d632720133

• A common example is to get an user ID from "req.params.userId" (which could be manipulated directly in the request payload) instead "req.session.userId".
• Deep explanation and demo included in the section A4 of NodeGoat tutorial.

• The quickest and most secure option here is to use a well-tested framework to implement this part, ie: Passport.
• Map each internal ID to a shorter (and more beautiful) one before sending it to the client and use it for the whole communication.
  • "shortid": "Short id generator. Url-friendly. Non-predictable. Cluster-compatible.".
• Deep explanation and demo included in the section A7 of NodeGoat tutorial.

• In general, avoid using URL redirection.
• It is recommended that any destination parameters is a mapped value, instead of the actual URL (or a part).
• Deep explanation and demo included in the section A10 of NodeGoat tutorial.

The basic idea is to use a secure method (random and enough length) to generate each user session identifier. The best option, as always, is to use a mature option.

Express:

• A secure method is used ("uid-safe" module) by default in the "express-session" middleware.
• Moreover the user can define his own one using the "genid" option.

Hapi:

• The methods server.cache includes the method "generateFunc" to specify your own algorithm.
• Another of the most used options ("hapi-auth-basic", "hapi-auth-cookie" and "yar").
• Neither of them don't include a method to generate it by default. So the user have to implement his own using a secure alternative (again, like "uid-safe").

• Inactive sessions should be destroyed automatically when the user is inactive from an amount of time. There are multiple JavaScript libraries to achieve it from the client-side.

Express: The connect-redis library supports the "ttl" options to set the session expiration.

Hapi:

• The server side caching is a built-in feature. It includes the method "server.state" also includes the option "ttl". Moreover it also includes the "server.cache" one which supports the following options:

  • expiresIn - relative expiration expressed in the number of milliseconds since the item was saved in the cache. Cannot be used together with expiresAt.

  • expiresAt - time of day expressed in 24h notation using the 'HH:MM' format, at which point all cache records expire. Uses local time. Cannot be used together with expiresIn.

  • staleIn - number of milliseconds to mark an item stored in cache as stale and attempt to regenerate it when generateFunc is provided. Must be less than expiresIn.

  • staleTimeout - number of milliseconds to wait before checking if an item is stale.

• Another important check is to confirm (to avoid pollution and future space problems) that the session is also destroyed in the permanent storage (ie: Redis).

Express: The "express-session" middleware includes the methods "Session.Destroy" and "store.destroy" (persistent) to manage it in a consistent way.

Hapi: Native server cache manages it correctly through the supported storages via catbox.

Express: The "express-session" middleware offers the method "regenerate" to make it easier.

Hapi: here we have the method "generateFunc". Check point 6.1 tips to know more.

Express: The "express-session" middleware offers the option "name".

Hapi: Cookies enabled by default, the option "name" in the method "server.state".

Express: The "express-session" middleware offers the option "secure".

Hapi: Cookies enabled by default, the option "isSecure" in the method "server.state".

Express: The "express-session" middleware offers the option "httpOnly".

Hapi: Cookies enabled by default, the option "isHttpOnly" in the method "server.state".

Express: The "express-session" middleware offers the option "secret".

Hapi: Cookies enabled by default, the option "sign" (for "integrity" and/or with password) in the method "server.state".

Travis and Heroku's GitHub integration is a comfortable option.

Istanbul is a well-known option.

Tools like audit-ci or auditjs help with this.

"npm-check-updates" automates it for you.

Use this ESLint rule : "detect-unsafe-regex".

• To support the last version of the dependencies.
• Use the tilde and caret correctly in the "package.json" file.
  • https://nodesource.com/blog/semver-tilde-and-caret

The solution is to use "npm shrinkwrap".

• The solution is to block them. So it's better to have an npm/Grunt/Gulp task to do it: Package install scripts vulnerability

• A library to help: Surku
• Use external libraries like ZAP (Node.js bindings).

• Attackers should use the easiest way to break in, so we also need to secure the OS where the service is running.
• Cloud deployment platforms are a good option to minimize this risk.
• In case you prefer to manage your own OS a good tool to check automatically its security in an easy way is Lynis.

• All involved microservices should respect this rule.
• Again a comfortable solution is to use a cloud deployment environment to avoid this risk.

• Sending them to conferences is a fun way to achieve it with good results.
• Official advisories: https://groups.google.com/forum/#!forum/nodejs-sec.
• It's good to watch the Github repositories for notifications to be informed if any vulnerabilities are discovered in the package in future.

Have in account that sometimes we need to assume risks.

• Which includes how to recover from the worst case scenarios (ie: Amazon -> Heroku, GitHub down).

Drop not needed stuff as much ass possible, keep it simple. Less surface exposure -> more secure.

Apply this methodology ;).

Internal: To know how to conduct a pentest it's not our responsibility as Backend developers. But of course we know about web technologies so it's something we can do for sure. We can learn at the same time we mitigate some of the vulnerabilities that are going to be found in the next step (they always find stuff:)). The best point to start (and the same the professionals use) is the OWASP Testing guide. Some free tools which can help to automate it are: ZAP, sqlmap, Skipfish, w3af, Nikto.

External: Again just hire a proper company.

This work is licensed under a Creative Commons Attribution 4.0 International License