Le vol de session consiste à s'emparer non pas d'un secret d'authentification, mais de la preuve d'authentification déjà accordée : cookie de session, jeton d'accès, jeton de rafraîchissement. Celui qui détient ce jeton agit au nom de l'utilisateur sans repasser par la moindre vérification — ni mot de passe, ni second facteur, ni biométrie. C'est la raison pour laquelle une MFA excellente peut coexister avec une compromission complète.
Pourquoi le jeton vaut plus que le mot de passe
Un mot de passe doit être présenté à un système qui va le contester : il déclenche un second facteur, une analyse de risque, éventuellement une alerte. Un jeton valide, lui, court-circuite tout cela : il est la conclusion d'une authentification que le service considère comme faite.
S'y ajoutent trois propriétés qui en font une cible de choix :
- Il est copiable. Contrairement à une clé privée stockée dans un élément sécurisé, un cookie est une valeur, donc exportable.
- Il est souvent durable. Un jeton de rafraîchissement peut rester valide plusieurs jours ou semaines, précisément pour éviter de gêner l'utilisateur.
- Il est rarement surveillé. Beaucoup d'organisations journalisent les authentifications et ignorent l'usage des sessions.
Les cinq voies de vol à connaître
| Voie | Mécanisme | Ce qui est capturé | Ce qui coupe l'accès |
|---|---|---|---|
| Proxy inverse (AiTM) | Relais de l'authentification en temps réel | Cookie de session émis à l'issue | Révocation de session |
| Dérobeur d'informations | Programme malveillant lisant le stockage du navigateur | Cookies, jetons, secrets enregistrés | Révocation + assainissement du poste |
| Extension de navigateur | Autorisation de lecture sur toutes les pages | Cookies, contenu des sessions actives | Retrait de l'extension + révocation |
| Faille applicative (XSS) | Injection de script dans une page de confiance | Jeton accessible au script | Correctif + invalidation globale |
| Consentement applicatif abusif | Application tierce autorisée par l'utilisateur | Jeton OAuth à durée longue | Retrait du consentement |
Ces voies ont un point commun : aucune ne suppose de casser la cryptographie. Elles récupèrent une valeur là où elle est stockée ou transportée.
Notons une conséquence contre-intuitive : les méthodes liées à l'origine, comme FIDO2/WebAuthn, résolvent le problème de la connexion — un faux domaine n'obtient rien d'exploitable — mais ne protègent pas ce qui est émis après. Le vol de session survit à la généralisation des passkeys.
Signaux de détection réellement exploitables
Un jeton volé ne produit pas d'événement d'authentification. La détection doit donc porter sur l'usage.
La rupture de contexte. Le jeton a été émis pour un poste, un système d'exploitation, une plage d'adresses. Il est utilisé depuis un autre. La comparaison entre le contexte d'émission et le contexte d'usage est le signal le plus fiable.
La géovélocité impossible. Deux usages du même jeton depuis des localisations incompatibles avec un déplacement physique.
L'origine d'hébergement. Une session bureautique utilisée depuis une infrastructure de serveurs plutôt que depuis un réseau d'accès résidentiel ou d'entreprise.
Les enchaînements post-accès. Création d'une règle de transfert de messagerie, enregistrement d'un nouveau facteur, génération d'un jeton d'API, export massif de données, changement de coordonnées bancaires. Pris isolément, chacun de ces gestes est légitime ; enchaînés dans les minutes qui suivent la première utilisation d'une session, ils constituent un motif d'intrusion.
L'absence de nouvelle authentification. Une session active depuis longtemps sans aucune réauthentification, sur un compte à privilèges, mérite une revue.
Contre-mesures, par ordre d'efficacité
- Savoir révoquer, vite. C'est le prérequis. Après un incident, changer le mot de passe ne ferme pas la session volée. La procédure doit permettre d'invalider l'ensemble des jetons d'un compte en quelques minutes, applications tierces comprises, et être testée hors incident.
- Réduire la durée de vie et la portée. Sessions courtes sur les périmètres sensibles, jetons de rafraîchissement limités, portée restreinte aux applications nécessaires. La question à se poser : « combien de temps un vol reste-t-il rentable ? »
- Lier la session au dispositif. Lorsque la plateforme le permet, associer le jeton à une clé détenue par le poste rend une copie inutilisable ailleurs. C'est la mesure structurelle la plus proche d'une solution.
- Réauthentifier au moment de l'action. Une session n'est pas une autorisation permanente. Virement, modification d'IBAN, création d'un compte à privilèges, export de base : ces opérations doivent exiger une preuve fraîche. Une session volée cesse alors de suffire.
- Contrôler ce qui tourne sur le poste. Les dérobeurs d'informations et les extensions malveillantes constituent la voie d'entrée la plus banale. Restreindre l'installation d'extensions et détecter les exécutions suspectes reste indispensable.
- Faire varier ce que l'attaquant observe. Une exécution mouvante (Moving Target Defense), où les paramètres changent en continu, prive le rejeu de sa cible stable.
Les points 3 et 4 dessinent la seule sortie durable : cesser de traiter l'authentification comme un événement d'entrée, et la rattacher aux actes. C'est la logique de l'authentification cognitive, qui demande une preuve d'intention humaine au moment de l'opération, dans un canal éphémère, sans secret réutilisable.
Réagir à un vol de session avéré
Dans l'ordre : révoquer toutes les sessions et jetons du compte ; inventorier les facteurs enrôlés et retirer ceux qui ne sont pas reconnus ; examiner les règles de messagerie, délégations et consentements applicatifs créés ; rechercher les actions à effet financier ou contractuel réalisées pendant la fenêtre d'exposition ; puis seulement traiter le poste et les identifiants. Inverser cet ordre laisse à l'attaquant le temps de rétablir son accès.
FAQ
Les passkeys protègent-elles du vol de session ?
Elles protègent la phase de connexion grâce à la liaison à l'origine, mais pas la session émise ensuite. Un cookie volé après une authentification par passkey reste exploitable tant qu'il n'est pas révoqué ou lié au dispositif.
Comment savoir si une session en cours est légitime ?
En comparant systématiquement le contexte d'émission et le contexte d'usage. Une session est suspecte quand son environnement change sans nouvelle authentification : adresse, empreinte du client, type de réseau, ou volume d'accès sans rapport avec l'usage habituel.
Des sessions plus courtes suffisent-elles ?
Elles réduisent la fenêtre d'exploitation, ce qui est utile, mais un attaquant automatisé agit en quelques minutes. La durée seule ne protège pas : elle doit s'accompagner d'une réauthentification sur les actions sensibles.
Le VPN ou le filtrage d'adresses règle-t-il le problème ?
Partiellement, en compliquant l'usage d'un jeton depuis l'extérieur. Mais un jeton volé sur un poste interne, par un dérobeur d'informations, sera utilisé depuis un contexte apparemment conforme. Le filtrage réseau est une couche, pas une réponse.
Aller plus loin : le 4ᵉ facteur cognitif · MFA résistante au phishing · Moving Target Defense et session hijacking · authentification transactionnelle