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 très futée en sécurité.

Mallory est de sortie pour obtenir l'argent de Mallory 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</code> 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 controle mechant.example.com</code attire Alice sur son site.
3. La visite d'Alice sur mechant.example.com</code 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 accepter les SIDs des variables GET/POST

La meilleure solution: confirmer l'identité

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.

Solution: conserver les SIDs dans des cookies HTTP

Solution: utiliser des SID SSL/TLS

Regénérer le SID à chaque requète

Accepter uniquement les SIDs généré côté serveur

Fonction logout

Expirer les anciens SIDs

Détruire la session si le Referer est suspect

Vérifier que les informations additionnelles sont cohérentes tout au long de la session

User Agent

Défense en profondeur

Voir aussi

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