Here I have simple MVC3 application with two form posts. To protect CSRF attack, I have used antiforgerytoken html helpers in both forms as per guidance here.
Here are m
I have no clear idea but i think there should be one value for "RequestVerificationToken_Lw" which will travel through for a single session. It will not create new value for each form.
The idea of the CSRF attack vector is this: I put up a malevolent form on my website https://fake-domain-that-looks-like-a-bank.com. I took the HTML and CSS from your site, so it looks exactly the same. I have a valid cert and all the logo bells and whistles. Now I trick users into visiting my site.
The user sees the usual form and does something. However, I replaced some of the inputs so they go nowhere, and I added some hidden fields so I control what the user does (involuntarily), like replace 'op=modify
with op=delete
. All his actions are backed by his (valid) auth cookie.
Now the anti forgery token protects the user because as the attacker, I can't add a valid hidden field that matches his cookie to my form. If I could read his cookies somehow, I could simply steal the auth token which would be a lot easier.
In MVC, the anti forgery token is bound to the logged on user's name. If you're using FormsAuthentication
and change the structure of user names, all users with existing cookies will run into trouble. As a side note: a common problem is that users who maintain two accounts run into AntiForgeryTokenExceptions
, you might want to handle that if it is a valid usage scenario.
Why does the cookie not change
If the cookie value changed with every request, multi-tab browsing would be a problem.
Why are cookie and form value different
MVC's cookies have internal structure, so their serialized version looks different. The actual security token that is inside should be identical. The serializer stores different information, depending on what information is present (user identity name, etc.). There is also a version byte, an indicator whether this is a session cookie, etc.
Gritty Details
If you want to know more, I recommend you clone the source via http://aspnetwebstack.codeplex.com/ and look at System.Web.WebPages\Helpers\AntiXsrf\TokenValidator.cs
, among other files. It's quite helpful to have the source around in any case.