what is the use of anti-forgery token salt ?

Question

in asp.net mvc 1.0, there is a new feature for handling cross site request forgery security problem:

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

and i found the token generated in html form keep changing every time a new form is rendered. I want to know how these token is generated? And when use some software to scan this site, it will report another security problem: Session fixed. why ? Since the token keep changed, how can this problem come ?

And there is another function, that is "salt" for the antiForgeryToken, but i really know what this used for, even through we don't use "salt" to generate the token, the token will changes all the time, so why have such function ?

Thanks in advance!

Answer 1

You've ask a few unrelated problems:

1. I don't know why your security software is reporting 'session fixed'. Try reading the documentation that comes with the report
2. The anti-forgery token:

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.

Answer 2

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.