asp.net mvc 3 - When the use of a AntiForgeryToken is not required /needed?

Question

UPD: Same question asked on security.stackexchange.com and the answer I got is different. Please follow there, to get the correct answer!

I'm running a rather large site with thousands of visits every day, and a rather large userbase.

Since I started migrating to MVC 3, I've been putting the AntiForgeryToken in a number of forms, that modify protected data etc.

Some other forms, like the login / registration also use the AntiForgeryToken now, but I'm becoming dubious about their need there in the first place, for a couple reasons...

1. The login form requires the poster to know the correct credentials. I can't really think of any way an csrf attack would benefit here. Especially if I check that the request came from the same host (checking the Referrer header)
2. The AntiForgeryToken token generates different values every time the page is loaded.. If I have two tabs open with the login page, and then try to post them, the first one will successfully load. The second will fail with a AntiForgeryTokenException (first load both pages, then try to post them). With more secure pages - this is obviously a necessary evil, with the login pages - seems like overkill, and just asking for trouble :S

There are possibly other reasons why would one use/not use the token in their forms.. Am I correct in assuming that using the token in every post form is bad / overkill, and if so - what kind of forms would benefit from it, and which ones would definitely NOT benefit?

Answer 1

Anti forgery tokens are useless in public parts of the site where users are not yet authenticated such as login and register forms. The way CSRF attack works is the following:

1. A malicious user sets a HTML form on his site which resembles your site. This form could contain hidden fields as well.
2. He tricks one of your site users to visit his malicious url.
3. The user thinks that he is on your site, fills the form and submits it to your site.
4. If the user was already authenticated on your site the form submission succeeds and the unsuspecting user have deleted his account (or whatever you can imagine).

So you could use anti forgery tokens on authenticated parts of your site containing actions that could modify somehow the user state.

Remark: checking the Referer header for identifying that a request came from your site is not secure. Anyone can forge a request and spoof this header.