Qu'est-ce que le détournement de session et comment fonctionne-t-il ?

Le détournement de session (alias cookie hijacking ou cookie side-jacking) est une cyber-attaque dans laquelle les attaquants prennent le contrôle de la session informatique d'un utilisateur légitime pour obtenir son identifiant de session et agir ensuite en tant qu'utilisateur sur un certain nombre de services de réseau. Ce type d'attaque est dangereux pour la sécurité des applications car il permet aux attaquants d'obtenir un accès non autorisé à des comptes protégés (et aux données qu'ils contiennent) sous l'apparence d'un utilisateur légitime.

Cet article présente tout ce qu'il faut savoir sur le détournement de session, notamment

• Qu'est-ce que le détournement de session ?
• Comment fonctionne le détournement de session ?
• Quels sont les types de détournement de session ?
• En quoi le détournement de session diffère-t-il de l'usurpation de session ?
• Quels sont les risques et les conséquences du détournement de session ?
• Quels sont les exemples de détournement de session ?
• Comment se protéger contre le détournement de session ?

Chaque fois qu'un utilisateur accède à un site web ou à une application via une connexion HTTP, le service authentifie l'utilisateur (par exemple, au moyen d'un nom d'utilisateur et d'un mot de passe) avant d'ouvrir la ligne de communication et de fournir l'accès. Cependant, les connexions HTTP sont en elles-mêmes "sans état", ce qui signifie que chaque action d'un utilisateur est considérée de manière indépendante. Par conséquent, si nous nous appuyons uniquement sur le protocole HTTP, les utilisateurs devront s'authentifier à nouveau pour chaque action qu'ils entreprennent ou chaque page qu'ils consultent.

Les sessions permettent de résoudre ce problème. Une session est créée sur le serveur hébergeant le site web ou l'application lorsque l'utilisateur se connecte et sert de référence pour l'authentification initiale. En fait, les utilisateurs peuvent rester authentifiés aussi longtemps qu'une session reste ouverte sur le serveur. Les utilisateurs peuvent mettre fin à une session en se déconnectant du service, ou certains services mettent fin à une session après une période d'inactivité prédéfinie.

La plupart des services créent ces sessions en émettant un identifiant de session, une chaîne de chiffres et de lettres stockée dans des cookies de session temporaires, des URL ou des champs cachés sur le site web. Dans certains cas, ces identifiants de session sont cryptés, mais ce n'est pas toujours le cas. Et dans de nombreux cas, ces identifiants de session sont basés sur des informations prévisibles, comme l'adresse IP de l'utilisateur.

Le détournement de session se produit lorsque des attaquants obtiennent un accès non autorisé à l'identifiant de session d'un utilisateur, ce qui leur permet d'assumer l'identité en ligne de cet utilisateur. Ce faisant, les attaquants peuvent se faire passer pour des utilisateurs légitimes, obtenir des informations et entreprendre des actions sous l'identité usurpée.

Le détournement de session commence lorsqu'un pirate obtient un accès non autorisé à l'identifiant de session d'un utilisateur. Les attaquants obtiennent généralement cet accès soit en volant le cookie de session d'un utilisateur (d'où le nom alternatif de détournement de cookie), soit en convainquant l'utilisateur de cliquer sur un lien malveillant qui contient un identifiant de session prédit (plus d'informations à ce sujet ci-dessous).

Une fois qu'un pirate dispose de l'identifiant de session et que l'utilisateur s'est connecté au service, il peut prendre le contrôle de la session. Pour ce faire, il applique l'identifiant de session de l'utilisateur légitime à son navigateur, ce qui fait croire au service que l'attaquant est l'utilisateur légitime engagé dans cette même session.

Sous cette apparence, l'attaquant peut alors se faire passer pour l'utilisateur légitime et accéder à toute information ou entreprendre toute action que l'utilisateur est autorisé à faire. Dans les cas où les utilisateurs disposent d'une connexion unique (SSO), le pirate peut utiliser cette approche pour obtenir un accès non autorisé à n'importe quel nombre d'applications, ce qui compromet gravement la sécurité de l'ensemble des applications.

Si l'on examine de plus près le fonctionnement exact du détournement de session, on découvre de nombreuses façons de mener ce type d'attaque. Les types de détournement de session sont les suivants :

Le cross-site scripting (XSS) est l'un des plus grands risques et l'une des approches les plus populaires pour le détournement de session. Le XSS se produit lorsque l'attaquant trouve des vulnérabilités dans le serveur ou l'application cible et en profite pour injecter des scripts côté client dans la page web. La page se charge alors avec ce code malveillant, mais tout semble légitime du côté de l'utilisateur car il provient toujours d'un serveur de confiance. Une fois le code malveillant chargé, il permet à l'attaquant de voler l'identifiant de session de l'utilisateur.

L'attaquant peut envoyer un lien vers un site web de confiance dans le cadre d'une attaque XSS, mais avec des paramètres de requête HTTP modifiés. Une fois que l'utilisateur a cliqué sur ce lien, l'attaquant peut accéder à son identifiant de session ou, dans certains cas, le lien peut même envoyer ces informations directement à l'attaquant. Dans des cas comme celui-ci, les attaquants utilisent généralement un raccourcisseur d'URL pour masquer l'URL et, par conséquent, tout ce qui est suspect dans le lien.

Le piratage de session, également connu sous le nom de reniflage de session, est un type d'attaque de piratage plus actif. Dans ce cas, les attaquants utilisent des outils de reniflage de paquets tels que Wireshark ou Kismet pour surveiller le trafic réseau et voler les cookies de session après l'authentification. Les utilisateurs sont plus vulnérables à ce type d'attaque lorsque le serveur ne chiffre que la page d'authentification et non les autres pages de la session. Par conséquent, les attaquants peuvent obtenir l'identifiant de session après l'authentification sur les pages non chiffrées tout au long de la session.

Il est important de noter que les attaquants doivent avoir accès au réseau de l'utilisateur pour exécuter ce type d'attaque, ce qui signifie que le piratage de session se produit généralement sur des réseaux WiFi non sécurisés ou des réseaux publics. 

La fixation de session se produit lorsque des attaquants peuvent définir l'identifiant de session d'un utilisateur. 

Ce type d'attaque nécessite une vulnérabilité dans le site web cible qui permet de définir des identifiants de session par le biais d'URL ou de formulaires. Dans ce cas, un pirate peut définir un identifiant de session au nom d'un utilisateur et l'amener à se connecter en conséquence, soit en lui envoyant une URL de phishing contenant l'identifiant de session, soit en définissant cet identifiant dans un faux formulaire de connexion. 

Dans les deux cas, l'utilisateur légitime se connecte à un site web et s'authentifie à l'aide de l'identifiant de session fixé par l'attaquant (et donc connu de lui). Une fois que l'utilisateur s'est connecté, l'attaquant peut également utiliser l'identifiant de session.

De nombreux sites web suivent un modèle pour l'émission des identifiants de session et, dans certains cas, il peut s'agir simplement de l'adresse IP de l'utilisateur. Dans ces cas, les attaquants peuvent surveiller les identifiants de session qui sont émis pour déterminer le modèle. S'ils y parviennent, ils peuvent facilement prédire à quoi peut ressembler un identifiant de session valide pour des utilisateurs spécifiques et générer cet identifiant de session pour l'utiliser eux-mêmes.

De même, une attaque par force brute peut se produire si les attaquants ont accès à une liste d'identifiants de session et les essaient encore et encore jusqu'à ce que l'un d'entre eux fonctionne. Ils disposeront généralement d'une telle liste si le modèle de génération des identifiants est prévisible. La différence, dans ce cas, est qu'ils peuvent ne pas être en mesure de prédire l'identifiant d'un utilisateur spécifique, de sorte qu'ils devront essayer différents identifiants de la liste jusqu'à ce qu'ils trouvent une correspondance.

Une attaque de type "homme dans le navigateur", également connue sous le nom d'attaque de type "homme du milieu" ou attaque par logiciel malveillant, nécessite tout d'abord que les attaquants infectent l'ordinateur d'un utilisateur avec un logiciel malveillant. 

Une fois que le logiciel malveillant est installé et qu'un utilisateur se connecte à un site web, l'attaquant peut alors agir comme un homme du milieu et intercepter des informations, modifier les actions d'un utilisateur sur le site ou entreprendre des actions supplémentaires en se faisant passer pour cet utilisateur - tout cela à l'insu de l'utilisateur. Comme ce type d'attaque provient de l'appareil de l'utilisateur légitime, il peut être très difficile de détecter les violations de la sécurité des applications dans ce type d'attaques.

Avec ce type d'accès à l'appareil d'un utilisateur, les attaquants peuvent également aller directement dans le dossier de stockage local temporaire du navigateur (alias "cookie jar") et s'emparer des identifiants de session pour tous les cookies qu'ils souhaitent.

Le détournement de session et l'usurpation de session sont similaires à bien des égards, mais il ne s'agit pas en fin de compte du même type d'attaque. La différence la plus importante entre ces deux types d'attaques est que le détournement de session se produit lorsqu'un utilisateur légitime est connecté à une bonne session web. En revanche, l'usurpation de session se produit lorsque les attaquants se font passer pour un utilisateur afin de lancer une nouvelle session web (ce qui signifie que l'utilisateur n'a pas besoin d'être connecté à ce moment-là).

La plus grande manifestation de cette différence est l'expérience de l'utilisateur légitime. Dans le cas d'un détournement de session, un attaquant interrompant la session peut entraîner un comportement inhabituel du site web ou de l'application, voire un plantage pour la victime. En revanche, comme l'utilisateur n'est pas activement connecté lors d'une attaque par usurpation de session, il ne subira aucun "effet secondaire" de la session suivante.

Un cas réussi de détournement de session donne à un attaquant la possibilité de faire tout ce que l'utilisateur ciblé peut faire. Cela présente un risque important pour la sécurité des applications, notamment lorsqu'il s'agit d'initier des transactions monétaires, d'accéder à des données protégées ou d'obtenir un accès non autorisé à d'autres systèmes par le biais du SSO.

Parmi les risques les plus notables de détournement de session, on peut citer

• Vol d'argent : Les attaquants acquièrent la capacité d'effectuer des transactions financières au nom de l'utilisateur. Il peut s'agir de transférer de l'argent d'un compte bancaire ou d'effectuer des achats à l'aide d'informations de paiement enregistrées.
  
• L'usurpation d'identité : Les attaquants obtiennent un accès non autorisé à des informations personnelles sensibles enregistrées dans des comptes qu'ils peuvent utiliser pour voler l'identité d'une victime au-delà des limites du site web ou de l'application piraté(e).
• Vol de données : Les attaquants peuvent voler tout type de données personnelles ou organisationnelles sensibles hébergées dans l'application et utiliser ces informations pour nuire à la victime ou à l'organisation (par exemple, en cas de chantage) ou pour poursuivre leurs objectifs (par exemple, en cas de vente d'informations protégées, potentiellement concurrentielles, ou de propriété intellectuelle).
  
• Accès à d'autres systèmes par le biais du SSO : Les attaquants peuvent également obtenir un accès non autorisé à d'autres systèmes si le SSO est activé, ce qui étend encore le risque potentiel d'une attaque par détournement de session. Ce risque est particulièrement important pour les organisations, dont beaucoup autorisent désormais le SSO pour les employés. En fin de compte, cela signifie que même les systèmes hautement protégés avec des protocoles d'authentification plus forts et des cookies de session moins prévisibles, comme ceux qui hébergent des informations financières ou des informations sur les clients, peuvent n'être protégés que par le maillon le plus faible de l'ensemble du système.

Plusieurs exemples très médiatisés illustrent exactement ce qui peut se produire à la suite d'une attaque par détournement de session. Parmi les exemples les plus notables, on peut citer

Lorsque la pandémie de COVID-19 a frappé, le monde est devenu numérique, l'école, le travail et les événements sociaux se déroulant par le biais d'applications de vidéoconférence comme Zoom. Il n'a pas fallu longtemps pour que ces vidéoconférences deviennent une victime populaire du détournement de session, ce qui leur a valu le nom de "Zoom-bombing". 

Plusieurs cas notables se sont produits, dans lesquels les attaquants se sont livrés à un détournement de session pour rejoindre des sessions vidéo privées. Les cas les plus signalés sont ceux où les attaquants se sont fait connaître en proférant des injures, des propos haineux et en partageant des images pornographiques. En réaction, des entreprises comme Zoom ont mis en place des mesures de protection de la vie privée plus strictes, telles que des mots de passe pour les réunions et des salles d'attente, afin que les organisateurs de réunions puissent admettre manuellement les invités.

En 2010, Mozilla Firefox a publié une extension de navigateur appelée Firesheep qui a ouvert une faille pour les personnes utilisant le navigateur sur des réseaux Wifi publics non cryptés. Plus précisément, l'extension Firesheep permettait aux pirates de voler facilement les cookies de session de ces utilisateurs à partir de n'importe quel site web ajouté à leurs préférences dans le navigateur. En fin de compte, de nombreux sites web ont réagi pour se protéger contre ce risque de détournement de session en exigeant des connexions HTTP sécurisées (HTTPS).

En 2019, un chercheur sur une plateforme de bug bounty a découvert une vulnérabilité dans Slack qui permettrait aux attaquants de forcer les utilisateurs dans de fausses redirections de session, puis de voler leurs cookies de session, donnant finalement aux attaquants l'accès à toutes les données partagées dans Slack (ce qui, pour de nombreuses organisations, finit par être assez important). Slack a réagi rapidement et a corrigé la vulnérabilité dans les 24 heures qui ont suivi son identification par le chercheur.

En 2017, un chercheur en sécurité a identifié une vulnérabilité dans GitLab dans laquelle les jetons de session des utilisateurs étaient disponibles directement dans l'URL. En creusant un peu, le chercheur a découvert que GitLab utilisait également des jetons de session persistants qui n'expiraient jamais, ce qui signifie qu'une fois qu'un attaquant a obtenu un jeton de session, il peut l'utiliser sans se soucier de l'expiration.

Cette combinaison d'exposition ouverte et de jetons persistants présentait un risque sérieux, exposant les utilisateurs à diverses attaques graves par détournement de session via une attaque par force brute. GitLab a finalement corrigé la vulnérabilité en modifiant la façon dont il utilise et stocke ces jetons.

Le détournement de session reste une menace majeure pour la cybersécurité, mais il existe plusieurs moyens de protéger votre organisation et ses utilisateurs contre ce type d'attaque. Les meilleurs résultats proviennent de l'utilisation combinée de plusieurs (voire de toutes) ces approches afin de fournir plusieurs lignes de défense pour la protection.

Assurez-vous que les sites web et les applications utilisés par votre équipe (en particulier ceux qui font partie d'un univers SSO) exigent l'utilisation de HTTPS partout - même au-delà des pages de connexion initiales - pour garantir des sessions entièrement sécurisées à chaque étape. Vous devez également les obliger à utiliser le cryptageSSL / TLS pour tout, y compris pour le partage des clés de session. 

Ce niveau de cryptage constitue la première ligne de défense pour protéger la visibilité des clés de session. Enfin, il convient d'établir une norme pour verrouiller l'accès aux cookies à partir de scripts côté client afin de se protéger contre les attaques XSS.

Plus les cookies de session générés sont longs et aléatoires, mieux c'est, car ils sont alors plus difficiles à prédire ou à deviner, ce qui offre une protection contre les attaques par force brute. La meilleure façon d'obtenir ce véritable caractère aléatoire est d'utiliser un cadre web pour générer et gérer les cookies de session plutôt que de créer un système soi-même.

La meilleure façon de se protéger contre les attaques par fixation de session est de changer la clé de session immédiatement après l'authentification lors de la connexion. 

En changeant la clé après la connexion, même si un pirate connaît la clé originale, il ne connaîtra pas la clé qui suivra l'utilisateur pendant le reste de sa session. Cette approche signifie que même si un pirate envoie aux utilisateurs un lien d'hameçonnage et que les utilisateurs utilisent ce lien pour se connecter, le pirate ne sera pas en mesure de faire quoi que ce soit avec la clé générée.

L'ajout de nouveaux domaines de vérification de l'identité au-delà de la connexion initiale et du cookie de session qui en résulte peut également fournir une autre couche de protection. 

Par exemple, vous pouvez examiner l'adresse IP de l'utilisateur pour déterminer si elle correspond à l'emplacement des connexions précédentes ou surveiller le comportement général de chaque utilisateur pour mieux identifier les anomalies. Toutefois, cette approche n'est pas parfaite : elle peut signaler des problèmes sans importance, comme les cas où les utilisateurs se déplacent souvent, et passer à côté de problèmes réels, comme les cas où un attaquant se connecte à partir de la même adresse IP que celle de l'utilisateur habituel.

Les systèmes IDS et IPS comparent le trafic du site à une base de données de signatures d'attaques connues. Si ces systèmes trouvent une correspondance, ils bloquent le trafic et alertent les propriétaires du système. Ces systèmes peuvent être difficiles et coûteux à installer, mais ils offrent une solide couche de défense contre le détournement de session.

Enfin, envisagez d'instaurer des politiques qui gèrent la manière dont les utilisateurs mettent fin aux sessions. Parmi les deux approches les plus répandues, citons la temporisation des sessions des utilisateurs, en particulier après une période d'inactivité, et l'obligation de fermeture automatique de la session lorsque la fenêtre est fermée. Ces deux approches permettent de minimiser la durée pendant laquelle un cookie de session particulier reste actif. Dans le même ordre d'idées, lorsqu'un utilisateur se déconnecte, vous devez vous assurer que le cookie de session est automatiquement supprimé de son appareil afin d'éviter toute exposition supplémentaire.