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 ?

Qu'est-ce que 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.

Comment fonctionne le détournement de session ?

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.

Quels sont les types de détournement de session ?

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 :

1) Les scripts intersites (XSS)

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.

2) Piratage de session (Session Side-Jacking) ou reniflage de session (Session Sniffing)

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. 

3) Fixation de la session

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.

4) ID de session prévisibles et force brute

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.

5) L'homme dans le navigateur (ou attaque de l'homme du milieu ou logiciel malveillant)

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.

En quoi le détournement de session diffère-t-il de l'usurpation de session ?

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.

Quels sont les risques et les conséquences du détournement de session ?

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

• Monetary theft: Attackers gain the ability to conduct financial transactions on behalf of the user. This might involve transferring money from a bank account or making purchases with saved payment information.
  
  
• Identity theft: Attackers gain unauthorized access to sensitive personal information saved in accounts that they can use to steal a victim’s identity beyond the confines of the hacked website/application.
• Data theft: Attackers can steal any kind of sensitive personal or organizational data housed within the application and use that information to harm the victim or organization (e.g., in the case of blackmail) or to pursue their agenda (e.g., in the case of selling protected, potentially competitive information or intellectual property).
  
  
• Access to additional systems through SSO: Attackers can also gain unauthorized access to additional systems if SSO is enabled, further spreading the potential risk of a session hijacking attack. This risk is particularly important for organizations, many of which now enable SSO for employees. Ultimately, this means that even highly protected systems with stronger authentication protocols and less predictable session cookies, like those that house financial or customer information, may only be as protected as the weakest link in the entire system.

Quels sont les exemples de détournement de session ?

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

1) "Zoom-bombing" (bombardement)

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". 

Several notable instances occurred in which attackers engaged in session hijacking to join private video sessions. The most reported instances included those in which the attackers made themselves known by shouting profanities, hateful language, and sharing pornographic images. In response, companies like Zoom issued stronger privacy protections, such as meeting passwords and waiting rooms, so that meeting hosts could manually admit guests.

2) Extension "Firesheep" de Mozilla Firefox

In 2010, Mozilla Firefox released a browser extension called Firesheep that opened a vulnerability for people using the browser on public, unencrypted Wifi networks. Specifically, the Firesheep extension made it easy for attackers to easily steal these users’ session cookies from any website added to their preferences in the browser. Ultimately, many websites responded to protect against this session hijacking risk by requiring HTTP Secure (HTTPS) connections.

3) Slack

In 2019, a researcher on a bug bounty platform found a vulnerability in Slack that would allow attackers to force users into fake session redirects and then steal their session cookies, ultimately giving the attackers access to any data shared within Slack (which for many organizations ends up being quite a lot). Slack responded quickly and patched the vulnerability within 24 hours of the researcher identifying it.

4) GitLab

In 2017, a security researcher identified a vulnerability in GitLab in which users’ session tokens were available directly in the URL. Upon digging deeper, the researcher found that GitLab also used persistent session tokens that never expired, meaning once an attacker got one session token, they could use it without the worry of 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.

Comment se protéger contre le détournement de session ?

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.

1) Utiliser HTTPS

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.

2) S'appuyer sur des cadres web pour la gestion des cookies de session

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.

3) Modifier la clé de session après l'authentification

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.

4) Introduire des domaines supplémentaires pour la vérification de l'identité

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.

5) Introduire les systèmes de détection d'intrusion (IDS) et les systèmes de protection d'intrusion (IPS)

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.

6) Les sessions des utilisateurs sont limitées dans le temps et/ou la déconnexion automatique est obligatoire.

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.

All it takes is one expired certificate to take down critical systems and applications. But without visibility, it’s impossible to stay ahead. Keyfactor is here to help you prevent session hijacking and system outages—get in touch with us today.