Sessions Maintien d'état contrôlé par le serveur

Sessions

Sous le nom de sessions on regroupe plusieurs techniques pour la réalisation d’un stockage clef-valeur associé à un client mais contrôlé par le serveur.

  • Différent du simple stockage par le client (cookies, storage API) :

    • Le client ne peut pas insérer/modifier les données sans l’accord du serveur.

    • (optionnel) Les données ne sont pas visibles par le client.

  • En général de courte durée (minutes) :

    • Réduit les risques associés au vol/fixation de session,

Mécanique d’un système de session

  1. Le client se connecte pour la première fois :

    • Un identifiant de session lui est associé,
    • le stockage est mis en place.

  2. Le client visite à nouveau le site :

    • Il transmet l’identifiant de session
    • le serveur reconstruit le stockage à partir de l’identifiant.
CLIENT SERVER GET / ?id=a434ef id=a434ef Sess a434ef user: toto loggedin: yes likes: oranges

Identifiants de session

Plusieurs canaux possibles (toutes les techniques de maintien d’état) :

  • URL (query string, chemin)

    /home?sessid=a3423f344
/a3423f344/home

  • Formulaires cachés

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

  • Cookies (le plus courant) :

    Cookie: sessid=a3423f344

  • Storage API (avec AJAX).

Sécurité : les identifiants de session doivent être éphémères, aléatoires et difficiles à deviner.

Stockage par le serveur

  • Zones de stockage possibles

    • mémoire volatile (RAM),
    • fichier temporaire,
    • base de données temporaire.

  • Le serveur est le seul à voir et modifier les données.

  • Capable de stocker beaucoup de données (mais déconseillé).

  • Système de sessions par défaut en PHP et Silex (fichier temporaire).

  • En Express :

Stockage par le client

  • Utilisation du stockage local du client : cookies, storage API

  • Méthodes cryptographiques (symétriques) pour garantir

    • confidentialité → Chiffrement : le serveur est le seul à voir les données.

    • integrité → Signature (HMAC) : le serveur est le seul à pouvoir créer/modifier les données.

  • Identifiant de session = zone de stockage.

  • Limité à des données de petite taille.

  • Le serveur doit générer une clef secrète aléatoire et ne jamais le divulguer.

  • En Express : cookie-session.

Exemple en Silex

// Configuration
$app->register(new Silex\Provider\SessionServiceProvider());

$app->get('/welcome',
  function(Application $app, Request $req) {
    // On stocke dans la session
    $app['session']->set('user', $req->query->get('name'));
    ...
});

$app->get('/next', function(Application $app) {
  // On cherche dans la session
  $u = $app['session']->get('user');
  if ($u) {
    return 'Hello ' . $u;
  } else {
    // Si user n'est pas défini, or rédirige sur /welcome
    return $app->redirect('/welcome');
  }
});

Exemple en Express

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

app.use(session( { secret : '12345' } ));

app.get('/welcome', function (req, res) {
  // On stocke dans la session
  req.session.user = req.query.user;
  ...
});

app.get('/next', function (req, res) {
  // On cherche dans la session
  if (req.session.user) {
    res.end('Hello ' + req.session.user);
  } else {
    // Si user n'est pas défini, or rédirige sur /welcome
    res.redirect('/welcome');
  }
});

Sessions : pour/contre

Avantages

  • API transparente, cache les détails du protocole et de l’implantation.
  • Souvent plus rapide qu’une interrogation d’une BD.

Désavantages

  • Utilise plus de ressources serveur qu’un simple stockage par le client.
  • Quasiment toutes les implantations nécessitent des cookies.

Alternatives et compléments

Systèmes de stockage global pour l’application

  • Clef-valeur en mémoire : Redis, …
  • Big table : Memcached, …

Rapples de sécurité

Ne pas stocker de données sensibles non chiffrées chez le client, ne pas les transmettre en clair par l’URL.

Générer des identifiants de session difficiles à deviner : utiliser des générateurs aléatoires et beaucoup de caractères, les faire dépendre de la requête HTTP(S).

Chiffrer les sessions critiques : transmettre exclusivement par HTTPS les informations sensibles.

Un attaquant qui peut voler/fixer un identifiant de session peut accéder à toutes les données de l’utilisateur.

Donner des durées de vie limitées : les cookies de session, les identifiants, … devraient périmer rapidement (ou régulièrement).

ET NE JAMAIS FAIRE CONFIANCE AU CLIENT !

Lectures

Documentations

Sécurité

Fork me on GitHub