Fixation de session

Un article de Wikipédia, l'encyclopédie libre.

Cet article est une ébauche concernant la sécurité informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

En sécurité des réseaux informatiques, les attaques par fixation de session exploitent la vulnérabilité d'un système qui permet à quelqu'un de fixer (déterminer) l'identifiant de session (SID ou session ID) d'une autre personne. La plupart de ces attaques ont lieu sur le web et ont pour origine l'acceptation de SIDs dans l'URL (chaine de la requête) ou dans les données POST.

Scénarios d'attaque[modifier | modifier le code]

Alice a un compte à la banque http://unsafe/. Malheureusement Alice n'est pas sensibilisée à la sécurité.

Mallory a l'intention d'obtenir l'argent d'Alice dans cette banque.

Alice a un niveau de confiance raisonnable envers Mallory, et visitera les liens que Mallory lui envoie.

Scénario d'attaque simple[modifier | modifier le code]

Scénario direct :

  1. Mallory a déterminé que http://unsafe/ accepte tout SID, accepte les SID en chaines de caractères et ne dispose pas d'un processus de validation du SID. Par conséquent http://unsafe/ n'est pas sécurisé.
  2. Mallory envoie un email à Alice : "Hey, regarde cela, il y a une nouvelle fonctionnalité sur notre banque, http://unsafe/?SID=JE_VAIS_CONNAITRE_LE_SID". Mallory essaye de fixer le SID à JE_VAIS_CONNAITRE_LE_SID.
  3. Alice est intéressée et visite http://unsafe/?SID=JE_VAIS_CONNAITRE_LE_SID. La page de connexion habituelle s'affiche, et Alice se connecte.
  4. Mallory visite http://unsafe/?SID=JE_VAIS_CONNAITRE_LE_SID et a à présent un accès illimité au compte de Alice.

Attaque par génération de SID sur le serveur[modifier | modifier le code]

Une idée fausse est qu'un serveur qui accepte uniquement les SID générés par le serveur n'est pas menacé par la fixation. Ceci est faux.

Scénario :

  1. Mallory visite http://vulnerable et prend connaissance du SID renvoyé. Par exemple le serveur peut renvoyer Set-Cookie: SID=0D6441FEA4496C2.
  2. Mallory peut à présent envoyer un email à Alice: "Regarde cette nouvelle fonctionnalité de notre banque http://vulnerable/?SID=0D6441FEA4496C2.
  3. Alice se connecte, ce qui fixe son SID à 0D6441FEA4496C2.

Attaque par utilisation du cross-site cooking[modifier | modifier le code]

Une autre attaque par fixation de session, le cross-site cooking, exploite les vulnérabilités du navigateur. Ceci permet au site http://mechant/ d'enregistrer des cookies dans le navigateur d'Alice dans le domaine de cookies d'un autre serveur, par exemple http://gentil/, à qui Alice fait confiance. Cette attaque peut fonctionner même s'il n'y a pas de vulnérabilité dans http://gentil/, car http://gentil/ peut supposer que la gestion des cookies par le navigateur d'Alice est sécurisée.

Scénario :

  1. Mallory envoie un email à Alice: "Hey, regarde ce site, http://mechant/".
  2. Alice visite http://mechant/, qui établit un cookie de SID avec la valeur JE_VAIS_CONNAITRE_LE_SID dans le domain http://gentil/.
  3. Alice reçoit ensuite un email de Mallory, "Hey, regarde ton compte en banque http://gentil/".
  4. Alice se connecte, Mallory peut utiliser son compte en utilisant le SID fixé.

Attaque par utilisation du cross-subdomain cooking[modifier | modifier le code]

Cette technique est identique à l'attaque avec utilisation du cross-site cooking, mis à part qu'elle ne repose pas sur une vulnérabilité du navigateur. Elle repose sur le fait que des cookies jokers peuvent être créés par un sous-domaine qui affecte les autres sous-domaines.

