Il existe de nombreux types de vulnérabilités de sécurité trouvées sur les sites Web, une intéressante est appelée « fixation de session ». La fixation de session est un problème où un attaquant peut influencer l'identifiant de session, c'est-à-dire l'identifiant de session d'un utilisateur, puis l'utiliser pour accéder à son compte. Ce type de vulnérabilité peut fonctionner de deux manières, il peut permettre à l'attaquant de trouver ou de définir l'identifiant de session d'un autre utilisateur.
Comment une attaque de fixation de session est effectuée
L'identifiant de session d'un utilisateur est souvent un élément clé de l'authentification sur le site Web et est dans de nombreux cas la seule donnée qui identifie l'utilisateur spécifique connecté. Le problème avec ceci est que si un attaquant peut définir ou apprendre l'ID de session d'un autre utilisateur, il peut utiliser le jeton de session et ensuite être en mesure d'agir en tant qu'utilisateur.
En règle générale, cela se fait en incitant un utilisateur à cliquer sur un type de lien de phishing. Le lien lui-même est tout à fait légitime mais inclut une variable qui définit un identifiant de session spécifié. Si l'utilisateur se connecte ensuite avec l'ID de session et que le serveur ne lui attribue pas de nouvel ID de session sur login, l'attaquant peut simplement définir son identifiant de session pour qu'il soit le même et avoir accès à celui de la victime. Compte.
L'attaquant peut également découvrir l'identifiant de session de la victime s'il apparaît dans une URL. Par exemple, si l'attaquant peut tromper la victime en lui envoyant un lien et qu'il inclut l'ID de session de la victime, l'attaquant peut utiliser l'ID de session pour accéder au compte de la victime. Dans certains cas, cela peut arriver complètement par accident. Par exemple, si l'utilisateur copie l'URL avec l'identifiant de session et le colle à un ami ou dans un forum, tout utilisateur qui suit le lien sera connecté avec le compte de l'utilisateur.
Corrections de fixation de session
Il existe quelques solutions à ce problème et, comme toujours, la meilleure solution consiste à mettre en œuvre autant de correctifs que possible dans le cadre d'une stratégie de défense en profondeur. La première solution consiste à modifier l'identifiant de session de l'utilisateur lorsqu'il se connecte. Cela empêche un attaquant de pouvoir jamais influencer l'ID de session d'un utilisateur connecté. Vous pouvez également configurer le serveur pour qu'il accepte uniquement les identifiants de session qu'il a générés et qu'il rejette explicitement tous les identifiants de session fournis par l'utilisateur.
Le site Web doit être configuré pour ne jamais placer de détails utilisateur sensibles tels que l'ID de session dans l'URL et doit le placer dans un paramètre de demande GET ou POST. Cela empêche l'utilisateur de compromettre accidentellement son propre identifiant de session. En utilisant à la fois un identifiant de session et un jeton d'authentification distinct, vous doublez la quantité d'informations dont l'attaquant a besoin pour obtenir et empêchez les attaquants d'accéder aux sessions avec des identifiants de session connus.
Il est essentiel que tous les identifiants de session valides pour un utilisateur soient invalidés lorsque le bouton de déconnexion est cliqué. Il est possible de régénérer l'identifiant de session à chaque demande, si les identifiants de session précédents sont invalidés, cela empêche également les attaquants d'utiliser l'identifiant de session connu. Cette approche réduit également considérablement la fenêtre de menace si un utilisateur divulgue son propre identifiant de session.
En permettant plusieurs de ces approches, une stratégie de défense en profondeur peut éliminer ce problème en tant que risque de sécurité.