Face à des infostealers de plus en plus friands de cookies de session, Chrome 146 inaugure sur Windows une protection matérielle pensée pour entraver le détournement de comptes en ligne.
Les infostealers ne se contentent plus de voler mots de passe et données personnelles. Depuis plusieurs années, ils récupèrent aussi les cookies de session stockés dans les navigateurs pour contourner l’authentification et rouvrir l’accès à des comptes sans avoir à repasser par une page de connexion. Avec les Device Bound Session Credentials, ou DBSC, déployés dans Chrome 146 sur Windows, Google cherche à enrayer ce mode opératoire en liant la session à l’appareil sur lequel elle a été ouverte. Une prise en charge de macOS est déjà prévue dans une prochaine version du navigateur.
Chrome lie désormais la session à l’appareil
Le principe des DBSC consiste à rattacher cryptographiquement une session web à l’appareil sur lequel elle a été ouverte, en mobilisant le TPM sous Windows et, à terme, le Secure Enclave sur macOS. Ces composants génèrent une paire de clés publique et privée, dont la clé privée ne peut pas être extraite de la machine.
Jusqu’ici, lorsqu’un malware mettait la main sur un cookie de session, il pouvait le transmettre à un attaquant, qui l’utilisait ensuite pour accéder au compte depuis une autre machine, sans avoir besoin du mot de passe. Avec les DBSC, ce jeton ne suffit plus à lui seul. Pour prolonger la session, Chrome doit en effet présenter au site ou au service en ligne une preuve de possession de la clé privée associée avant que de nouveaux cookies de courte durée soient émis. Or, comme cette clé reste liée à l’appareil d’origine, le jeton récupéré par un infostealer finit rapidement par ne plus servir à grand-chose.
Le but n’est donc pas d’empêcher à tout prix le vol du cookie, ni d’attendre qu’il soit repéré pour réagir, mais de faire en sorte qu’une fois exfiltré de l’appareil sur lequel la session a été ouverte, il ne suffise plus à maintenir durablement l’accès au compte.
Une protection pensée pour le web sans devenir un nouvel outil de pistage
Ce nouveau dispositif ne doit pas changer la manière dont les internautes se connectent à un site ou à un service en ligne. Son adoption suppose surtout quelques ajustements du côté du serveur, qui doit enregistrer la session protégée au moment de la connexion puis en vérifier le renouvellement en s’assurant que Chrome détient bien la clé attendue. Le navigateur prend ensuite en charge la rotation des cookies et les opérations cryptographiques associées, sans imposer de refonte de l’interface ou du parcours de connexion.
Côté confidentialité, chaque session repose sur une clé distincte, ce qui évite de transformer ce mécanisme en identifiant réutilisable d’un site à l’autre ou d’une connexion à l’autre. Le protocole a aussi été conçu pour limiter les informations transmises au strict nécessaire, sans exposer d’identifiant matériel ni de données d’attestation au-delà de ce qui permet de valider la session.
DBSC n’a par ailleurs pas été pensé comme une brique propriétaire réservée à Chrome. Le protocole suit le processus de standardisation du W3C, dans le cadre du Web Application Security Working Group, sur fond de travail mené avec Microsoft et d’échanges plus larges avec l’écosystème de la sécurité web. Avant ce premier déploiement public sur Windows, la technologie a aussi fait l’objet de plusieurs phases de test avec des plateformes volontaires, dont Okta, afin de vérifier son fonctionnement dans des conditions réelles.
Google prévoit désormais d’étendre le dispositif à macOS, d’en élargir l’usage aux environnements d’entreprise, en particulier là où les parcours SSO dominent encore, et d’explorer une prise en charge des appareils dépourvus de module matériel dédié.
- Vitesse de navigation imbattable
- Écosystème d'extensions très riche
- Synchronisation multi-appareils fluide
Un cookie de session est un jeton stocké par le navigateur qui prouve qu’un utilisateur s’est déjà authentifié, et permet de rester connecté sans ressaisir son mot de passe. S’il est copié, un attaquant peut souvent « rejouer » ce cookie sur une autre machine pour accéder au compte comme si la session était toujours valide. Ce contournement est particulièrement efficace contre les protections basées sur le mot de passe, puisqu’il évite l’étape de connexion. La valeur du cookie dépend aussi de sa durée de vie et de la façon dont le service renouvelle la session côté serveur.
Que change le principe des Device Bound Session Credentials (DBSC) par rapport à un cookie classique ?Les DBSC lient cryptographiquement la session à l’appareil qui l’a ouverte, au lieu de considérer le cookie comme une preuve suffisante à lui seul. Concrètement, lors du renouvellement, le navigateur doit prouver au serveur qu’il possède une clé privée associée à cette session, en plus de présenter le cookie. Si un malware exfiltre le cookie, il ne peut pas emporter la clé privée, ce qui limite fortement l’usage du jeton volé hors de la machine d’origine. Le mécanisme s’appuie sur des cookies à courte durée de vie et sur un renouvellement conditionné par cette preuve de possession.
Quel est le rôle du TPM (Windows) et du Secure Enclave (macOS) dans la protection DBSC ?Le TPM et le Secure Enclave sont des modules matériels conçus pour générer et stocker des clés cryptographiques de manière isolée du système, afin d’empêcher leur extraction par logiciel. Dans DBSC, ils servent à produire une paire de clés (publique/privée) où la clé privée reste non exportable, même si l’ordinateur est compromis. Le navigateur peut alors signer une preuve de possession avec cette clé privée pour valider le renouvellement de session côté serveur. Cela ne rend pas le vol de cookies impossible, mais réduit leur réutilisation à distance en l’absence de la clé liée à l’appareil.
