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

161

D'après ce que j'ai appris jusqu'à présent, le but des jetons est d'empêcher un attaquant de falsifier une soumission de formulaire.

Par exemple, si un site Web avait un formulaire qui saisissait des articles ajoutés à votre panier, et qu'un attaquant pourrait spammer votre panier avec des articles que vous ne voulez pas.

Cela a du sens car il pourrait y avoir plusieurs entrées valides pour le formulaire de panier, tout ce que l'attaquant aurait à faire est de connaître un article que le site Web vend.

Je comprends comment les jetons fonctionnent et ajoutent de la sécurité dans ce cas, car ils garantissent que l'utilisateur a effectivement rempli et appuyé sur le bouton «Soumettre» du formulaire pour chaque article ajouté au panier.

Cependant, les jetons ajoutent-ils une sécurité à un formulaire de connexion utilisateur, qui nécessite 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 les deux pour que la falsification de connexion fonctionne (même si vous n'avez pas configuré de jetons), et si un attaquant le savait déjà, il pourrait simplement se connecter au site Web. lui-même. Sans oublier qu'une attaque CSRF qui oblige l'utilisateur à se connecter n'aurait de toute façon aucun but pratique.

Ma compréhension des attaques CSRF et des jetons est-elle correcte? Et sont-ils inutiles pour les formulaires de connexion des utilisateurs comme je le soupçonne?

php token csrf

— php_learner
source

Ils peuvent détourner votre routeur, car vous utilisez probablement le mot de passe par défaut à ce sujet, et il n'est pas protégé par CSRF pour la connexion.

— AbiusX

Oui, les autres sites Web ne peuvent donc pas imiter votre formulaire de connexion. Que peuvent-ils réaliser en le faisant? D'abord, vous ne voulez pas permettre cela. Deuxièmement: cas d'échec très faciles comme le blocage de l'utilisateur en raison d'un mot de passe incorrect n non. de temps, peut être évité.

— mayankcpdixit

126

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 "phishing de domaine de confiance". En bref, une page de connexion vulnérable au CSRF permet à un attaquant de partager un compte utilisateur avec la victime.

La vulnérabilité se déroule comme ceci:

L'attaquant crée un compte hôte sur le domaine de confiance
L'attaquant forge une demande de connexion dans le navigateur de la victime avec les informations d'identification de ce compte hôte
L'attaquant incite la victime à utiliser le site de confiance, où elle peut ne pas remarquer qu'elle est connectée via le compte hôte
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 hôte

Comme exemple pertinent, considérons YouTube . YouTube a permis aux utilisateurs de voir un enregistrement de "leur propre" historique de visionnage, et leur formulaire de connexion était vulnérable au CSRF! Ainsi, un attaquant pouvait créer un compte avec un mot de passe qu'il connaissait, connecter la victime à YouTube à l'aide de ce compte - traquant les vidéos que la victime regardait.

Il y a une discussion dans ce fil de commentaires qui implique qu'il ne pourrait "que" être utilisé pour de telles violations de la vie privée. Peut-être, mais pour citer la section de l'article CSRF de Wikipedia :

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

Accent mis sur les «attaques nouvelles». Imaginez l'impact d'une attaque de phishing contre vos utilisateurs, puis imaginez cette attaque de phishing fonctionnant via le propre signet de confiance de l'utilisateur vers votre site! L'article lié dans le fil de commentaires susmentionné donne plusieurs exemples qui vont au-delà de simples attaques contre la confidentialité.

— natevw
source

6

Comment la protection CSRF aide-t-elle? Y a-t-il quelque chose qui empêche l'attaquant de demander son propre jeton CSRF et de simplement se soumettre avec cela? Puisqu'aucune session authentifiée n'existe, il n'y a aucune raison pour que le serveur Web préfère un jeton à un autre.

— A. Wilson

2

"Y a-t-il quelque chose qui empêche l'attaquant de demander son propre jeton CSRF et de se soumettre avec ça?" - Oui! C'est toute l'hypothèse derrière la logique de prévention CSRF. Les navigateurs ont permis / permettent une soumission de formulaire pour cibler une autre origine, mais ils n'ont jamais [intentionnellement] permis à JS de lire des données sur plusieurs sites, sauf maintenant via opt-in CORS. Sauf si vous avez mal configuré CORS, l'attaquant peut déclencher une soumission de formulaire (qui peut inclure un jeton CSRF existant dans les cookies ) mais n'a aucun moyen de connaître le jeton pour envoyer la deuxième copie requise (par exemple dans le corps / les en-têtes). Le code CSRF sera donc rejeté.

— natevw

7

Je pense que votre dernier commentaire est faux (vous avez mal compris ce que disait A. Wilson). Nous disons qu'un attaquant peut charger http://good.com/login.htmldans un client, analyser le jeton CSRF imbriqué, puis publier http://bad.com/login.htmlqui contient un formulaire modifié qui soumet son nom d'utilisateur, son mot de passe et son jeton indépendamment de ce que la victime tape. CORS ne s'applique pas parce que vous ' J'ai deux clients distincts: l'attaquant et la victime. Donc, pour réitérer la question: la protection CSRF fonctionne-t-elle vraiment pour les formulaires de connexion?

— Gili

8

Oui, CSRF protégera un formulaire de connexion contre la falsification de demandes intersites . Un jeton CSRF approprié est unique sur le plan cryptographique chaque fois qu'il est généré. Bien sûr, l'attaquant peut obtenir un jeton lui- même, mais il ne correspondra toujours PAS au cookie [potentiellement non défini] de la victime dans son navigateur, et l'attaquant n'a aucun moyen de définir ledit cookie sans compromettre une page sur le bon domaine. (Votre exemple semble un peu confus entre CSRF et une sorte d'attaque de phishing étrange, donc je ne suis pas sûr si je réponds à votre question réelle ...)

— natevw

3

Je me trompe peut-être, mais il semble qu'il y ait une menace importante si l'utilisateur fait accidentellement quelque chose lié à l'achat d'articles. Par exemple, un attaquant incite l'utilisateur à se connecter à un site Web, et l'utilisateur procède à l'achat d'articles sans se rendre compte qu'ils sont dans un autre compte (pensez à Amazon ou similaire). Maintenant, l'attaquant a accès aux informations de paiement enregistrées, peut rediriger les achats, etc.

— you786

14

Votre compréhension est correcte - tout l'intérêt de CSRF est que l'attaquant peut forger une demande d'apparence légitime à l'avance. Mais cela ne peut pas être fait avec un formulaire de connexion à moins que l'attaquant ne connaisse le nom d'utilisateur et le mot de passe de la victime, auquel 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 envoyant du spam aux échecs de connexion, lorsque le système de sécurité peut verrouiller l'utilisateur pendant un certain temps.

— Jon
source

2

Wow Réponse super rapide! Merci beaucoup! Maintenant, je peux continuer à créer mon site Web en toute confiance.

— php_learner

21

Le login CSRF peut toujours être utilisé pour des attaques contre la vie privée de l'utilisateur seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: C'est un article assez intéressant, merci pour le lien. Mais cela dépend de la connexion de l'utilisateur avec un compte sous le contrôle de l'attaquant et suppose que l'utilisateur ne se rendra pas compte que quelque chose ne va pas et suppose que l'utilisateur va produire des informations sensibles qui seront ensuite stockées sur le serveur. Donc à mon humble avis, il est tout à fait moins sérieux que CSRF «classique».

— Jon

6

@Jon Oui, cela peut être moins grave, mais en fin de compte, cela peut être plus qu'un simple inconvénient, à savoir une atteinte à la vie privée. Chaque service doit définir lui-même son modèle de menace et le gérer en conséquence. Pour ce faire, vous devez au moins être conscient des menaces possibles. C'est pourquoi j'ai ajouté mes 2 cents.

— squiddle

1

Pourriez-vous expliquer comment ils le feraient "En fin de compte, la seule chose qu'un attaquant puisse faire est de déranger vos utilisateurs en envoyant du spam aux échecs de connexion, alors que le système de sécurité pourrait verrouiller l'utilisateur pendant un certain temps."

— samthebest

0

Oui , donc les autres sites Web ne peuvent 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 nno. de temps, peut être évité.
- Les alertes de piratage Flase peuvent être évitées. etc.

— mayankcpdixit
source

La plupart de ces points sont incorrects. L'attaquant peut créer un formulaire de connexion, obtenir les informations d'identification de l'utilisateur, charger le formulaire de connexion (avec le jeton csrf) et publier les trois informations sur la cible. CSRF ne l'empêche pas.

— Snapey

Les navigateurs @Snapey ne permettent généralement pas à JS de lire les données CSRF. En utilisant JS, vous ne pouvez pas imiter la demande de soumission de formulaire authentique.

— mayankcpdixit

Le jeton csrf est souvent transmis au client pour être utilisé par javascript. Je ne parle pas des cors que je prends à propos de l'attaquant qui demande simplement le formulaire de connexion et les informations d'identification. @mayankcpdxit. Vous semblez impliquer que csrf empêche le bourrage d'informations d'identification, ce qu'il ne fait pas.

— Snapey

Théoriquement, oui, cela ne peut pas empêcher. Mais il n'est pas possible d'automatiser le remplissage des informations d'identification après CSRF si vous arrêtez de charger les formulaires CSRF dans les iframes et arrêtez d'autoriser la demande d'origine croisée.

— mayankcpdixit

-1

La validation CSRF avant la connexion n'a pas trop de sens à mon humble avis.

Merci à @squiddle pour le lien: seclab.stanford.edu/websec/csrf/csrf.pdf , on peut 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 valider la CSRF avant la connexion, 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 en échouant à l'objectif.

Peut-être qu'un attaquant peut alors essayer de deviner un nom d'utilisateur de votre site. Ce que j'ai fait, si l'adresse IP essaie de deviner 10 noms d'utilisateur sans succès, je la liste simplement en noir.

— Patrice Gagnon
source