Scénario :

  1. Un site web www.example.com fournit des sous-domaines à des tierces parties dont elle n'a pas confiance.
  2. L'une de ces parties, Mallory, qui contrôle mechant.example.com attire Alice sur son site.
  3. La visite d'Alice sur mechant.example.com crée un cookie de session avec le domaine .example.com sur le navigateur d'Alice.
  4. Quand Alice visite www.example.com, ce cookie sera envoyé avec la requête, et la session d'Alice sera spécifiée par le cookie de Mallory.
  5. Si Alice se connecte, Mallory peut utiliser son compte.

Chacun de ces scénarios d'attaque a résulté d'une élévation de privilèges, où Mallory a obtenu l'accès à des fonctions et des données normalement réservées à Alice.

Un scénario d'attaque alternatif ne requiert pas qu'Alice se connecte à un site. Plutôt, simplement en fixant la session, Mallory peut être capable d'espionner Alice et de profiter des données qu'elle envoie. Par exemple, Mallory peut utiliser les attaques ci-dessus pour donner à Alice sa propre session authentifiée — ainsi Alice commencera à utiliser le site avec l'authentification de Mallory. Si Alice décide d'acheter quelque chose sur ce site et entre son numéro de carte de crédit, Mallory peut être en mesure de récupérer les données en regardant l'historique des données enregistrées pour ce compte.

Moyens de lutte[modifier | modifier le code]

Ne pas créer de contexte utilisateur côté serveur à partir d'un SID généré par l'utilisateur[modifier | modifier le code]

Le contexte utilisateur représente l'ensemble des informations côté serveur concernant l'utilisateur qui s'est authentifié (la session) et auquel est lié le SID. Cela permet notamment au serveur d'identifier les droits de l'émetteur de la requête pour le contrôle d'accès.

Ne pas accepter les SIDs des variables GET/POST[modifier | modifier le code]

Les SIDs dans l'URL (variables GET) ou dans les variables POST ne sont pas recommandées car ils simplifient cette attaque. Il est aisé de créer des liens ou des formulaires qui déterminent les variables GET / POST.

Utiliser a bon escient les cookies HTTP[modifier | modifier le code]

Sur les systèmes modernes le SID est stocké par défaut dans un cookie HTTP, ce qui représente un niveau de sécurité moyen du moment que le système de gestion de session ne prend pas en compte les variables GET/POST. Cependant, cette solution est vulnérable à une attaque de type Cross-Site Request Forgery (CSRF) et elle ne respecte pas la contrainte "Sans état" de l'architecture REST.

PS : Il est important de protéger ces cookies à l'aide des différents attributs que les navigateurs courants comprennent (Sans lien direct avec la vulnérabilité "Fixation de session") :

  • Secure
  • HttpOnly
  • SameSite

Regénérer (côté serveur) le SID à chaque changement de privilèges du contexte utilisateur[modifier | modifier le code]

Chaque changement de privilèges du contexte correspond généralement à une authentification où l'utilisateur fourni son secret. On retrouve de manière courante les pages d'authentification où le contexte passe de "privilèges d'un utilisateur non authentifié" à "privilèges d'un utilisateur authentifié" (D'autres cas, tel qu'une seconde authentification pour accéder à des fonctions d'administration applicative, sont à considérer).

Regénérer un SID permet de mitiger le risque qu'un utilisateur ait positionné/pris connaissance du SID au préalable de ce changement de privilèges et puisse ainsi profiter de ces nouveaux privilèges sans avoir eu à connaître le secret.

Fonction logout[modifier | modifier le code]

Expirer les anciens SIDs[modifier | modifier le code]

Détruire la session si le Referer est suspect[modifier | modifier le code]

Vérifier que les informations additionnelles sont cohérentes tout au long de la session[modifier | modifier le code]

User Agent[modifier | modifier le code]

Défense en profondeur[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Fixation_de_session&oldid=194468933 ».