Aller au contenu
TortueTech
RubriquesGlossaire

Session

Sécurité

État qu'un serveur maintient pour un même client d'une requête à la suivante, matérialisé par un identifiant que le client présente à chaque appel. Elle donne de la mémoire à des protocoles qui n'en ont aucune, HTTP en tête.

Diagramme de séquence entre trois acteurs : Client, Serveur et Stockage de sessions. 1, le client envoie son identifiant et son mot de passe au serveur ; 2, le serveur crée la session dans le stockage de sessions ; 3, le serveur renvoie au client un identifiant de session dans un cookie ; 4, le client envoie une requête accompagnée du cookie ; 5, le serveur vérifie l'identifiant auprès du stockage de sessions ; 6, si la session est valide, le serveur renvoie la réponse, sinon il renvoie le client à la connexion.

Pourquoi ça existe : HTTP est sans état : chaque requête arrive seule, sans souvenir de la précédente. La session recolle les morceaux : on s'authentifie une fois, puis le serveur reconnaît l'identifiant à chaque requête suivante.

État côté serveur ou côté client : Soit l'état vit côté serveur (mémoire, base, cache) et le client ne porte qu'un identifiant opaque ; soit il voyage dans un jeton signé comme un JWT, qui allège le serveur et le prive du moyen de dire non avant l'expiration, sauf à tenir une liste de révocation (c'est-à-dire à remettre côté serveur l'état qu'on venait tout juste d'en sortir).

Durée de vie et révocation : Une session se borne par une expiration d'inactivité, une durée absolue et une invalidation explicite à la déconnexion. Le bouton « Se déconnecter » efface souvent le cookie du navigateur et rien d'autre : côté serveur, la session coule alors des jours paisibles jusqu'à sa retraite naturelle.

Le mot ne sert pas qu'au web : Une session TLS désigne l'état cryptographique d'une connexion, que la reprise de session permet de retrouver sans refaire toute la poignée de main ; une session SSH, le canal ouvert après authentification ; et sur un module matériel, une application ouvre une session PKCS#11 (C_OpenSession) avant de pouvoir se connecter au jeton et utiliser ses clés. Même idée partout : un état nommé, borné dans le temps, qu'on referme (ou qu'on oublie de refermer).

Attaques et parades : Un identifiant volé (XSS, réseau non chiffré) ou imposé avant la connexion (fixation) suffit à usurper l'utilisateur. Parades de base : régénérer l'identifiant après authentification, cookies HttpOnly, Secure et SameSite, transport sous TLS.

Voir aussi :CookieJWTTLSCSRFAuthentification

Ce qui arrive si on s'en passe

Sans session, le serveur traite chaque requête HTTP comme isolée et ne peut pas relier un appel au précédent. Il reste alors deux options. La première consiste à exiger les identifiants complets à chaque requête, ce qui multiplie les occasions de les intercepter ou de les écrire par erreur dans les journaux. La seconde consiste à confier l'état au client, qui peut le modifier librement si rien ne le signe ni ne le vérifie côté serveur. Le serveur perd aussi tout point de contrôle pour mettre fin à un accès : pas de déconnexion effective, pas de révocation après un changement de mot de passe, pas d'expiration après une période d'inactivité. Dans les journaux, les actions ne se rattachent plus à un parcours identifié. Il devient alors impossible de reconstituer une séquence suspecte ou de limiter le débit pour chaque client.

Explication de la marmotte

Imagine un festival de musique. À l'entrée, tu montres ton billet une seule fois et on t'attache un bracelet au poignet. Ensuite, pour entrer dans chaque concert, pas besoin de tout remontrer : le bracelet prouve que tu as déjà été contrôlé. Sur un site web, c'est pareil. Quand tu te connectes avec ton mot de passe, le site te remet une sorte de bracelet invisible que ton navigateur garde et présente à chaque clic. Ce bracelet finit par expirer au bout d'un moment, ou quand tu te déconnectes. Et si quelqu'un te le vole, il peut entrer à ta place : c'est pour ça qu'il faut bien le protéger.

Où ce terme est utilisé

← Tout le glossaire