Types of Sessions

Before we dive into the details of sessions and securing sessions on top of the mechanisms that Express provides by default, it is sensible to explore the differences between cookies and sessions (Figure 6-1) and what makes them interesting.

Figure 6-1. Session and cookie relationship

How Express Handles Sessions

Since version 4 of Express, a lot of bundled middleware (for example, bodyParser, cookieParser, and session) has been moved into separate modules to allow for quicker updates and better maintainability. This section explores some of the functionality that the module express-session brings to the table in order to allow for secure handling of sessions.

When using the Express generator or looking at most tutorials, you will see a default initialization of the session middleware that looks something like this:

var session = require('express-session');

app.use(session({
  secret: 'mechagodzilla',
  resave: false,
  saveUninitialized: true,
  cookie: {
    secure: true
  }
}));

Let’s look at the default options that are being passed to the middleware:

• secret is a required option and resembles the session secret that is utilized to sign the session ID cookie. The session module relies on the node module cookie-signature, which utilizes crypto (a popular module for cryptography) in order to sign the provided value with SHA-256 as keyed-hash message authentication code, also known as HMAC. Finally, the signed value is hashed as Base64 before being returned to Express.

• The next option, resave, determines whether sessions are saved in the session storage even when they did not get modified. This used to default to true but its use is no longer recommended. Instead, decide based on your session storage: if req.session.touch() is used, resave can be set to false; otherwise, true is the recommended value.⁴

• saveUninitialized is used to indicate whether a new (but unmodified) session should be saved. While true is the default value, it is recommend to set this value to false when being used to handle authentication.

• cookie allows for deeper configuration of your session ID cookie. secure is recommended to be set to true and ensures that secure cookies for HTTPS-enabled websites work. The session middleware does not rely on the cookieParser middleware anymore and can even cause issues when used in conjunction with it.

• cookie.maxAge is set to null by default and results in cookies being handled as browser-session cookies, which means that they are removed as soon as the browser window is closed.

A prime feature of this middleware is the possibility of setting up your own function for generating session IDs. genid can be used with any function that creates and returns unique IDs. Currently, the default implementation uses uid2.

var session = require('express-session');
var uuid = require('node-uuid');

app.use(session({
  genid: function(req) {
    return uuid.v4()
  },
  secret: 'mechagodzilla',
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true
  }
}));

var cookie = require('cookie-signature');

var value = 'test';
var secret = 'myamazingsecret';

var signedValue = cookie.sign(value, secret);
// signedValue is 'test.6L58yh6xptQIl6IyKA5GxGr63TRJwwxTNUYy6ui51Bk'

var unsignedValue = cookie.unsign(signedValue, secret);
// unsignedValue is 'test'

var session = require('express-session');
var uuid = require('node-uuid');

app.use(session({
  genid: function (req) {
    var timestamp = Date.now();
    var id = uuid.v4();
    var sessionId = id + '$' + timestamp;
    return sessionId;
  },
  secret: 'mechagodzilla',
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true
  }
}));

var sessionParts = req.sessionID.split('$');
if (sessionParts.length === 2) {
  var timestamp = sessionParts[1];
  // Validate session
  ...
}

The Three Types of XSS Attacks

When dealing with XSS prevention mechanisms, three attack methods become apparent:

• Persistent XSS

• Reflected XSS

• DOM-based XSS

Persistent XSS relies on malicious code being stored in a website’s database. This results in the injected code being loaded over and over again and was a popular exploit in the early days of Internet forums.

Reflected XSS attacks originate from the original request and can be seen as one-time attacks that are returned in the server’s response to the victim.

The last type, DOM-based XSS, is based on modifying client-side code and often attacks the URL’s fragment identifier, which we know as the hash mark that normally serves for navigational purposes. Another example of DOM-based XSS is modifying entries in HTML5’s LocalStorage; OWASP released a cheat sheet when dealing with HTML5 in order to assist with securing your application.⁸

Testing XSS Protection Mechanisms

In this section, we will explore how a basic reflected injection attack works and which mechanisms Node, HTTP, and the browsers put into place to prevent exploitation.

First we will generate a new project (using the Express generator) configured to be vulnerable. To get started, execute the following command in your terminal:

express xss
cd express
npm install .

This generates the initial setup for our application. After all modules are installed, we can start working on a basic user-registration feature—residing in views/index.jade—which accepts a first and last name and eventually displays these details on a simple profile page:

