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?

Thorianite

This question has been answered by security experts here: security.stackexchange.com/questions/2120/… – Commute

@Commute did you notice that the link that you put on your comment is the same to the link in the top of the question? and that question has been asked by the same user? – Buoyancy

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.

Conscience

I agree your point about forging the referer header, but still.. if the referer header on a POST request is different - that means something is definitely wrong, right? :) – Thorianite

I'm not saying it's always going to protect me.. just another security boundary that might be useful – Thorianite

@Binder, think of the hacker sending an email to you pretending that this email is coming from your bank (known as phishing) telling you to click on a link in the email in order to update your account details for example. Since the user is authenticated on the real site, he could perform any action on behalf of this user on the actual site. This is the kind of attack that an anti forgery token is designed to prevent. – Conscience

More on the matter #6413313 – Chelton

If the attacker forges a login page and gets the credentials that way, what's the point of using the token to protect the real login page? The attacker would be able to login anyway using the userand password that he got. – Onceover

This answer is dangerously wrong. The tokens ARE necessary. See a simple example attack here: security.stackexchange.com/questions/2120/… – Commute