web-dev-qa-db-fra.com

Les formulaires de connexion ont-ils besoin de jetons contre les attaques CSRF?

D'après ce que j'ai appris jusqu'à présent, les jetons ont pour but d'empêcher un attaquant de falsifier un formulaire.

Par exemple, si un site Web comporte un formulaire dans lequel vous ajoutez des éléments à votre panier, un attaquant pourrait envoyer du spam dans votre panier avec des éléments que vous ne souhaitez pas.

Cela a du sens, car il pourrait y avoir plusieurs entrées valides pour le formulaire de panier. Tout attaquant devrait donc savoir quel article est vendu sur le site Web.

Je comprends le fonctionnement des jetons et ajoute la sécurité dans ce cas, car ils garantissent que l'utilisateur a bien rempli et appuyé sur le bouton "Soumettre" du formulaire pour chaque article ajouté au panier.

Cependant, les jetons ajoutent-ils de la sécurité à un formulaire de connexion utilisateur, qui requiert un nom d'utilisateur et un mot de passe?

Étant donné que le nom d'utilisateur et le mot de passe sont très uniques, l'attaquant devrait connaître ces deux éléments pour que la falsification de l'identifiant fonctionne (même si vous n'avez pas configuré les jetons), et s'il le savait déjà, il pourrait simplement ouvrir une session sur le site Web. lui-même. De plus, une attaque CSRF qui oblige l'utilisateur à se connecter lui-même n'aurait de toute façon aucun but pratique.

Est-ce que ma compréhension des attaques et des jetons CSRF est correcte? Et sont-ils inutiles pour les formulaires de connexion utilisateur comme je le suppose?

phptokencsrf
139
php_learner

Oui. En général, vous devez sécuriser vos formulaires de connexion contre les attaques CSRF comme tout autre.

Sinon, votre site est vulnérable à une sorte d'attaque de type "phishing domain". En bref, une page de connexion vulnérable aux CSRF permet à un attaquant de partager un compte d'utilisateur avec la victime.

La vulnérabilité se présente comme ceci:

  1. L'attaquant crée un compte hôte sur le domaine approuvé
  2. L'attaquant falsifie une demande de connexion dans le navigateur de la victime avec les informations d'identification de ce compte hôte
  3. L'attaquant incite la victime à utiliser le site de confiance, où elle peut ne pas se rendre compte qu'elle est connectée via le compte de l'hôte.
  4. L’attaquant a désormais accès à toutes les données ou métadonnées que la victime a "créées" (intentionnellement ou non) alors que son navigateur était connecté avec le compte Host

Comme exemple pertinent, considérons YouTube . YouTube permettait aux utilisateurs de voir un enregistrement de "leur" historique de visionnage, et leur formulaire de connexion était vulnérable à la CSRF! En conséquence, un attaquant pourrait configurer un compte avec un mot de passe ils savait connecter la victime à YouTube en utilisant ça compte - traquer les vidéos de la victime. était en train de regarder.

Il y a une discussion dans ce fil de commentaire qui implique que cela pourrait "seulement" être utilisé pour des violations de la confidentialité telles que celle-ci. Peut-être, mais pour citer la section dans article de CSRF de Wikipedia :

Login CSRF permet diverses attaques originales. Par exemple, un attaquant peut se connecter ultérieurement au site avec ses informations d'identification légitimes et afficher des informations confidentielles, telles que l'historique des activités, qui ont été enregistrées dans le compte.

L'accent est mis sur les "nouvelles attaques". Imaginez l'impact d'une attaque de phishing sur vos utilisateurs, puis imaginez que cette attaque de phishing fonctionne via le favori favori de l'utilisateur sur votre site! Le document lié au fil de commentaire susmentionné donne plusieurs exemples allant au-delà des simples attaques contre la vie privée.

109
natevw

Votre compréhension est correcte: l’intérêt de CSRF est que l’attaquant puisse créer une demande légitime à l’avance. Mais cela ne peut pas être fait avec un formulaire de connexion à moins que l'attaquant connaisse le nom d'utilisateur et le mot de passe de la victime. Dans ce cas, il existe des moyens plus efficaces d'attaquer (connectez-vous vous-même).

En fin de compte, la seule chose qu’un attaquant peut faire est de gêner vos utilisateurs en leur envoyant des spams ayant échoué leurs connexions, lorsque le système de sécurité peut verrouiller l’utilisateur pendant un certain temps.

12
Jon

La pré-connexion de validation CSRF n'a pas beaucoup de sens à mon humble avis.

Merci à @squiddle pour le lien: seclab.stanford.edu/websec/csrf/csrf.pdf , nous pouvons lire sur la toute première page:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Si vous tentez de vous connecter au préalable à la validation CSRF, vous donnez à un attaquant potentiel la possibilité de récupérer un code valide de votre site Web! Il/elle serait alors en mesure de republier le jeton contre l'objectif.

Peut-être qu'un attaquant pourrait alors essayer de deviner le nom d'utilisateur de votre site. Ce que j’ai fait, si l’adresse IP essaie de deviner, disons 10 noms d’utilisateurs sans succès, je l’ai simplement mise sur liste noire.

0
Patrice Gagnon

Oui, Les autres sites Web ne peuvent donc pas imiter votre formulaire de connexion! Aussi simple que cela.

Que peuvent-ils réaliser en le faisant?

  • Premièrement: vous ne voulez pas permettre cela.
  • Deuxièmement: même des cas d'échec très simples comme:
    • blocage de l'utilisateur en raison d'un mot de passe incorrect n no. des fois, peut être évité.
    • Les alertes de piratage Flase peuvent être évitées. etc.
0
mayankcpdixit