Une vue de rasoir unique contient plusieurs formulaires, chacun avec son propre appel à comme je le comprends, tous les deux Les jetons de falsification devraient être les mêmes. Pourquoi les valeurs sont-elles différentes? Ils devraient être identiques, car Ils sont envoyés dans la même réponse du serveur? @ html.antiforgeryToken ()
Le Documentation dit rien de l'appeler une fois seul.
6 Réponses :
Ce ne sont pas des commandes antiforgérytanks non égales .
Le MVC est généré uniqe pour toutes les commandes UNIQE.
SO Merci Buffjape, pour votre commentaire
Les mettre dans la même forme n'a fait aucune différence. Deux appels à @ html.antiforgeryToken () génèrent toujours des valeurs différentes.
Je pense que ces bugs de navigation provoqueront un tel problème parfois.
J'ai peur que cela ne fonctionne pas.
Le jeton antiforgery se déplace également dans le cookie de réponse, vous ne contiendrez donc que le dernier jeton, et donc le premier formulaire échouera toujours.
Vous pouvez essayer de faire quelque chose comme ceci: Je l'ai essayé et le même jeton est utilisé dans les deux formes.
Savez-vous pourquoi les valeurs sont différentes?
Parce que chaque appel génère un jeton différent, c'est-à-dire qu'il n'y a plus de creuser à ce sujet. Le MSDN dit "génère un champ de forme caché (jeton anti-falsification) validé lorsque le formulaire est soumis.", De sorte que "génère" stipule qu'un nouveau sera généré à chaque fois :)
Pourquoi quelqu'un voudrait-il que deux jetons anti-falsification différents?
Pourquoi les indexeurs des matrices INT32, pourquoi quelqu'un voudrait-il définir un tableau sur une longueur négative? Il devrait être uint32 ou uint16 :) Je ne dis pas que c'est juste ou faux, je dis seulement comment cela fonctionne selon la spécification.
Dans quelle spécification parlez-vous?
MSDN.MicRosoft .com / fr-nous / bibliothèque / ...
Cela ne spécifie pas le comportement lorsqu'il est utilisé plus d'une fois (que je dois faire). Mais il devrait sûrement générer un jeton anti-falhant valide à chaque fois?
La signification de "générer" est "Créer" ou "Produire". Cela implicitement au nom de la méthode qu'il créera une nouvelle chose. Sinon, la méthode serait nommée "getanttiforgerytoken" ou quelque chose de similaire.
Je suis juste intéressé par une réponse à ma question - pourquoi les valeurs sont-elles différentes?
Je vous ai déjà dit, car cette méthode "génère" un jeton chaque fois que vous l'appelez.
Et pourquoi ça fait ça?
Parce que si cela renvoyait le même jeton chaque fois que vous l'avez appelé, vous obtiendrez la même jeton sur différentes pages et que quelqu'un pouvait simplement la copier pour faire attaquer la CSRF. Si vous devez utiliser le jeton dans deux endroits différents (car votre page a deux formes), c'est la bonne réponse.
Eh bien, cela pourrait générer le même jeton chaque réponse, au lieu de chaque appel. Qu'est-ce qui ne va pas avec ça?
Rien n'est faux avec ça. Le développeur qui a rendu cet assistant a décidé de le générer une fois par appel. C'est l'API. C'était la décision du développeur (probablement beaucoup d'entre eux pesaient). Si vous souhaitez le comportement que vous décrivez, mettez-le en œuvre vous-même - c'est la beauté de la programmation!
Votre approche crée une vulnérabilité de sécurité, comme indiqué dans ma réponse fournie ci-dessous. Vous ne devez pas utiliser le même jeton pour chaque formulaire présent dans la page.
Je pense que vous êtes confus, nous ne parlons pas du même jeton sur tout le site (collecte de la page), mais le même jeton sur deux formes dans la même page (ressource HTML unique).
Non, je parle de la même ressource HTML avec diverses entités de formes.
Maintenant, cette chose fonctionne, c'est-à-dire si vous avez deux formulaires sur la même page et deux jetons, les deux formulaires peuvent être soumis avec succès.
Ils devraient sûrement être les mêmes, car ils sont envoyés dans la même réponse?
La réponse n'a rien à voir avec ça.
@ html.antiforgerytoken () est une méthode statique dehtmlhelper qui génère un jeton "fort> ajouté au HTML et au cookie de réponse. Vous appelez la méthode plusieurs fois pour que votre génération de jetons multiples.S'il n'a pas généré un jeton unique à chaque fois, il serait à peine sécurisé.
Désolé, je voulais dire la réponse non demande. Question modifiée, mais stands toujours - pourquoi générer deux jetons différents dans le HTML, quand il n'y a qu'un seul jeton dans le cookie?
@buffjape, je ne comprends pas pourquoi vous pensez appeler une méthode qui renvoie une valeur une valeur unique serait ou pourrait, toujours de retourner des valeurs en double - c'est tout simplement pas possible. Son non différent de créer une méthode qui a var a = guid.newguid; var b = guid.newguid; Les valeurs de A et b seront différentes. Par votre logique, ils devraient être les mêmes parce qu'ils sont dans la même méthode. Peut-être devriez-vous étudier le code source pour mieux comprendre
Si je comprends bien, le but de @ html.antiforgerytoken () est de mettre un jeton anti-falhant spécifique sur la page (afin qu'il correspond au cookie). Je sais déjà que ça ne fait pas ça. Ce que je cherche, c'est une explication rationnelle ...
@ html.antatiforgeryToken () génère essentiellement une valeur cryptée en fonction de la cookie et des données de formulaire. Donc, si vous déclarez et utilisez ceci @ html.antiforgeryToken () pour chacun qu'il générera deux différents _RequestvalidationToken. Mieux déclarer une variable globale @Token avec méthode @ html.antiforgeryToken () et créera un seul jeton pour chaque demande.
Les valeurs Si les formulaires avaient la même jeton, une fois qu'un attaquant connaissait la valeur de jeton pour une forme, il serait capable de tromper le serveur d'accepter les données envoyées par les autres formulaires, bien qu'ils n'aient pas été soumis par l'utilisateur, vaincre le Protection fournie par le jeton anticsRF.
L'objectif du jeton est de fournir un paramètre d'identification aléatoire, ce qui le rend très difficile pour l'attaquant de tromper l'application en pensant que c'était l'utilisateur connecté qui a rempli le formulaire.
Pour ceux qui ne connaissent pas les attaques CSRF, veuillez jeter un coup d'œil ici .
Alors, comment l'attaquant obtient-il le jeton d'une des formes?
Mitm serait l'un des moyens de voir ça. L'empoisonnement DNS serait un autre. Attaques qui défaitent "Politique" identique d'origine " ( Même le navigateur Android souffre de ce ) permettrait également à un attaquant de lire la page Contenu, lui permettant ainsi de lire le jeton via JavaScript.
Cela s'applique à une forme avec un jeton antiforgergie aussi. Avec une attaque MITM possible, votre jeton pariera visible de la réponse HTML et de l'en-tête Set-Cookie HTTP. Même si le MITM ne permettait pas d'intercepter du client au serveur, l'attaquant peut toujours modifier les données que vous envoyez sans avoir une connaissance préalable des jetons. De plus, si un attaquant doit lire la page que vous avez dans le navigateur, cela n'a pas d'importance si vous avez un jeton dans une forme ou deux jetons sous deux formes.
Le jeton utilisé une fois ne peut plus être utilisé ou je n'aurais pas besoin de le savoir avant. Réutiliser la même session, les jetons passés suffiraient à la vaincre. Ainsi, une fois que l'utilisateur l'utilise, l'attaquant ne peut plus le refaire. De plus, il existe différents types de MITM, MITM passif et actif. Parfois, il peut intercepter le trafic et le changer, il ne peut parfois pas regarder cela passer.
Si les jetons de sécurité ne sont pas invalidés lors de l'utilisation, tout ce qu'il faudrait pour créer mon propre utilisateur d'administration serait de rejouer la demande d'origine, changeant uniquement les informations d'identification choisies.
Je dois vérifier, ASP.NET MVC peut rejeter le deuxième poste de jeton. L'idée de la protection XSRF est que l'attaquant ne peut pas deviner le jeton sous la forme, si cela était possible, cette contre mesure sera totalement inutile. Donc, si un utilisateur est déjà vulnérable à une attaque MITM, XSRF est rendu inutile.
Eh bien, juste après ce paragraphe, Owasp déclare "d'améliorer encore la sécurité de la présente conception proposée, envisagez de randomiser le nom de paramètre de jeton CSRF et ou la valeur de chaque demande". Citant la réponse que vous avez liée, générant un jeton par page va casser une utilisation du client, car un seul jeton valide à la fois brisera l'application avec le problème du bouton arrière décrit. Avoir un jeton par forme leur permettra d'utiliser l'autre forme (tant qu'ils ne sont soumis qu'une seule fois). En outre, je suis en désaccord avec l'approche de la session, car cela me donne le temps de le bruteforcer (j'ai vu des personnes utilisant des séquences de 64 bits ...)
Quel est le point de générer un nouveau jeton pour chaque demande lors d'une session? Avez-vous validé si les jetons ne peuvent pas être valides pour une demande ultérieure? Si oui, pensez-vous que Asp.net gère lui-même tout ce genre de choses en mémoire?
Le jeton anti-falsification n'est pas comparé directement - le serveur doit d'abord sans récupérer et comparer les données protégées à l'intérieur. Avoir différentes jetons protégés ne signifie pas nécessairement qu'ils contiennent des données différentes.
Qu'est-ce que le Également, le Étant donné que toutes les données sont sérialisées, cryptées, alors codées, vous pouvez avoir des écarts dans le jeton protégé en raison de différences entre le system.web.helpers.antixrf.tokenvalidator est le SecurityToken à l'intérieur du antiforgerytoken instances. Cependant, ces instances contiennent également un champ supplémentaire , un nom d'utilisateur et un champ réclamant .
SecurityToken à l'intérieur du AntiforgeryToken est directement copié de la (Current si elle est valide, sinon le cookie antiforgery fraîchement généré) à l'intérieur antiforgeryworker .
inférieur data entre jetons ou
N'oubliez pas que l'approche de Vtortola crée une faille de sécurité, comme expliqué dans ma réponse ci-dessous. Les jetons doivent être différents.