Le détournement de session se produit lorsqu'un pirate vole ou usurpe l'identifiant de session valide d'un utilisateur afin d'obtenir un accès non autorisé à des applications Web. Cela peut se produire de différentes manières, notamment le XSS, le reniflage de réseau ou l'utilisation de jetons de session prévisibles. La prévention passe par une gestion sécurisée des sessions, l'utilisation du protocole HTTPS et la mise en œuvre de politiques de délai d'expiration des sessions appropriées.
Après la connexion d'un utilisateur, le serveur émet un identifiant de session, généralement stocké dans un cookie ou un token, qui représente la connexion à chaque requête suivante. Le détournement de session (session hijacking) désigne toute technique permettant à un attaquant d'obtenir ou de reproduire cet identifiant et de l'utiliser pour agir en tant qu'utilisateur, sans jamais connaître le mot de passe. Le vol peut se produire de plusieurs façons : un cross-site scripting ou un script tiers malveillant qui lit le cookie, l'écoute du trafic réseau non chiffré, un logiciel malveillant sur l'appareil, ou la devinette de tokens faibles et prévisibles. Une fois que l'attaquant rejoue un identifiant de session valide, l'application traite ses requêtes comme celles de l'utilisateur authentique jusqu'à l'expiration ou la révocation de la session.
Une session volée accorde un accès authentifié immédiat, contournant ainsi entièrement la connexion, y compris l'authentification multifacteur qui n'a été vérifiée qu'à l'ouverture de session. C'est là l'essence d'une attaque pass-the-cookie : avec un cookie de session valide, l'attaquant n'a souvent besoin ni de mot de passe ni de second facteur. Selon le compte, il peut lire des données privées, effectuer des achats, transférer des fonds ou modifier des paramètres pour verrouiller l'accès au véritable utilisateur. Comme les requêtes portent une session légitime, elles paraissent normales au serveur ; la détection repose donc souvent sur des signaux plus subtils, tels qu'un changement soudain d'appareil ou de localisation, plutôt que sur un échec manifeste.
N'envoyez les cookies de session que via HTTPS, marquez-les HttpOnly pour que le JavaScript côté client ne puisse pas les lire, et définissez l'attribut SameSite pour limiter l'envoi intersite. Utilisez des tokens longs et aléatoires, faites-les tourner lors des changements de privilèges, et appliquez des délais d'expiration sensés ainsi qu'une révocation côté serveur. Comme une voie de vol courante est un script tiers malveillant ou compromis qui lit les cookies ou les tokens dans le navigateur, maîtriser le code côté client est important : cside achemine les scripts tiers via un méthode Script, analyse la charge utile et peut bloquer en temps réel un script qui tente d'exfiltrer des données de session, tout en conservant un enregistrement forensique. Détecter une incohérence d'appareil sur une session réutilisée peut aussi signaler un token détourné.
Il s'agit d'un détournement de session qui utilise un cookie de session volé. Comme le cookie représente déjà une session authentifiée, un attaquant qui l'obtient peut l'importer dans son propre navigateur et accéder au compte sans le mot de passe ni un second facteur. C'est un moyen prisé de contourner l'authentification multifacteur après coup.
Non. HttpOnly empêche le JavaScript côté client, y compris les charges utiles XSS, de lire un cookie, ce qui ferme une voie de vol majeure. Mais les sessions peuvent encore être détournées par l'écoute du réseau, un logiciel malveillant sur l'appareil ou des tokens prévisibles. C'est une couche importante, à combiner idéalement avec HTTPS, SameSite, une génération de tokens robuste et des délais d'expiration.
We answer client-side security questions every day. Bring yours.