Formulaire de connexion HTML sans protection CSRF
Nous avons récemment reçu un rapport de vulnérabilité indiquant que l'un de nos formulaires HTML dans l'une des applications internes n'est pas protégé par CSRF. Au début, nous ne pouvions pas le reproduire immédiatement manuellement en utilisant les outils de développement en regardant les en-têtes et les cookies trouvant le XSRF-TOKEN présent dans les en-têtes.
Mais ensuite, nous avons reproduit le problème dans l'onglet navigation privée ou dans un navigateur "propre". Le problème ne concernait que la toute première tentative de connexion. Il semble qu'au moment où la première demande de connexion est publiée, le client n'a pas encore le jeton XSRF puisqu'il s'agit de la toute première interaction entre le client et le serveur.
Est-ce toujours une vulnérabilité et doit être corrigé s'il n'est reproduit que lors de la toute première demande de connexion? Comment ce type de problème est-il généralement résolu? Il doit probablement y avoir une sorte d'interaction client-serveur avant la soumission du formulaire de connexion afin que le client obtienne au préalable le jeton XSRF.
Cela s'appelle "Login CSRF" et est en effet un vrai problème que vous devez résoudre.
Bien qu'un attaquant ne puisse pas tromper une victime pour se connecter à son propre compte puisque l'attaquant ne connaît pas les informations d'identification de l'utilisateur, un attaquant pourrait tromper la victime en se connectant au compte de l'attaquant. Cela peut être utilisé pour inciter une victime à céder des informations à l'attaquant, car la victime pense qu'elle est connectée en tant que telle.
C'est en effet quelque chose qui a été utilisé à des fins malveillantes. De Détecter :
Paypal était autrefois vulnérable à la connexion CSRF et l'attaquant pouvait obliger un utilisateur à se connecter au compte Paypal de l'attaquant. Lorsque l'utilisateur a ensuite payé quelque chose en ligne, il a inconsciemment ajouté sa carte de crédit au compte de l'attaquant.
Un autre exemple, moins évident, est un CSRF de connexion qui existait autrefois dans Google, qui a permis à l'attaquant de forcer l'utilisateur à se connecter au compte de l'attaquant et de récupérer plus tard toutes les recherches que l'utilisateur avait effectuées lors de sa connexion.
Même si vous ne pouvez penser à aucun moyen de tirer parti de votre site, un attaquant intelligent pourrait le faire. Il n'y a aucune raison de le permettre.
Alors, comment le bloquez-vous? Même si la première action que l'utilisateur entreprend est de se connecter, la première interaction qu'il a avec le serveur est de récupérer la page de connexion. C'est l'occasion d'attribuer un jeton CSRF. Vérifiez-le ensuite sur toutes les demandes qui modifient l'état du serveur, y compris la connexion.
(Une vulnérabilité liée de manière tangentielle est la fixation de session. Le fait d'avoir des jetons CSRF qui persistent après la connexion peut vous exposer à cela, alors lisez-le avant de commencer à implémenter une solution.)
Comme expliqué par Anders , le manque de csrf sur le formulaire de connexion est une vulnérabilité sérieuse. Il existe probablement de nombreux vecteurs d'attaque, mais voici une autre possibilité qui me vient à l'esprit. Dans le pire des cas, cela pourrait conduire au vol des informations d'identification de la victime.
Si l'attaquant a un self-xss persistant sur son compte, amener l'utilisateur à se connecter sur son compte pourrait être suffisant pour le déclencher, lui permettant ainsi de modifier la page source entière et d'afficher soit un formulaire d'inscription soit un formulaire de connexion.
Voici un exploit sur AirBnb exploitant l'auto-xss plus le manque de jeton csrf sur le formulaire de connexion.