Le vol de session est l'attaque qui rend une bonne authentification insuffisante : l'attaquant ne cherche pas à franchir le contrôle, il arrive après. Muni d'un jeton valide, il agit avec les droits de la victime sans fournir le moindre facteur. C'est aujourd'hui le point aveugle commun aux passkeys, aux clés physiques et à toutes les MFA correctement déployées.
Trois chemins vers un jeton valide
| Chemin | Comment il opère | Ce qui le rend possible |
|---|---|---|
| Proxy inverse (AiTM) | capture le cookie émis juste après l'authentification | la session est émise avant tout contrôle d'usage |
| Logiciel voleur d'informations | extrait cookies et jetons du poste ou du navigateur | le jeton est stocké côté client |
| Extension ou composant tiers | lit le contexte de navigation | la surface du navigateur est large |
Un quatrième chemin, plus discret, mérite d'être cité : les jetons de rafraîchissement, qui prolongent silencieusement une session bien au-delà de la durée affichée dans la politique de sécurité. Beaucoup d'organisations découvrent en incident que leurs sessions « de huit heures » duraient en pratique bien davantage.
Pourquoi raccourcir les sessions ne règle pas le problème
C'est la première réaction, et elle est saine — mais elle bute sur une arithmétique simple.
- L'exploitation est rapide. Le temps utile à l'attaquant pour exfiltrer, modifier un paramètre sensible ou créer un accès de persistance se compte en minutes, pas en heures.
- La friction remonte. Des sessions très courtes multiplient les réauthentifications, ce qui fabrique l'automatisme que les attaques d'approbation exploitent.
- La persistance survit à la session. Une fois à l'intérieur, l'attaquant crée souvent un accès propre — clé d'interface, compte de service, règle de transfert. Expirer la session n'y change rien.
Raccourcir reste nécessaire. Ce n'est simplement pas suffisant, parce que le problème n'est pas la durée de la confiance mais le fait qu'elle soit accordée en bloc.
Deux leviers : rendre l'observation inutile, et rompre la confiance implicite
Le Moving Target Defense
Le Moving Target Defense fait varier en continu les paramètres d'exécution. L'effet visé sur ce scénario est précis : ce qu'un observateur apprend d'un échange se périme, et il ne peut pas construire par accumulation une compréhension stable du fonctionnement à détourner. Associé au polymorphisme fonctionnel, il vise à rendre l'attaque non capitalisable — l'attaquant doit refaire son travail à chaque fois au lieu d'industrialiser.
La validation au niveau de l'action
C'est le levier décisif. Plutôt que d'authentifier une fois puis de faire confiance, on exige une preuve au moment de l'opération sensible : virement, changement de coordonnées bancaires, élévation de privilèges, export massif, modification d'un moyen de récupération.
Un jeton volé permet alors d'ouvrir une session ; il ne permet pas d'exécuter ces opérations, parce que celles-ci demandent la résolution d'un challenge cognitif, c'est-à-dire l'application d'une méthode personnelle qui n'a jamais transité et ne se trouve pas dans un cookie.
Cette approche s'inscrit dans la logique du NIST SP 800-207 : « ne jamais faire confiance, toujours vérifier ». La formule est souvent citée pour justifier des contrôles réseau ; elle s'applique tout autant à la confiance qu'on accorde à une session déjà établie.
Le score de risque comme déclencheur
Entre « tout autoriser » et « tout redemander », il existe une voie intermédiaire. Un score de risque contextuel compare les caractéristiques de l'usage à celles de l'authentification initiale : changement d'adresse réseau en cours de session, agent utilisateur incohérent, activité depuis une infrastructure d'hébergement, rythme d'actions inhabituel. Une divergence n'établit pas un vol de session, mais elle justifie d'élever l'exigence sur l'action en cours plutôt que de couper l'accès et de générer un incident de support. C'est ce couplage — détection contextuelle d'un côté, preuve d'intention de l'autre — qui rend la mesure supportable à l'échelle d'une organisation.
Un plan en cinq points
- Inventorier les actions à fort impact. Elles sont peu nombreuses et suffisent à définir le périmètre de la validation renforcée.
- Réduire la durée de vie effective, jetons de rafraîchissement compris, et vérifier l'écart entre politique affichée et réalité.
- Vérifier la révocation. Savoir invalider un jeton en quelques minutes, et l'avoir testé.
- Lier la session à des signaux contextuels — terminal, réseau, comportement — via un score de risque, pour élever l'exigence en cas d'incohérence.
- Ajouter une validation d'intention sur les actions inventoriées, en overlay de la chaîne existante.
Ce plan a l'avantage de ne dépendre d'aucun remplacement d'IdP : les quatre premiers points relèvent de la configuration, le cinquième d'un ajout.
FAQ
Les passkeys protègent-elles du vol de session ?
Elles protègent la connexion grâce à la liaison à l'origine, ce qui empêche le relais des identifiants. Elles ne disent rien du jeton émis ensuite : une fois la session ouverte, le mécanisme d'authentification n'intervient plus.
Comment détecter une session détournée ?
Par les incohérences entre l'authentification et l'usage : changement d'adresse IP ou d'agent en cours de session, géovélocité impossible, activité depuis une infrastructure d'hébergement, enchaînement rapide avec une modification de paramètre sensible.
La réauthentification systématique n'est-elle pas plus simple ?
Elle déplace le risque vers la fatigue d'approbation. Une exigence ciblée sur les actions à fort impact obtient un meilleur résultat qu'une exigence uniforme que les utilisateurs finissent par traiter mécaniquement.
Le facteur cognitif se déploie-t-il sans refonte ?
Il peut s'ajouter en overlay d'une MFA existante, ce qui permet de couvrir d'abord les opérations sensibles et les comptes à privilèges avant d'envisager un parcours complet.
Aller plus loin : le 4ᵉ facteur cognitif · vol de session et token theft · l'authentification transactionnelle · le MTD face au rejeu