Apr 8, 15 2:29 am

Was this post helpful?

Secure Your Express Application

Apr 8, 2015
| by:
Sherif Koussa
What is Express JS?

At Software Secured, we have been building our internal tools around Node.js and Express. Node.js is becoming more and more popular nowadays and several frameworks have popped up to wrap Node.js functionality and APIs. One of these frameworks is Express JS. Express is very popular today as it was one of the first frameworks for Node.js that handled server-side web tasks. It takes care of mundane tasks, like routing, parameter parsing, templates, and sending responses to the client's browser.  Node.js make it easier to develop secure applications using Express JS; there are a bunch of security features that can be enabled easily by making simple modifications. The following contains a quick rundown of these features.

Enable CSRF Protection

This is super easy to setup. We use the lusca module. The code looks something like this:

[code]var express = require('express');
var session = require('express-session');
var app = express();
var csrf = require('lusca').csrf();
...
app.use(lusca.csrf());[/code]

This is then used in the forms that post to the server:

[code]form(role="form" action="..." method="post")
input(type='hidden' name='_csrf' value=_csrf)
...[/code]

Dont Run as Root

It’s been long foretold by the ancient bearded ops that one shall run a service with the least amount of privilege necessary and no more.

One way to approach this is to drop process privileges after you bind to the port using something like this:

[code]var express = require('express');
var app = express();
...
app.listen(app.get('port'), function() {
process.setgid('www-data');
process.setuid('www-data');
});[/code]

Another way is putting something like nginx or another proxy in front of your application. Whatever you do, just don’t freak’n run as root.

Turn off X-Powered-By

Why? Because you don’t want to make it easy for an attacker to figure what you are running The X-Powered-By header can be extremely useful to an attacker for building a site’s risk profile

X-Powered-By: Express

Can be removed using:

[code]var express = require('express');
var app = express();
...
app.disable('x-powered-by');[/code]

Use Generic Cookie Name

One way to fingerprint your application is using the cookie name.
jsessionid -> Java application
phpsessid -> PHP application
ASP.NET_SessionId -> .net application

This is again a technique to hide information about what technology is being used.

[code]app.use(express.session({
secret: 'some secret that now one knows',
key: 'sessionId'
}));[/code]

Add HTTPOnly and Secure Flags to Session Cookies

Session cookies should have the SECURE and HTTPOnly flags set. This ensures they can only be sent over HTTPS (you are using HTTPS, right?) and there is no script access to the cookie client side.

[code]app.use(express.session({
secret: "s3Cur3",
key: "sessionId”,
cookie: {
httpOnly: true,
secure: true
}}));[/code]

Use the Content Security Policy (CSP) Header

This header is implemented in a select set of browsers at the moment, but still helps towards fending off attacks.

[code]var express = require('express');
var helmet = require('helmet');

var app = express();
...
app.use(helmet.contentSecurityPolicy({
defaultSrc: ["'self'", 'default.com'],
scriptSrc: ['scripts.com'],
...
}));[/code]

Use Secure Headers

These can all be enabled in an express app using some combination of helmet and lusca modules

  • X-Content-Type-Options - stops browser mime type sniffing
  • X-XSS-Protection - Setting to '1; mode=block' tells IE to turn on anti cross site scripting engine
  • X-Frame-Options - Setting this disallows the site to be included in a frame or iframe
  • Cache-Control - This enhances privacy. We can set to nocache for sensitive information.
  • X-Content-Security-Policy - This is CSP and was described
  • Strict-Transport-Security - checks for use of https
  • Access-Control-Allow-Origin - Controls which site can bypass same origin policy

Each header is further described here: Seven Web Server HTTP Headers that Improve Web Application Security for Free

Check for HTTP Parameter Pollution (HPP)

Give the following GET request:

[code]// GET /search?firstname=John&firstname=John[/code]

What will this return?

[code]req.query.firstname[/code]

It will return the following:

[code][“John”, “John”][/code]

Express populates HTTP request parameters with same name in an array

An attacker can:

  • Trigger Type Errors in application
  • Any uncaught errors in async code could crash the HTTP server causing DoS
  • Modify application behavior
  • Bypass input validations applied on strings in our code, WAF, browser filters.

Solution:

  • Check expected type as part of the input validation
  • Implement robust error handling mechanism using try/catch, domain, and cluster.
Regular Expression Denial of Service (ReDoS) Attack

Evil regex can take exponential execution time when applied to certain non-matching inputs.
By default, regex gets executed in event loop thread, so could be exploited for DoS attack.
In order for a regex to be evil regex, several requirements should happen:

( )+
( a+ )+
( a|aa )+

1. Grouping with repetition, and
2. Inside repeated group, repetition or alternation with overlapping.

Solution:

  • Review regex in our or external code for evil pattern
  • Do not use user-supplied inputs as regex

Final Notes:

This a very cool project that has sprung up semi-recently that is working towards making the nodejs ecosystem more secure

https://nodesecurity.io

That's all for now folks.

Was this post helpful?

About the Author

Sherif Koussa
Sherif Koussa is OWASP Ottawa Chapter Co-Leader, Software Developer, Hacker, and founder and CEO of Software Secured and Reshift. In addition to contributing to OWASP Ottawa for over 14 years, Sherif contributed to WebGoat, and OWASP Cheat Sheets. Sherif also helped the SANS and GIAC organizations launch their GSSP-Java and GSSP-NET exams and contributed to a few of their courses. After switching from the software development field to the security field, Sherif took on the mission of supporting developers shifting security left, and ship more secure code organically.
Share This Post

Leave a Reply

Your email address will not be published.

Related Post

Aug 9, 2023 by Cate Callegari

Worried Penetration Testing Will Derail Your Sprint Cycle?

Read more

Was this post helpful?

Jul 17, 2023 by Shimon Brathwaite

7 Agile Software Development Habits that Produce Security Concerns

Read more

Was this post helpful?

Jul 4, 2023 by Cate Callegari

Common Security Misconfiguration Habits

Read more

Was this post helpful?

Office

301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4

Designed by WP Expert
© 2023
Software Secured
cross