extends layout

block content
  h1 Registration
  form(method='POST', action='/register')
    fieldset
      legend Your details
      label(for='firstname') Firstname
      input(id='firstname', name='firstname', type='text')
      label(for='lastname') Lastname
      input(id='lastname', name='lastname', type='text')
      input(type='submit', value='Submit')

The form submits a POST request with the populated body to the route /register. In this step, we will add this new route declaration to our application (which you can find in routes/index.js):

router.post('/register', function(req, res) {
  var user = {
    firstname: req.body.firstname,
    lastname: req.body.lastname
  };

  res.render('profile', { user: user });
});

For this example, we don’t bother with storing user data and simply render another template, profile, with the POST request’s details. The profile page is created by running the following command:

touch views/profile.jade

The following template displays the user’s first name and last name by using Jade’s buffered code mechanism:

extends layout

block content
  h1 Your Profile
  p= user.firstname
  p= user.lastname

Now that all the pieces are in place, we can run our first attempt at an XSS attack. Instead of submitting an innocent combination of first and last name, we want to abuse the last name in order to submit a script that loads another site:

<script>window.location="http://tme.coffee"</script>

Submitting the details populates the POST request’s body like this:

{
  firstname: 'Tim',
  lastname: '<script>window.location="http://tme.coffee"</script>'
}

Now the basic assumption is that our profile page would simply render the information provided and therefore load the URL http://tme.coffee instead of displaying the last name.

Gladly, Jade escapes buffered code and therefore simply renders the output shown in Figure 6-2.

Figure 6-2. Escaped profile information

When inspecting the page’s source, you will notice that the escaped profile page renders like this:

<body>
  <h1>Your Profile</h1>
  <p>Tim</p>
  <p>&lt;script&gt;window.location=
      &quot;http://tme.coffee&quot;&lt;/script&gt;</p>
</body>

For this upcoming step, let’s be foolish and disable this automatic escaping-mechanism. We can do this by changing the template:

extends layout

block content
  h1 Your Profile
  p= user.firstname
  p!= user.lastname

Instead of displaying buffered code with =, we use the functionality to render unbuffered code, != (which is definitely not safe for input) and resubmit our form.

This is where things get interesting, as differences in browsers become quite apparent. Chrome (tested with Version 48.0.2564.48 beta) doesn’t render the last name field and prints the following statement in the JavaScript console:

Doing the same experiment with Mozilla’s Firefox V42 results in the script tag executing—the browser loads up the page http://tme.coffee.

XSS Auditor is a feature that was initially introduced with WebKit and made its way into the Chromium Project’s WebKit fork Blink. That implies that a wide array of browsers such as Chrome, Opera, and Safari come with this built-in mechanism against reflected XSS attacks. Microsoft’s Internet Explorer supports XSS Auditor functionality with version 8 and above.

static bool startsOpeningScriptTagAt(const String& string, size_t start)
{
    return start + 6 < string.length() && string[start] == '<'
        && WTF::toASCIILowerUnchecked(string[start + 1]) == 's'
        && WTF::toASCIILowerUnchecked(string[start + 2]) == 'c'
        && WTF::toASCIILowerUnchecked(string[start + 3]) == 'r'
        && WTF::toASCIILowerUnchecked(string[start + 4]) == 'i'
        && WTF::toASCIILowerUnchecked(string[start + 5]) == 'p'
        && WTF::toASCIILowerUnchecked(string[start + 6]) == 't';
}

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8,de;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Content-Length:73
Content-Type:application/x-www-form-urlencoded
Host:localhost:3000
If-None-Match:W/"be-JIAfZIOVAe1p85FawKqWIg"
Origin:http://localhost:3000
Referer:http://localhost:3000/
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) ...

router.post('/register', function(req, res) {
  var user = {
    firstname: req.body.firstname,
    lastname: req.body.lastname
  };

  res.set('X-XSS-Protection','0');
  res.render('profile', { user: user });
});

Conclusion

Through a combination of sensible browser defaults like the X-XSS-Protection header and the features of modern templating engines like escaping input, a solid base-layer security is being provided. Previously, we’ve explored security-layering, and it definitely makes sense to hold on to this behavior when dealing with reflected XSS. As developers, we should use both client-side and server-side features that help escaping and sanitizing input in order to prevent exploitation of our application.

