En bref : rejeu de jeton de session apres authentification entre appareils
- La faille: Chaque pitch traite le MFA comme la ligne d'arrivee. Le vol de cookies leve le bluff. Le MFA authentifie l'evenement de login, et un cookie de session vole est le recu prouvant que le login a eu lieu, donc le serveur remet le compte sans nouvelle demande.
- Les preuves: SpyCloud a recupere plus de 17 milliards d'enregistrements de credentials voles dans le milieu criminel en 2024, et DBSC ne couvre que Chrome 146+ sur Windows. cside empreinte les appareils avec plus de 250 signaux a 99,7% de precision pour attraper le moment ou un cookie est rejoue depuis la mauvaise machine.
- La décision: Toute equipe qui compte sur MFA plus HttpOnly pour proteger des sessions vivantes est exposee. Ajoutez ce trimestre la surveillance runtime des scripts pour l'exfiltration de tokens et le scoring comportemental au niveau appareil, avant qu'une vente d'infostealer sur Telegram devienne votre incident.
Peu de temps ? Découvrez la détection de prise de contrôle de compte de cside. Elle couvre tout ce qui suit en un seul déploiement.
Le vol de cookies se produit lorsqu'un attaquant capture le token de session qu'un site web a émis après la connexion d'un utilisateur et le rejoue depuis un appareil différent. L'attaquant hérite de l'accès de l'utilisateur sans connaître son mot de passe. Aucune invite MFA ne se déclenche. L'utilisateur reste connecté et ne remarque rien ; les deux sessions fonctionnent en parallèle.
La raison pour laquelle le MFA n'arrête pas cela est structurelle. Le MFA authentifie l'utilisateur lors de l'événement de connexion. Après la connexion, le serveur s'appuie sur le cookie de session, une accréditation à durée limitée prouvant que le navigateur a déjà passé l'authentification. Un cookie volé est la preuve que le navigateur l'a déjà passée. Le serveur ne peut pas distinguer l'utilisateur réel de l'attaquant à moins de vérifier quelque chose au-delà du token lui-même.
Les chercheurs en sécurité appellent cela une attaque pass-the-cookie. C'est la technique dominante derrière une grande part des prises de contrôle de comptes en 2026.
Comment fonctionne le détournement de session
La chaîne d'attaque est la même quelle que soit la manière dont le cookie a été obtenu.
- L'utilisateur s'authentifie. Le navigateur termine la connexion et le MFA. Le serveur émet un cookie de session, une longue chaîne aléatoire, et le renvoie avec la réponse.
- L'attaquant capture le cookie. Cela se produit via un malware infostealer, un proxy de phishing ou un script malveillant s'exécutant dans la page.
- L'attaquant rejoue le cookie. Depuis son propre navigateur ou un script, il définit le cookie volé et envoie une requête au site cible.
- Le serveur voit une session valide. Le cookie est actif et a été émis à un utilisateur authentifié. L'accès est accordé.
La session légitime reste ouverte. L'utilisateur navigue toujours sur son appareil ; l'attaquant navigue sur le même compte sur le sien.
Trois façons dont les attaquants volent les tokens de session
Malware infostealer
Le malware infostealer est la voie la plus courante. Des familles comme Lumma, Vidar et RedLine balaient le dépôt de cookies sur disque du navigateur, extraient les tokens de session de centaines de sites et les transmettent à un serveur contrôlé par l'attaquant en quelques minutes d'infection. Le Rapport Annuel 2025 d'Exposition des Identités de SpyCloud a récupéré plus de 17 milliards de paires d'identifiants volés du milieu criminel en 2024. Les cookies de session volés atteignent les marchés Telegram dans les heures suivant une infection réussie.
Le dépôt de cookies du navigateur est un fichier local, en texte brut ou une base de données SQLite locale. Tout processus s'exécutant avec les privilèges de l'utilisateur peut le lire. Les infostealers n'interceptent pas le trafic réseau ; ils lisent depuis le disque après que le navigateur a déjà déchiffré les données.
Phishing adversaire-au-milieu (AiTM)
Le phishing AiTM place un proxy inverse entre la victime et la vraie page de connexion. La victime voit une copie visuelle exacte de la connexion, saisit ses identifiants et complète le MFA. Le proxy transmet tout au vrai site et capture le cookie de session résultant au retour. L'attaquant détient maintenant un token post-authentification valide sans avoir passé le MFA lui-même.
Cette technique contourne les contrôles anti-phishing traditionnels car la page paraît authentique, l'invite MFA se complète contre le vrai service et la victime se connecte normalement. Seul le proxy de l'attaquant se trouve au milieu, invisible.
Scripts tiers malveillants et XSS
Une vulnérabilité XSS ou un script tiers compromis peut extraire les tokens de session du navigateur à l'exécution. JavaScript s'exécutant dans le contexte d'origine de la page peut lire les cookies non marqués HttpOnly, les encoder et les exfiltrer dans des requêtes qui ressemblent à des appels d'analyse routiniers.
C'est le vecteur de la chaîne d'approvisionnement côté client : l'attaquant ne cible pas directement votre site mais compromet une balise d'analyse, un widget de chat ou une bibliothèque de paiement en laquelle votre site a confiance et qu'il charge sur chaque page. Le skimmer arrive dans du code que le site considère déjà sûr.
Pourquoi les défenses standard ratent cela
L'attribut HttpOnly
HttpOnly empêche JavaScript de lire le cookie via document.cookie. Cela bloque les lectures de tokens XSS pour ce cookie spécifique, ce qui importe. Mais cela ne fait rien contre le malware infostealer qui lit le cookie directement depuis le disque après que le navigateur l'a stocké, et ne protège pas contre un proxy AiTM capturant le token sur le réseau avant qu'il n'atteigne le dépôt protégé.
HTTPS et TLS
TLS chiffre le trafic en transit et arrête l'écoute passive du réseau. Les infostealers lisent depuis le disque, après le déchiffrement. Les proxies AiTM terminent TLS des deux côtés de la connexion. Aucun des deux n'est arrêté par le seul chiffrement du transport.
MFA
Le MFA vérifie l'utilisateur lors de la connexion. Après la connexion, le serveur s'appuie uniquement sur le cookie. Un cookie volé ne déclenche jamais une autre invite MFA à moins que le serveur ne force la réauthentification basée sur des signaux d'appareil ou comportementaux, ce que la plupart des serveurs ne font pas à chaque requête.
Sessions liées à un appareil et DBSC
La correction structurelle pour les attaques pass-the-cookie est de lier la session au matériel qui l'a créée. Un cookie volé devient inutile si le serveur exige une preuve cryptographique que le navigateur contrôle toujours une clé privée spécifique détenue par l'appareil.
Le protocole Device Bound Session Credentials (DBSC) de Google fait cela en utilisant le TPM ou le Secure Enclave de l'appareil. Sur Chrome 146+ pour Windows, le navigateur génère une clé privée dans le matériel lors de l'établissement de la session. Les cookies de session de courte durée ne sont émis que tant que le navigateur peut prouver la possession de cette clé. Un attaquant qui vole le cookie depuis un autre appareil ne peut pas le renouveler sans la clé privée.
Les limites pratiques à mi-2026 :
- Couverture : Chrome 146+ sur Windows est le déploiement principal. iOS, Firefox et Safari ne supportent pas encore DBSC.
- Chemins de repli : en l'absence de TPM ou lors d'une erreur réseau pendant la vérification de la clé, DBSC peut ignorer la liaison. Cette session se comporte alors comme un cookie conventionnel.
- Malware sur le même appareil : si un infostealer s'exécute sur la même machine qui détient la clé privée, l'attaquant peut utiliser la session depuis cet appareil. DBSC traite le rejeu hors appareil, pas le compromis sur le même appareil.
Ces lacunes font de DBSC une couche, pas une solution complète.
Liste de vérification pour prévenir le détournement de session
| Contrôle | Ce qu'il arrête |
|---|---|
| TLS + HSTS | Écoute réseau (session sidejacking) |
| Attributs HttpOnly, Secure, SameSite | Lectures XSS via document.cookie |
| Rotation de l'ID de session après connexion | Fixation de session |
| Délais d'expiration absolus et d'inactivité courts | Fenêtre de rejeu après vol |
| Tokens de session aléatoires longs | Devinette de tokens |
| Révocation côté serveur lors de la déconnexion | Sessions actives après action de compte |
| DBSC (Chrome 146+ / Windows) | Rejeu hors appareil de cookie volé |
| Surveillance des scripts côté client | Exfiltration de tokens via XSS ou chaîne d'approvisionnement |
| Intelligence d'appareil + scoring comportemental | Token rejoué atteignant la session active |
Aucun contrôle individuel n'est complet. Les infostealers contournent les contrôles de transport. Les proxies AiTM contournent le MFA et HTTPS au niveau de la session. HttpOnly limite un vecteur de lecture JavaScript mais pas les lectures depuis le disque. Le modèle en couches fonctionne car chaque contrôle contourne ce que les autres ne peuvent pas faire.
Détecter une session détournée dans le navigateur en direct
La prévention réduit la probabilité de vol de tokens. La détection capture la session qui a déjà été volée et est en train d'être rejouée.
cside fonctionne comme un unique snippet JavaScript propriétaire dans le navigateur du visiteur sans proxy ni modification DNS. Il surveille ce que les scripts tiers et la session elle-même font réellement sur la page en direct pour des utilisateurs réels, pas ce qu'un crawler ou scanner observe sur le code au repos.
Exfiltration de tokens à la source. Un script tiers qui attache des écouteurs d'événements inattendus aux champs de formulaire, lit les valeurs de cookies en dehors des appels d'analyse normaux ou envoie des données à un domaine inconnu déclenche un signal de détection avant que le token ne quitte la page. Cela ferme le vecteur XSS et de chaîne d'approvisionnement avant qu'un cookie ne soit volé. La même surveillance runtime détecte également le bourrage de cookies d'affiliation et le détournement de liens, où les scripts injectés déposent des cookies d'affiliation contrôlés par l'attaquant ou réécrivent les liens sortants pour rediriger l'attribution, une attaque de couche navigateur tout aussi invisible.
Discordance d'appareil lors du rejeu. Lorsqu'un cookie volé est utilisé depuis un appareil différent, l'empreinte digitale de la session change. L'intelligence d'appareil de cside génère un ID d'appareil persistant à partir de plus de 250 signaux de navigateur, matériel et réseau avec 99.7% de précision. Une discordance d'empreinte digitale après une session établie est une anomalie que la couche de scoring comportemental signale pour réauthentification ou blocage.
Signaux comportementaux. Le rejeu automatisé de session depuis un script ou un agent IA produit des patterns différents des sessions humaines réelles : sans mouvement réaliste de souris, sans variance de défilement, sans cadence de frappe naturelle. Les signaux comportementaux de cside séparent l'automatisation de l'utilisation genuine.
cside intègre également la détection d'agents IA, capturant les outils d'orchestration et les navigateurs automatisés qui rejouent des sessions volées ou exécutent des accès de comptes scriptés à grande échelle.
PCI DSS 4.0.1 et sécurité des sessions sur les pages de paiement
Pour les plateformes de e-commerce et de paiement, les vecteurs de scripts côté client et XSS qui exfiltrent les tokens de session sont les mêmes risques que ciblent les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1. L'exigence 6.4.3 impose un inventaire de scripts et une méthode d'autorisation pour chaque script sur les pages de paiement. L'exigence 11.6.1 impose une surveillance continue et des alertes sur les modifications non autorisées des scripts de pages de paiement et des en-têtes HTTP de sécurité.
Un script tiers malveillant exfiltrant un token de session ou des données de carte de paiement sur une page de paiement est précisément la menace que ces exigences traitent. cside automatise les deux contrôles et produit des rapports hebdomadaires prêts pour les QSA (validé VikingCloud). La surveillance qui détecte un script malveillant volant des tokens de session satisfait également au mandat de détection d'altérations que les QSA évaluent désormais.
Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 sont obligatoires et évaluées depuis le 1er avril 2025.
