Gestion de session : fixation, expiration, invalidation et token dans l'URL

La session est le mécanisme qui permet à une application de se souvenir qu'un utilisateur s'est authentifié. Elle prend généralement la forme d'un identifiant opaque stocké dans un cookie, transmis à chaque requête. Les erreurs de gestion de session ne se trouvent pas dans le token lui-même mais dans la façon dont il est créé, transmis, conservé et détruit. Un token parfaitement aléatoire peut quand même être volé si la session ne s'invalide jamais.

Fixation de session

La fixation de session est une attaque où l'attaquant impose un identifiant de session à la victime avant qu'elle s'authentifie. Le scénario classique : l'attaquant obtient un identifiant de session valide (en visitant le site lui-même), envoie à la victime un lien contenant cet identifiant, la victime clique, se connecte avec ses identifiants, et l'application ne régénère pas le token. L'attaquant, qui connaissait déjà le token, a maintenant accès à la session authentifiée.

Lien avec session fixée (token dans l'URL)

https://app.example.com/login?sessionid=abc123

# L'attaquant a préalablement visité le site avec ce sessionid.
# Si l'application l'accepte et ne régénère pas le token après authentification,
# l'attaquant peut utiliser ce même sessionid pour accéder à la session.

La correction est simple et non négociable : régénérer l'identifiant de session immédiatement après chaque authentification réussie. Le token qui existait avant la connexion doit être invalidé et remplacé par un nouveau. Toutes les bibliothèques de gestion de session sérieuses proposent une méthode pour ça.

Exemple PHP : régénération après authentification

// Après vérification des identifiants :
session_regenerate_id(true); // true = détruit l'ancienne session
$_SESSION['user_id'] = $user->id;
$_SESSION['authenticated'] = true;

Identifiant de session prévisible

Un token de session prévisible peut être deviné par force brute ou par inférence. Certaines applications génèrent leurs tokens à partir d'informations prévisibles : timestamp Unix, combinaison de l'ID utilisateur et d'un compteur, hash MD5 du nom d'utilisateur. Un attaquant qui comprend le schéma peut énumérer les tokens valides.

La règle : utiliser un générateur cryptographiquement sûr avec au moins 128 bits d'entropie. Ne jamais construire un token manuellement.

Génération sécurisée de token

// Node.js
const crypto = require('crypto');
const sessionToken = crypto.randomBytes(32).toString('hex'); // 256 bits

// Python
import secrets
session_token = secrets.token_hex(32)  # 256 bits

Token de session dans l'URL

Exposer le token de session dans l'URL est une erreur grave. Les URLs apparaissent dans les logs de serveur, les logs de proxy, l'historique du navigateur, l'en-tête HTTP Referer (envoyé aux sites tiers), les bookmarks et les emails. Un token dans l'URL est un token exposé à des dizaines de systèmes différents.

Token dans l'URL (à éviter absolument)

# Mauvaise pratique
https://app.example.com/dashboard?token=abc123xyz

# Quand l'utilisateur visite un lien externe depuis cette page,
# l'en-tête Referer contient l'URL complète avec le token :
Referer: https://app.example.com/dashboard?token=abc123xyz

Le token de session doit toujours transiter dans un cookie, jamais dans l'URL ni dans un en-tête de type Authorization stocké en localStorage (accessible à JavaScript).

Session non invalidée après déconnexion

Quand un utilisateur se déconnecte, la session doit être détruite côté serveur. Supprimer le cookie côté client sans invalider la session serveur ne suffit pas : si l'attaquant a intercepté le token (via XSS, log ou autre), il peut continuer à l'utiliser indéfiniment.

Déconnexion correcte (Node.js / express-session)

app.post('/logout', (req, res) => {
  req.session.destroy((err) => {  // Détruit la session côté serveur
    res.clearCookie('connect.sid'); // Supprime le cookie côté client
    res.redirect('/login');
  });
});

Durée de vie excessive

Une session qui ne expire jamais, ou qui expire après 30 jours, est une fenêtre d'exploitation permanente. Si le token est compromis (log, XSS, épaule-surfing), l'attaquant dispose d'un accès illimité dans le temps. La durée de vie doit être proportionnelle à la sensibilité de l'application.

La bonne pratique : durée absolue (ex. 8 heures) combinée à un timeout d'inactivité (ex. 30 minutes). Les deux indépendamment : un token peut rester valide 8 heures même si l'utilisateur ne fait rien, ou expirer après 30 minutes d'inactivité selon ce qui arrive en premier.

Récapitulatif

1. Régénérer le token après authentification : neutralise la fixation de session
2. Utiliser un générateur cryptographique : au moins 128 bits d'entropie, jamais construit manuellement
3. Transporter le token dans un cookie uniquement : jamais dans l'URL, jamais en localStorage
4. Invalider la session côté serveur à la déconnexion : supprimer le cookie ne suffit pas
5. Durée de vie raisonnée : durée absolue + timeout d'inactivité, adaptés à la sensibilité de l'application