Cookie de session
Sécurité
Petite donnée qu'un serveur web dépose dans le navigateur, en général après la connexion, et qui contient un identifiant aléatoire renvoyé automatiquement à chaque requête. HTTP n'ayant aucune mémoire d'une requête à l'autre, c'est ce cookie qui permet au serveur de reconnaître l'utilisateur sans redemander son mot de passe.
Ce qu'il contient : Un identifiant de session long, aléatoire et opaque, rien de plus : l'état réel (utilisateur, droits, panier) reste côté serveur, dans un magasin de sessions. Y glisser un rôle ou un identifiant utilisateur en clair revient à laisser le client décider de qui il est.
Durée de vie : Au sens strict, un cookie de session n'a ni Expires ni Max-Age et disparaît à la fermeture du navigateur, sauf quand celui-ci restaure les onglets et le garde au passage. La vraie limite doit donc être appliquée côté serveur, avec une expiration d'inactivité et une expiration absolue.
Attributs de protection : HttpOnly empêche le JavaScript de la page de le lire, Secure le réserve à HTTPS, SameSite limite son envoi depuis d'autres sites et réduit la surface CSRF. Le préfixe __Host- interdit en plus qu'un sous-domaine vienne l'écraser.
Vol et fixation : Un cookie de session volé n'a pas besoin du mot de passe : il est déjà la preuve qu'on l'a tapé, ce qui rend l'authentification multifacteur très décorative après coup. D'où la règle : régénérer l'identifiant à la connexion et à chaque changement de privilège, puis l'invalider côté serveur à la déconnexion.
Ce qui arrive si on s'en passe
Sans cookie de session, HTTP ne garde aucun lien entre deux requêtes : le serveur ne peut plus reconnaître un utilisateur déjà authentifié. Il ne reste alors que deux voies. Dans la première, le mot de passe est renvoyé à chaque requête (c'est le cas de l'authentification HTTP Basic). Il circule donc en permanence sur le réseau et à travers les proxys, et le navigateur le garde en mémoire, sans déconnexion réelle possible côté serveur. Dans la seconde, l'identifiant de session passe dans l'URL. Il fuit alors par l'en-tête Referer, l'historique, les journaux des serveurs et les liens partagés, et quiconque le récupère reprend la session. Dans les deux cas, le serveur perd aussi des moyens de contrôle : sans identifiant de session distinct, il ne peut ni invalider une session précise, ni limiter sa durée, ni rattacher une action à une connexion donnée dans ses journaux.
Explication de la marmotte
Quand tu te connectes à un site, il vérifie ton mot de passe une seule fois. Ensuite, il te remet une sorte de ticket, comme le ticket du vestiaire au théâtre : juste un numéro, sans ton nom dessus. Ton navigateur (le programme qui affiche les sites) garde ce ticket et le montre à chaque nouvelle page. Le site regarde dans son registre à quoi correspond ce numéro et sait que c'est toi, sans te redemander ton mot de passe. Le revers : quelqu'un qui vole ce ticket peut se faire passer pour toi jusqu'à ce qu'il ne soit plus valable. C'est pour ça qu'il faut se déconnecter sur un ordinateur partagé.
Où ce terme est utilisé
- Attributs du cookie de session (9 occurrences)
- Cloudbleed 2017 : fuite mémoire d'un proxy TLS mutualisé (3 occurrences)
- La clé de cache HTTP : pourquoi deux requêtes identiques ne le sont pas (3 occurrences)
- POODLE CVE-2014-3566 oracle de padding SSL 3.0 (3 occurrences)
- Attaque cache deception CDN et contre-mesures (2 occurrences)
- Comment empêcher une attaque de fixation de session (2 occurrences)
- Désérialisation non sécurisée et chaîne de gadgets (2 occurrences)
- La politique de même origine : ce que le navigateur cloisonne vraiment (2 occurrences)
- TA0006 Accès aux identifiants : voler plutôt que forcer (2 occurrences)
- Attaque MIME sniffing par fichier téléversé (1 occurrence)