Fixation de session

Qu'est-ce que Fixation de session?

La fixation et le détournement diffèrent selon le moment où l'attaquant obtient l'identifiant de session. Un pirate de l’air le vole après votre authentification. La fixation plante une valeur connue auparavant et permet à votre propre connexion de la mettre à niveau. Vous épinglerez un identifiant anonyme en direct dans un lien, regarderez la victime se connecter et chargerez son tableau de bord avec cette même chaîne. Le gestionnaire lit const sid = req.cookies.sid || crypto.randomUUID() . Le correctif crée un nouvel identifiant sans condition à chaque transition d'authentification et de privilèges, c'est pourquoi l'entropie et HttpOnly ne ferment pas celui-ci.

Ce que vous apprendrez dans Fixation de session

• Distinguer la fixation de session du détournement de session selon le moment où l'identifiant est en possession de l'attaquant (avant la connexion ou après)
• Reconnaître que toute primitive d'écriture de cookie (sous-domaine XSS, MITM, fractionnement de réponse) est suffisante pour permettre la fixation
• Appliquer une rotation inconditionnelle des identifiants de session à chaque authentification réussie (et à chaque transition de privilèges)
• Associez la rotation à la suppression explicite de l'identifiant de session de pré-connexion afin que l'ancienne liaison ne puisse pas continuer côté serveur
• Auditez chaque transition d'état d'authentification pour le même hook de rotation (connexion, post-MFA, élévation de rôle, changement de mot de passe)

Fixation de session — Étapes de la formation

1. Le plan de Bob

   Bob ne peut pas voler le mot de passe d'Alice, et il n'en a pas besoin. Son plan est de lui donner un identifiant de session qu'il connaît déjà, puis de la laisser se connecter par-dessus, de sorte que la session sur laquelle elle finit authentifiée soit celle qu'il contrôle. Il a d’abord besoin d’un identifiant de session pour planter. Il ouvre lui-même le portail Sundermark Logistics, et cet ancien portail transmet à son navigateur un identifiant de session anonyme et le renvoie directement dans la barre d'adresse sous la forme d'une valeur ?sid , exactement comme n'importe quel visiteur.

2. Un identifiant de session valide à planter

   Bob ouvre l'inspecteur de cookies du navigateur. Le portail lui a déjà remis un identifiant de session, avant qu'il ne se connecte ou fasse quoi que ce soit. C'est anonyme, mais c'est une valeur réelle que le serveur a émise et qu'il honorera. C'est l'identité exacte qu'il va implanter sur Alice.

3. Armez-le dans un lien

   Bob n'a rien à construire. L'identifiant de session que le serveur lui a donné est déjà épinglé à l'adresse ?sid=SID-9F3A2B1C7D , et le portail a une particularité héritée : il copie ce sid directement à partir de l'URL dans le cookie du visiteur. Ce lien précis est donc le piège. Toute personne à qui Bob l'envoie voit son identifiant de session inséré dans son cookie au moment où il l'ouvre.

4. Envoyez le piège à Alice

   Bob cible Alice, une employée dont il veut le compte sur le portail. Il ouvre son courrier électronique et lui écrit un message présenté comme un avis d'accès informatique de routine, portant le même lien d'identification de session dans le corps. Tout ce dont il a besoin, c'est qu'elle l'ouvre et se connecte.

5. Un avis d’accès de routine

   En dehors des heures de bureau, Alice reçoit un e-mail qui ressemble à un message d'entretien informatique : confirmez l'accès à votre portail avant la fin de la journée. Le lien pointe vers le vrai portail, donc rien ne saute aux yeux.

6. Un clic remet le cookie

   Alice clique sur le lien. Il ouvre la véritable page de connexion au portail, exactement comme prévu. Ce qu'elle ne peut pas voir : le portail vient de copier le sid du lien dans son pot à cookies. Son navigateur contient désormais l'identifiant de session de Bob.

7. Alice se connecte

   Alice se connecte avec ses informations d'identification Sundermark, tout comme l'avis le demande. Le portail l'accueille et la dépose sur son tableau de bord. Rien ne semble faux. Son compte, ses coordonnées, sa séance.

8. L'identifiant qui aurait dû changer

   Voici le défaut, rendu visible. Une connexion sécurisée génère un tout nouvel identifiant de session au moment où vous vous authentifiez, de sorte que l'identifiant que vous avez transporté est jeté. L'identité d'Alice n'a pas changé. Le cookie sur son tableau de bord authentifié représente, octet par octet, la valeur qui figurait sur le lien envoyé par courrier électronique, la valeur que Bob a plantée.

9. Bob actualise son compte

   Bob a toujours la page de connexion ouverte dans son navigateur, celle qu'il a chargée avec son identifiant de session planté. Une minute après qu'Alice se soit connectée, il l'actualise simplement. Son identifiant implanté est désormais lié à sa session authentifiée, de sorte que le portail traite sa demande comme la sienne et le renvoie directement à son tableau de bord. Pas de mot de passe, pas de vol, pas de malware.

10. Nommez ce qui s'est passé

    Avant qu'Alice ne passe de victime à ingénieur, soyez précis sur l'attaque.