2010-02-08 10 views
3

Nous venons d'effectuer des tests de pénétration sur une application que nous avons créée à l'aide d'ASP.NET MVC, et l'une des recommandations qui a été faite était que la valeur de AntiForgeryToken dans le formulaire pouvait être soumise de nouveau plusieurs fois. n'expire pas après un usage unique.Est-il possible de modifier la valeur AntiForgeryToken dans ASP.NET MVC après chaque vérification?

Selon le OWASP recommendations autour du modèle de jeton Synchronizer:

« En général, les développeurs ont besoin ne génèrent que ce jeton une fois pour la session en cours. »

C'est ainsi que je pense que le ASP.NET MVC AntiForgeryToken fonctionne.

Dans le cas où nous devons livrer bataille, est-il possible de faire en sorte que AntiForgeryToken régénère une nouvelle valeur après chaque validation?

+0

Je ne suis pas sûr que vous le vouliez, d'autant plus que de nombreux sites ont besoin de faire plusieurs appels AJAX à partir d'une seule page. Le modèle de jeton Synchronizer signifie que vous ne vérifiez pas seulement un jeton propre à l'utilisateur pour sa session (ce que fait AntiForgeryToken), mais que vous vérifiez également un jeton spécifique à la page que vous attendez de la requête. viens de. 'ViewState' n'a fait que cela dans les pages WebForms mais c'est plus compliqué dans MVC. – Keith

Répondre

7

Le jeton anti-falsification est juste un jeton anti-XSRF. En particulier, c'est et non un nonce à usage unique. Si vous avez besoin d'un nonce à usage unique pour votre application, vous ne pouvez pas utiliser le jeton anti-falsification à cette fin. Il n'y a pas de fonctionnalité intégrée pour cela.

-1

Peut-être que vous pouvez utiliser le AntiForgeryToken en utilisant the three parameters constructor. L'utilisation d'un salt est toujours recommandée, mais en limitant également le jeton par domaine et path, votre jeton sera plus sécurisé et unique par page.

Si vous n'avez pas de vulnérabilités XSS, ce problème ne va pas être un gros gâchis dans votre site web :) // Ai-je écrit cela? Sûrement je n'ai pas bien lu le problème.

À la votre!

+0

Merci, mais cela ne résout pas vraiment le problème des valeurs de jetons par requête. – jmcd

+0

Désolé, mais -1 pour _ "Si vous n'avez pas de vulnérabilités XSS, ce problème ne va pas être un gros désordre sur votre site web" _ car c'est tout simplement faux. Les attaques CSRF peuvent être complètement externes à votre application, elles ont juste besoin que l'utilisateur ait toujours un cookie d'authentification valide. – Keith