Sessions State keeping by the server

Sessions

Under the name of sessions go various techniques for keeping a key-value storage associated to a client and controlled by the server.

Different from a simple client-based storage (cookies, storage API):
- The client cannot insert/modify data without help from the server
- (optional) Stored data are not visible to the client.
Typically short-lived:
- Reduces risks associated to session hijacking/fixing.

Mechanics of a session system

The client connects for the first time:
- It is given a session identifier,
- the server sets up a storage associated to the identifier.
When the client visits again the site:
- It transmits the session identifier
- the server recovers the storage.

Session identifiers

Many possible channels (any techniques used for keeping the state on the client):

URL (query string, path)

https://www.example.com/home?sessid=a3423f344
https://www.example.com/a3423f344/home

Hidden forms

<input type="hidden" name="sessid" value="a3423f344">

Cookies (the most used one):
```
Cookie: sessid=a3423f344
```
Storage API (with AJAX).

Security: session identifiers must be ephemeral, random and hard to guess.

Storage by the server

Possible storage areas:
- volatile memory (RAM),
- temporary file,
- temporary database.
The server is the only one to see and modify data.
Potentially store large data (not recommended).
Default sessions system historically implemented in PHP (temporary file).
In Express:
- express-session (RAM, temporary database, …).
- …

Storage by the client

Leveraging the client local storage: cookies, storage API.
(Symmetric) cryptographic methods to guarantee
- Confidentiality → Encryption: the server is the only one able to see the data.
- Integrity → Signature (HMAC): the server is the only one able to create/modify data.
Session identifier = storage area.
Limited to small data.
The server must generate a random secret key, and never give it away.
In Express: cookie-session.

Express example

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

app.use(session( {
  secret : '12345',
  resave: false,
  saveUninitialized: false,
} ));

app.get('/welcome', function (req, res) {
  req.session.user = req.query.user;       // Store data in the session
  ...
});

app.get('/next', function (req, res) {
  if (req.session.user) {                  // Retrieve data from the session
    res.end('Hello ' + req.session.user);
  } else {
    res.redirect('/welcome');              // If data is absent, redirect to /welcome
  }
});

Sessions: pros/cons

Advantages

Transparent API, hides the protocol and implementation details.
Often faster than querying a DB.

Disadvantages

Uses more resources than a simple client-based storage.
Almost all implementations need the client to activate cookies.

Alternatives and complementary systems

Global storage for the application

Memory based key-value storages: Redis, …
Big table: Memcached, …

Security warnings

Never store unencrypted sensible data on the client: Never transmit them via the URL.
Always generate hard-to-guess session identifiers:: use random number generators and long strings, let identifiers depend on the HTTP(S) request.
Use an encrypted transport layer:: only use HTTPS for sensitive information (remember all personal information is sensitive).

An attacker with the ability to steal/fix session identifiers can acces all the user data.

Use short-lived sessions:: session cookies, identifiers, … must expire fast (or at least regularly).