Fixation de session

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

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

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

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

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

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

Ne pas créer de contexte utilisateur côté serveur à partir d'un SID généré par l'utilisateur

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

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

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

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.

Voir aussi

• Empoisonnement de sessions
• Élévation des privilèges