Gestion de session et cookies : les attributs de sécurité

Le protocole HTTP ne garde aucun souvenir : chaque requête est indépendante. Comment une application sait-elle alors que vous êtes toujours connecté après avoir saisi votre mot de passe ? Grâce à un identifiant de session, transporté dans un cookie. C’est un peu le bracelet d’un festival : une fois que vous l’avez au poignet, on ne vous redemande plus votre billet. Qui vole le bracelet entre à votre place. Cette leçon explique comment on protège ce bracelet et comment on vérifie qu’il l’est.

Le cycle de vie d’une session

1. Vous vous authentifiez avec succès.
2. Le serveur crée une session et vous envoie un identifiant, dans l’en-tête de réponse Set-Cookie.
3. Votre navigateur renvoie ce cookie à chaque requête vers ce site.
4. Le serveur retrouve votre session grâce à lui et sait « qui vous êtes ».
5. À la déconnexion ou à l’expiration, la session doit être détruite côté serveur.

Chaque étape peut être mal réalisée. L’auditeur les passe en revue.

Les attributs d’un cookie de session

Un cookie peut porter des attributs qui limitent son usage. Voici ceux qui comptent pour la sécurité, expliqués en détail dans la documentation de référence du web (developer.mozilla.org) :

Un en-tête bien configuré ressemble à ceci :

Set-Cookie: session=VALEUR_OPAQUE; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600

Vous le verrez dans l’historique de votre proxy, ou dans les outils de développement du navigateur, onglet de stockage ou réseau.

Qualités de l’identifiant lui-même

Le cookie de session doit être :

• Long et imprévisible : produit par un générateur aléatoire de qualité cryptographique. Un identifiant qui ressemble à un compteur (1001, 1002…) ou qui contient le nom d’utilisateur est un constat sérieux.
• Opaque : il ne doit pas encoder en clair des informations comme le rôle (« role=admin ») que le serveur croirait sans vérifier.
• Renouvelé à la connexion : voir la fixation de session ci-dessous.

La fixation de session

Imaginez qu’un hôtel donne à chaque client une carte-clé déjà programmée, et que quelqu’un connaisse le numéro de la carte avant que vous la receviez. Une fois que vous avez validé votre arrivée, cette personne a elle aussi accès à votre chambre. C’est le principe de la fixation de session : si l’application conserve le même identifiant de session avant et après l’authentification, un identifiant connu à l’avance devient un laissez-passer.

La contre-mesure est simple : régénérer l’identifiant de session à chaque changement de niveau de privilège (connexion, élévation de droits). Le test : notez la valeur du cookie avant connexion, connectez-vous, regardez si elle a changé. Si elle est identique, c’est un constat.

Déconnexion et expiration

Une application peut afficher « Vous êtes déconnecté » et laisser la session valide côté serveur. Le test est simple :

1. Connectez-vous et copiez la valeur du cookie.
2. Déconnectez-vous via le bouton prévu.
3. Rejouez, avec le module de rejeu du proxy, une requête réservée aux connectés en y remettant l’ancien cookie.
4. Si elle est acceptée, la session n’a pas été invalidée côté serveur.

De même, vérifiez l’expiration après inactivité : une session ouverte pendant des jours sur un ordinateur partagé est un risque pour l’utilisateur.

Cookies et transport

Le cookie ne doit jamais circuler sur une connexion non chiffrée. Au-delà de l’attribut Secure, l’application doit rediriger tout le trafic vers HTTPS et envoyer un en-tête indiquant au navigateur de n’utiliser que HTTPS (nous le reverrons avec les en-têtes de sécurité, au chapitre 4). Quand vous auditez, vérifiez ce qui se passe si vous demandez la page en HTTP simple.

Jetons côté client : un mot sur les JWT

Certaines applications remplacent la session serveur par un jeton signé (souvent au format JWT) stocké côté client. Les points de contrôle sont voisins : la signature est-elle vérifiée par le serveur ? Le jeton a-t-il une durée de vie courte ? Peut-on le révoquer ? Contient-il des informations sensibles lisibles par n’importe qui (le contenu est encodé, pas chiffré) ? Un jeton accepté sans vérification de signature est une faille grave. Ici, retenez le principe : le serveur ne doit jamais faire confiance à ce que le client peut modifier.

À vous de jouer

Dans votre application d’entraînement :

1. Connectez-vous et relevez dans l’historique de votre proxy l’en-tête Set-Cookie de la réponse de connexion.
2. Remplissez le tableau : Secure, HttpOnly, SameSite, durée de vie — présents ou absents ?
3. Comparez la valeur du cookie avant et après la connexion.
4. Testez la déconnexion en rejouant une requête avec l’ancien cookie.
5. Consignez au carnet au moins deux constats avec leur correction suggérée.

Reste un maillon sensible de l’authentification : que se passe-t-il quand on a oublié son mot de passe ? C’est la leçon suivante.