Test de vulnérabilité CSRF

L’attaque par demande de site croisé (CSRF) consiste à utiliser la logique généralement acceptée des navigateurs Internet pour gérer la session utilisateur sur les pages ouvertes. La norme est que l’utilisateur ne peut avoir qu’une seule session active dans l’application Web qu’il utilise actuellement. Chaque nouvel onglet du navigateur utilisera automatiquement les cookies de l’utilisateur déjà connecté. L’attaquant utilise ce fait le plus souvent en envoyant à sa victime un lien spécialement préparé lorsque vous cliquez sur l’action (par exemple, changer le mot de passe) sur la page où la victime a une session active.

La protection contre ce type d’attaque consiste le plus souvent à ajouter un paramètre unique et imprévisible, au moins par session, qui est collé comme variable aux demandes sensibles (par exemple, changer le mot de passe, ajouter un nouvel utilisateur) et dont le serveur vérifie la validité. Un attaquant ne connaissant pas la valeur de ce jeton n’est pas en mesure de générer une demande que le serveur ne rejettera pas en raison de la non-conformité du jeton antiCSRF.

Dans l’une des applications que j’ai étudiées, j’ai découvert la possibilité de mener plusieurs attaques de type CSRF. Un exemple consiste à préparer une page conçue appropriée lorsque l’utilisateur connecté entre en fonction de sa demande de changement de mot de passe. Le code de cette page est présenté ci-dessous, avec les paramètres sélectionnés pour l’utilisation du nouveau mot de passe. Notez que la ligne sélectionnée sur l’impression ci-dessous indique le code qui définit le champ de formulaire d’entréeoù le nouveau mot de passe a été défini.

La demande envoyée automatiquement à l’aide des sessions de l’utilisateur qui est entré sur la page remplacée ressemble à ce qui suit :

En réponse, l’application confirme le changement de mot de passe, comme le montre la capture d’écran suivante :