les attaques de type csrf et double soumis cookie
Ci-dessous la citation est tirée de la http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
Lorsqu'un utilisateur visite un site, le site devrait générer un
(cryptographiques) pseudo-aléatoire de la valeur et de la définir comme un cookie
sur la machine de l'utilisateur. Le site devrait exiger que chaque soumission de formulaire
pour inclure cette pseudo-aléatoire de la valeur comme une forme de la valeur et aussi comme un
valeur du cookie. Lorsqu'une requête est envoyée au site, à la demande
ne doit être considéré comme valable que si la forme de la valeur et de la valeur du cookie
sont les mêmes. Si un attaquant envoie un formulaire sur le compte d'un utilisateur, il
ne peut modifier les valeurs de la forme. Un attaquant ne peut pas lire
les données envoyées par le serveur ou modifier la valeur du cookie, par la même origine
politique. Cela signifie que si un attaquant peut envoyer la valeur qu'il veut
avec le formulaire, il sera impossible de la modifier ou de lire la valeur stockée dans
le cookie. Puisque la valeur du cookie et la valeur doit être l'
de même, l'attaquant sera pas en mesure de soumettre un formulaire, à moins
il est capable de deviner la valeur pseudo-aléatoire.
La méthode ci-dessus empêche les attaques de type CSRF en comparant les psuedorandom valeur dans le cookie et la forme. Cependant pourquoi la valeur à retourner avec le formulaire ? Je suis en supposant à la fois la forme et le témoin ont la même valeur chiffrée qu'ils sont de retour sur le serveur. Et le serveur valide par le décryptage de la valeur.
Donc, même si la valeur n'est renvoyée uniquement par les cookies, le serveur peut le décrypter et vérifier la demande. A quoi sert le retour de la valeur chiffrée avec la forme?
OriginalL'auteur murtaza52 | 2012-07-17
Vous devez vous connecter pour publier un commentaire.
Des Cookies sont envoyés automatiquement à chaque requête, peu importe si la demande a été initiée par le site d'origine ou par un site tiers. C'est pourquoi un cookie, il ne suffit pas que chaque demande de le contenir.
Mais en ayant le jeton également dans la demande elle-même, un attaquant site ne peut pas générer des requêtes valides plus qu'ils ne peuvent pas mettre la main sur le jeton de l'utilisateur.
OriginalL'auteur Gumbo
Ok, donc décomposons le problème de questions atomiques pour mieux comprendre:
Qu'est-ce que ce CSRF ?
C'est un type d'application web de la vulnérabilité. Au niveau le plus élémentaire, la raison pour laquelle une CSRF est que le navigateur ne comprends pas comment distinguer si une action a été exécutée volontairement par l'utilisateur (comme par exemple en cliquant sur un bouton dans un formulaire, ou en cliquant sur un lien hypertexte, etc.) ou si l'utilisateur sans le savoir, a effectué l'action (comme, disons, l'utilisateur visite une page à partir du domaine, dire bad.com et bad.com envoyé une demande à good.com/some_action alors que l'utilisateur est déjà connecté à good.com).
Alors, quel est l'impact de CSRF
Maintenant, nous allons remplacer good.com ci-dessus avec facebook.com. Et supposons que, lorsque un utilisateur, connecté à facebook.com, poste un commentaire sur son mur, il y a une demande HTTP GET qui est envoyé, de la forme-dire
https: //facebook.com/postComment?userId=Abhinav_123& commentaire=HiIAmAbhinav.
Maintenant, supposons que l'utilisateur, alors qu'il est encore connecté à facebook.com, visite une page sur bad.com. Maintenant bad.com appartient à un attaquant où il a codé la suite bad.com:
Maintenant, dès que le navigateur de l'utilisateur charge le contenu de cette page bad.com, une demande est envoyée à facebook.com comme :
https: //facebook.com/postComment?userId=Abhinav_123& commentaire=I_AM_AN_IDIOT
parce que le navigateur essaye de rendre la balise img. Pour ce faire il doit extraire la ressource spécifiée dans src et par conséquent, il envoie le au-dessus de requête HTTP GET. Donc, essentiellement, l'attaquant pourrait soumettre une demande à facebook.com pour le compte de l'utilisateur sans le lui fait savoir.
Maintenant ce qui pourrait avoir empêché cette attaque ?
Si seulement il y avait un moyen de déterminer si la demande a été faite par l'utilisateur intentionnellement. Pour ce faire, l'anti-CSRF token est venu dans l'image. C'est juste un hasard, chaîne unique généré par le serveur (facebook.com dans notre exemple ci-dessus), puis envoyé à l'utilisateur et de définir dans le navigateur de l'utilisateur dans un cookie. Maintenant, pour chaque demande la participation de quelques sensibles à l'action (comme l'affichage d'un commentaire dans notre facebook exemple ci-dessus), le navigateur envoie cette chaîne aléatoire aussi avec la requête et le serveur avant d'effectuer l'action serait de vérifier si la chaîne de caractères aléatoires est l'un, qu'il avait envoyé au navigateur ou pas.
L'idée est que cette chaîne aléatoire de ne pas être connu de l'attaquant. Donc, même si l'attaquant crée une img src comme indiqué ci-dessus, et les visites de l'utilisateur bad.com l'action (de l'envoi d'un commentaire dans notre exemple ci-dessus) ne sera pas exécutée, car pour l'action à effectuer, en dehors de l'URL, une chose supplémentaire est également nécessaire, qui est la chaîne de caractères aléatoires, que l'attaquant n'a pas.
Mais la définition de cette chaîne aléatoire dans un cookie a de nouveau une ÉNORME faille
Raison de la façon dont les cookies sont conçus et la manière dont les navigateurs gérer les cookies, la définition de cette chaîne aléatoire (l'anti-CSRF token) dans le cookie ne servira pas notre but. De par leur conception, les cookies sont automatiquement envoyées au serveur à chaque requête que le client apporte à ce serveur (il suffit de mettre, et les détails omis pour des raisons de simplicité. Pour plus de détails consultez : RFC2965)
Ainsi, dans notre exemple ci-dessus, l'attaquant n'a pas vraiment besoin de connaître la chaîne de caractères aléatoires. La publication de commentaires d'action sera encore terminé, car dès que l'utilisateur visite bad.com et charge le post de commentaire l'URL (comme expliqué ci-dessus) le hasard anti-CSRF token (présent dans le cookie) sera automatiquement jointe à la requête.
Alors, quelle est la solution alors ?
Au lieu de mettre de l'anti-CSRF token dans le cookie, le serveur (facebook.com) doit mettre comme paramètre caché dans un formulaire et le faire lors de la demande de l'utilisateur pour l'affichage d'un commentaire de cette forme (la tenue de l'anti-CSRF token) doivent également être affichées.
Maintenant, l'attaquant n'a aucun moyen de l'exécution du présent sensibles à l'action au nom de l'utilisateur (sauf si il a en quelque sorte découvre au hasard des anti-CSRF token lui-même)
Maintenant pour en venir au problème de connexion CSRF et double soumettre cookie
Un grand nombre de fois les sites web se protéger contre les attaques CSRF par le déploiement d'une certaine forme de anti_CSRF jeton d'architecture. Mais beaucoup de fois les sites web ne se soucient pas beaucoup sur la protection de leur formulaire de connexion contre les attaques CSRF. Pourquoi ? - Parce que même un formulaire de connexion est vulnérable à CSRF et un attaquant tente de l'exploiter par le cadrage, une demande de connexion à good.com (facebook.com) par l'intermédiaire de son domaine (bad.com), l'utilisateur aura toujours besoin de saisir ses informations d'identification valides pour obtenir loggedinto facebook.com. Ces informations sont disponibles uniquement avec le véritable utilisateur et non l'agresseur et, partant, l'attaquant peut pas encadrer avec succès une demande de connexion.
Donc, qu'est-ce que l'attaque occasion pour l'attaquant ici ?
L'attaquant peut créer son propre compte avec facebook.com. Il dispose maintenant d'un ensemble valide d'informations d'identification pour lui-même. Maintenant, il encadre la demande de connexion à facebook.com avec ses identifiants de connexion, et sur son domaine (bad.com).
Maintenant, lorsque l'utilisateur visite la page, bad.com l'utilisateur est connecté sur mon compte. J'ai attaqué comme un peut plus tard en voir de toutes les activités effectuées par l'utilisateur sur le compte éventuellement la divulgation d'informations sensibles (comme le disent les demandes d'amis envoyées si l'utilisateur choisit d'envoyer de nouvelles demandes d'amis, les messages envoyés à quelqu'un, encore une fois, si l'utilisateur n'a donc après la connexion à mon compte. Toutes ces possibilités dépendent de comment convaincre l'utilisateur qu'il a ouvert une session sur ce compte propre, ce qui, là encore, l'attaquant peut prendre le soin de faire sa propre facebook page regarde aussi proche de la victime que possible à la con de lui en lui faisant croire qu'il est de son compte)
Alors maintenant, qu'est-ce que la technique d'atténuation contre cela?
C'est une double soumettre cookie que nous avons besoin maintenant, ici.
Qu'est-ce exactement est-ce à dire
Comment permet-elle d'atténuer l'attaque ?
Que par la mise en œuvre du principe d'une double cookie, lorsqu'un utilisateur anonyme (pas de l'utilisateur connecté) visites à une page de connexion au serveur définit un cookie avec une certaine chaîne de caractères aléatoires dans le navigateur de l'utilisateur et définit également la même dans les paramètres de la requête ainsi (dire une forme cachée de champ). Lorsque l'utilisateur soumet la demande de connexion, ces choses sont soumis avec la demande - l'identification de l'utilisateur, la chaîne aléatoire dans le champ de formulaire masqué et le cookie de la tenue de la chaîne de caractères qui est envoyé automatiquement bien sûr).
Maintenant un attaquant aura accès à ses propres informations d'identification, la chaîne de caractères aléatoires définies par le serveur dans le témoin et dans le champ de formulaire masqué pour l'attaquant. Quand l'attaquant envoie fabriqués à la demande de connexion de l'utilisateur (la victime), et que l'utilisateur tente de faire cette demande, l'utilisateur est toujours pas connecté et est un utilisateur anonyme pour le serveur jusqu'à présent. Afin que le serveur de définir un cookie sur le navigateur de l'utilisateur avec une autre (de l'attaquant) valeur aléatoire. Maintenant, lorsque l'utilisateur en fait la demande de connexion par le biais de l'attaquant conçu lien, la demande doit contenir l'attaquant des informations d'identification, l'attaquant de la chaîne aléatoire dans le champ de formulaire masqué, mais l'utilisateur de la chaîne aléatoire dans le cookie (en provenance du navigateur de l'utilisateur). Maintenant, quand cette demande atteint le serveur, les chaînes aléatoires dans le cookie et le champ de formulaire masqué ne correspondent pas, et, donc, être considérée comme une exception et traités en conséquence.
Donc ce la raison pour le retour de la valeur chiffrée avec la forme. Espérons qu'il efface le concept.
Bonjour @Yuri, si pourquoi est anti CSRF mécanismes encore nécessaire en dépit de la SCRO, est ce que vous essayez de demander, permettez-moi de prendre une chance et d'essayer d'expliquer. Aussi loin que de simples demandes dans les catégories de documents sont concernés (sans pré-vol) CSRF est encore possible. Pas si simple demande (avec pré-vol), il dépend vraiment de la façon la SCRO politiques sont configurés. Parce que, la pré-vol (OPTIONS) la demande peut encore être effectué par un adversaire par l'exploitation d'une CSRF bug, et puis cela dépend de ce que le serveur répond à la réponse. Si le serveur est trop permissive, l'attaque serait encore passer.
1) "aussi loin Que de simples demandes dans les catégories de documents sont concernés (sans pré-vol) CSRF est encore possible" - entendez-vous les questions les plus simples décrites ici developer.mozilla.org/en-US/docs/Web/HTTP/CORS ? Si oui, pré-vol demandes sont nécessaires uniquement pour les anciens serveurs ou des serveurs sous développement avec l'ancien code(c'est expliqué là stackoverflow.com/questions/15381105/...). 2) "Si le serveur est trop permissive" c'Est vraiment très dur à configurer correctement la scro paramètres sur le serveur?
OriginalL'auteur qre0ct