à quoi sert le sel anti-contrefaçon?

Question

Dans ASP.NET MVC 1.0, une nouvelle fonctionnalité permet de gérer le problème de sécurité de falsification de requêtes entre sites:

 <%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

J'ai constaté que le jeton généré au format HTML continuait à changer chaque fois qu'un nouveau formulaire était rendu.

Je veux savoir comment ces jetons sont générés? Et lorsque vous utilisez un logiciel pour analyser ce site, un autre problème de sécurité est signalé: Session fixed. Pourquoi? Depuis que le jeton a changé, comment résoudre ce problème?

Et il existe une autre fonction, à savoir "sel". pour antiForgeryToken , mais je sais vraiment à quoi cela sert, même si nous n'utilisons pas "salt". pour générer le jeton, le jeton changera tout le temps, alors pourquoi avoir une telle fonction?

Answer 1

Beaucoup d’informations sur le AntiForgeryToken ici: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/ / a>

Ceci permet d'éviter une falsification de requête intersite (CSRF). C’est un comportement assez classique de cliquer sur "Enregistrer" pour enregistrer un formulaire et effectuer une action sur le serveur, c’est-à-dire enregistrer les détails d’un utilisateur. Comment savez-vous que l'utilisateur qui soumet le formulaire est l'utilisateur qu'il prétend être? Dans la plupart des cas, vous utiliseriez un cookie ou une authentification Windows.

Et si un attaquant vous attirait vers un site qui soumet exactement le même formulaire dans un petit IFRAME caché? Vos cookies sont soumis intacts et le serveur ne voit pas la demande différente de la demande légitime. (Comme Gmail a découvert: http: //www.gnucitizen. org / blog / google-gmail-e-mail-piratage-technique / )

Le jeton anti-contrefaçon empêche cette forme d'attaque en créant un jeton cookie supplémentaire chaque fois qu'une page est générée. Le jeton est à la fois sous la forme et dans le cookie. Si la forme et le cookie ne correspondent pas, nous avons une attaque CSRF (l'attaquant ne pourrait pas lire le jeton anti-falsification en utilisant l'attaque décrite ci-dessus).

Et que fait le sel, extrait de l'article ci-dessus:

  

Salt est juste une chaîne arbitraire. Une valeur de sel différente signifie qu'un jeton anti-contrefaçon différent sera généré. Cela signifie que même si un attaquant parvient à se procurer un jeton valide, il ne peut & # 8217; le réutiliser dans aucune autre partie de l'application où une valeur de sel différente est requise.

Mise à jour: Comment le jeton est-il généré? Téléchargez le source . , et jetez un coup d’œil aux classes AntiForgeryDataSerializer, AntiForgeryData.

Answer 2

Vous avez posé quelques problèmes indépendants:

1. Je ne sais pas pourquoi votre logiciel de sécurité signale "session fixe". Essayez de lire la documentation fournie avec le rapport
2. Le jeton anti-contrefaçon:

Ceci est utilisé (vraisemblablement) pour valider que chaque requête est valide. Considérez donc que quelqu'un essaie de présenter un lien vers la page ? X = 1 , si le jeton n'est pas également transmis, la demande sera rejetée. En outre, cela (peut) empêcher l’enregistrement en double du même article. Si vous cliquez deux fois sur "post", le jeton changera probablement (à chaque demande) et ce cas sera détecté via quelque chose comme:

Session["nextToken"] = token;
WriteToken(token);

...

if( !Request["nextToken"] == Session["nextToken"] ){
    ...
}

// note: order in code is slightly different, you must take the token
// before regenerating it, obviously

Je pense que le terme utilisé pour désigner cette attaque (l'attaque qu'il protège) s'appelle "CSRF". (Requête inter-site), ces jours-ci.