In ASP.NET MVC 1.0, there is a new feature for handling cross site request forgery security problem:
<%= Html.AntiForgeryToken() %>
[ValidateAntiForge
You've ask a few unrelated problems:
This is used (presumably) to validate that each request is valid. So consider that someone tries to present a link to the page ?x=1
, if the token is not also passed, the request will be rejected. Further, it (may) prevent duplicate posting of the same item. If you click 'post' twice, the token will likely change (each request), and this case will be detected via something like:
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
I think the term for this (the attack it protects) is called "CSRF" (Cross-Site Request Forgery), these days.
Lots of info on the AntiForgeryToken here: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
This is to prevent a Cross-Site Request Forgery (CSRF). It's pretty standard behavior to click 'Save' sumbit a form and perform some action on the server, i.e. save a user's details. How do you know the user submitting the form is the user they claim to be? In most cases you'd use some cookie or windows based auth.
What if an attacker lures you to a site which submits exactly the same form in a little hidden IFRAME? Your cookies get submitted intact and the server doesn't see the request as any different to a legit request. (As gmail has discovered: http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/)
The anti-forgery token prevents this form of attack by creating a additional cookie token everytime a page is generated. The token is both in the form and the cookie, if the form and cookie don't match we have a CSRF attack (as the attacker wouldn't be able to read the anti-forgery token using the attack described above).
And what does the salt do, from the article above:
Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required.
Update: How is the token generated? Download the source, and have a look at the AntiForgeryDataSerializer, AntiForgeryData classes.