En bref : sécurité des sessions liées à l'appareil
- La faille: La MFA est traitée comme la ligne d'arrivée de la sécurité des comptes, mais dès que l'authentification est terminée, elle cesse d'aider, et chaque jeton de session volé après un défi MFA valide fonctionne toujours depuis n'importe quel appareil sur Internet.
- Ce que cside voit: Les sessions liées à l'appareil de cside génèrent une empreinte dérivée du matériel à partir du rendu GPU, de l'entropie du canvas, des métriques de polices et de la sortie WebGL, qui survit à l'effacement des cookies, au mode incognito et aux VPN, car elle est recalculée depuis l'appareil plutôt que stockée dans les cookies.
- La décision: Si votre posture face à la prise de contrôle de compte s'arrête à la MFA, décidez ce trimestre si une faille XSS ou un outil man-in-the-browser qui dérobe un jeton de session valide est un risque que vous êtes prêt à assumer entièrement.
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.
Une session liée à l'appareil est une session authentifiée rattachée à l'appareil précis qui l'a créée. Si le jeton de session est ensuite présenté depuis un autre appareil, l'écart d'empreinte est repéré et la session est rejetée ou soumise à un contrôle renforcé. Cela ferme une faille que la plupart des systèmes d'authentification laissent ouverte : la fenêtre après la connexion, pendant laquelle un jeton valide peut être volé et rejoué ailleurs.
| Scénario | Ce que fait la MFA | Ce que fait le rattachement à l'appareil |
|---|---|---|
| Identifiants volés avant la connexion | Demande à l'attaquant un second facteur | Attend qu'une session existe pour pouvoir la rattacher |
| L'attaquant valide la MFA sur son appareil | Autorise la connexion puisque le défi a été réussi | Rattache la nouvelle session à l'appareil de l'attaquant, sans annuler la connexion compromise |
| Jeton de session valide volé après la MFA | Ne déclenche aucun nouveau défi de connexion | Détecte une différence d'empreinte lorsque le jeton est rejoué depuis un autre appareil |
| Requête valide depuis l'appareil d'origine | A déjà terminé son contrôle à la connexion | Fait correspondre l'empreinte enregistrée et laisse la session continuer |
La faille post-authentification que le rattachement à l'appareil ferme
La MFA protège l'événement de connexion. Elle confirme que la personne qui soumet ses identifiants contrôle aussi un deuxième facteur à ce moment-là. Une fois l'authentification terminée et le jeton de session émis, la MFA a rempli son rôle. Le jeton lui-même est un identifiant au porteur : toute partie qui le détient peut le présenter au serveur et obtenir une réponse authentifiée.
Les jetons de session sont volés par plusieurs voies : le cross-site scripting qui lit les cookies, les proxys man-in-the-browser qui capturent les jetons au moment où ils sont définis, le vol du stockage de l'appareil, et l'ingénierie sociale qui pousse les utilisateurs à les exposer. Dans chaque cas, l'attaquant se retrouve avec un jeton valide émis après un contrôle MFA légitime. Le contrôle appartient déjà au passé. Le jeton volé fonctionne toujours.
Les sessions liées à l'appareil ferment cette faille. Même lorsqu'un attaquant détient un jeton valide, son utilisation depuis un autre appareil produit un écart d'empreinte que le serveur peut détecter. La session n'est approuvée que lorsqu'elle provient de l'appareil qui l'a créée.
Comment fonctionne techniquement le rattachement à l'appareil
La session est rattachée au moment de l'authentification. Lorsqu'un utilisateur se connecte, l'empreinte de l'appareil pour cette session (dérivée de signaux de navigateur et matériels) est enregistrée aux côtés du jeton de session dans le magasin de sessions du serveur.
À chaque requête ultérieure qui présente le jeton, le serveur compare l'empreinte actuelle à celle enregistrée à la connexion. Si elles correspondent, la requête se poursuit. Sinon, la session est invalidée ou un contrôle renforcé se déclenche.
L'empreinte utilisée pour le rattachement doit être stable et dérivée du matériel. Les identifiants basés sur les cookies ne conviennent pas, car ils peuvent être copiés en même temps que le jeton de session. Un attaquant qui vole un cookie de session peut aussi voler tout identifiant d'appareil basé sur les cookies présent dans le même magasin. Une empreinte de couche navigateur dérivée du rendu GPU, de l'entropie du canvas, des métriques de polices et de la sortie WebGL ne peut pas être extraite du stockage des cookies, car elle n'y est pas stockée. Elle est recalculée à partir du matériel à chaque session.
Les sessions liées à l'appareil de cside génèrent une empreinte dérivée du matériel à la création de la session et la renvoient aux côtés du jeton de session via leur API. Votre serveur enregistre l'empreinte avec la session. À chaque requête protégée, le script léger de cside recalcule l'empreinte pour la session en cours, et votre application la compare à la valeur stockée. cside ne remplace pas votre jeton de session. Il vous fournit un signal d'appareil suffisamment fort pour savoir si le jeton est rejoué à un endroit où il ne devrait pas l'être.
Contre quoi le rattachement à l'appareil protège
Détournement de session après une XSS. Une faille de cross-site scripting qui permet à un attaquant de lire les cookies de session ne livre pas une session exploitable lorsque cette session est liée à l'appareil. Rejouer le jeton volé depuis la machine de l'attaquant produit un écart d'empreinte.
Capture de session man-in-the-browser. Un logiciel malveillant de navigateur qui intercepte une session authentifiée capture le jeton mais pas le signal d'appareil, car ce signal est calculé à partir du matériel de la victime. Le jeton volé ne correspond pas à l'empreinte de l'attaquant.
Partage d'identifiants après authentification. Lorsqu'un utilisateur légitime transmet son jeton de session à un collègue (courant dans les outils d'entreprise où l'ajout d'un poste nécessite une action d'administration), la session partagée présente un écart d'appareil. C'est le problème du partage de compte appliqué à la couche session plutôt qu'à la couche connexion.
Voyage impossible. Une session créée à Londres puis présentée depuis un appareil aux caractéristiques réseau d'une autre zone géographique, dans une fenêtre de temps trop courte pour un déplacement physique, est détectable grâce au changement d'empreinte combiné aux signaux réseau.
Comment les sessions liées à l'appareil et la MFA s'articulent
Le rattachement à l'appareil protège la session après l'authentification. La MFA protège l'événement de connexion pendant l'authentification. Ils couvrent des points différents du cycle de vie de la session, et une posture complète contre la prise de contrôle de compte a besoin des deux.
Un attaquant qui contourne la MFA par un échange de carte SIM (SIM swap) ou par lassitude face aux notifications push et qui s'authentifie avec succès reçoit un jeton de session sur son propre appareil. Le rattachement à l'appareil sur cette session n'aide en rien, car l'appareil de l'attaquant est l'origine de la session. La MFA est le contrôle qui compte à ce stade.
Un attaquant qui observe un utilisateur légitime effectuer la MFA puis vole le jeton de session par une XSS est arrêté par le rattachement à l'appareil, car son empreinte ne correspond pas à l'origine de la session. La MFA est déjà terminée et n'apporte rien à ce stade.
Réunissez les deux et la couverture devient claire. La MFA arrête à la connexion les attaquants qui n'ont pas d'identifiants valides ou ne peuvent pas satisfaire le deuxième facteur. Le rattachement à l'appareil arrête après la connexion les attaquants qui ont obtenu une session valide d'une autre manière.