More information on XSS attacks and tools that help with reducing attack vectors can be found on http://excess-xss.com.

Handling CSRF with csurf

Express offers an optional middleware called csurf that can be installed via npm. The module provides a unique token that needs to be rendered in forms and will be validated after form submission—a mechanism that’s similar to what we have done with providing the state parameter when requesting the Authorization Code in the previous example:

var csurf = require('csurf');

var csrfMiddleware = csurf({
  cookie: true
});

app.get('/form', csrfMiddleware, function(req, res) {
  res.render('form', { csrfToken: req.csrfToken() });
});

In this example, we create a new middleware based on csurf that stores cookies instead of req.session to store the CSRF token secret. This middleware is mounted for the route /form and provides the generated token as an option to the form template:

extends layout

block content
  h1 CSRF protection using csurf
  form(action="/login" method="POST")
    input(type="text", name="username=", value="Username")
    input(type="password", name="password", value="Password")
    input(type="hidden", name="_csrf", value="#{csrfToken}")
    button(type="submit") Submit

By rendering the CSRF token as a hidden part of a hypothetical login form, we provide a way to send the token back to the server. This allows us to validate the authenticity of our request in the /login route:

app.post('/login', csrfMiddleware, function(req, res) {
  // This request is unique and can be handled accordingly
});

Some of the functionality in csurf relies on using a session middleware (like cookie-parser or express-session) before using the middleware itself. This is just a matter of handling the initialization process of your application’s middleware accordingly.

Protecting our application against CSRF attacks with popular modules such as csurf is incredibly easy and leaves little excuse for not doing so. By simply using a middleware and handling the provided token, a whole level of threat can be managed.

Lusca

Back in 2012, PayPal started adopting Node to power its application stack. Part of this process was the development of krakenjs, an extension of Express. Part of the kraken suite is a module called Lusca, which focuses heavily on improving security by setting sensible defaults and providing protection mechanisms against prominent vulnerabilities.

Lusca can be used as application-level middleware by adding it to your application’s initialization process:¹⁵

var express = require('express'),
    app = express(),
    session = require('express-session'),
    lusca = require('lusca');

//this or other session management will be required
app.use(session({
    secret: 'abc',
    resave: true,
    saveUninitialized: true
}));

app.use(lusca({
    csrf: true,
    csp: { /* ... */},
    xframe: 'SAMEORIGIN',
    p3p: 'ABCDEF',
    hsts: {maxAge: 31536000, includeSubDomains: true, preload: true},
    xssProtection: true
}));

Please note that not only common threats such as XSS and CSRF are covered. Lusca also features HTTP Strict Transport Security (HSTS), Content Security Policy (CSP) options, and support for the X-Frame-Options response header.

Helmet

Helmet is a collection of 10 security middlewares that operate similarly to how PayPal’s Lusca functions. You can either use a default initialization with app.use(helmet() and cover 6 out of 10 middlewares or use the submodules individually.¹⁶

Currently, Helmet comes with the following modules:

• contentSecurityPolicy, which contains CSP settings

• dnsPrefetchControl, which controls browser DNS prefetching. Currently beta and soon part of the default middleware.

• frameguard, for prevention of clickjacking

• hidePoweredBy, which controls the X-Powered-By header

• hpkp, HTTP Public Key Pinning

• hsts, HTTP Strict Transport Policy

• ieNoOpen, X-Download-Options (IE8 and newer)

• noCache, which enables or disables client-side caching

• noSniff, which prevents MIME-type sniffing

• xssFilter, the X-XSS-Protection header

We definitely recommend reading Helmet’s documentation. The contributors took the time to provide detailed explanations of attack types and how they can be mitigated.¹⁷

Node Security Project

The last valuable resource that is worth mentioning is the Node Security Project. Subscribing to its Node Security Newsletter is definitely worthwhile and trying out nsp. nsp allows for auditing your Node application’s package.json and npm-shrinkwrap.json files for known vulnerabilities.

Install nsp by running the following command:

npm install -g nsp

Then navigate to your project and run nsp like so:

cd testapp
nsp check

Potential output looks similar to Figure 6-3.

Figure 6-3. nsp security audit

The Node Security Project also curates a list of valuable resources (such as talks, papers, blog posts, and more).¹⁸ This collection serves as a great overview of current security best practices for Node.