Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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...

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) 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?

P.S. This question is also asked on StackOverflow, but I'm not entirely convinced.. I thought I'd ask it here, for more security coverage

share|improve this question
    
Has there been any update to this question? Regarding the issue with multiple concurrent login pages being submitted? My current solution is to remove the anti forgery token from the login page. –  Marko Mar 27 '12 at 16:50
    
I don't think that should be a problem anymore.. I've got the anti forgery token on our login page, and it's not a problem anymore. –  Artiom Chilaru Mar 28 '12 at 13:54
    
I've also made sure that my web.config has a machineKey specified, which ruled out a number of the issues I had initially –  Artiom Chilaru Mar 28 '12 at 13:54

2 Answers 2

up vote 31 down vote accepted

Yes, it is important to include anti-forgery tokens for login pages.

Why? Because of the potential for "login CSRF" attacks. In a login CSRF attack, the attacker logs the victim into the target site with the attacker's account. Consider, for instance, an attack on Alice, who is a user of Paypal, by an evil attacker Evelyn. If Paypal didn't protect its login pages from CSRF attacks (e.g., with an anti-forgery token), then the attacker can silently log Alice's browser into Evelyn's account on Paypal. Alice gets taken to the Paypal web site, and Alice is logged in, but logged in as Evelyn. Suppose Alice then clicks on the page to link her credit card to her Paypal account, and enters her credit card number. Alice thinks she is linking her credit card to her Paypal account, but actually she has linked it to Evelyn's account. Now Evelyn can buy stuff, and have it charged to Alice's credit card. Oops. This is subtle and a bit obscure, but serious enough that you should include anti-forgery tokens for the form action target used to log in. See this paper for more details and some real-world examples of such vulnerabilities.

When is it OK to leave off the anti-forgery token? In general, if the target is a URL, and accessing that URL has no side effects, then you don't need to include anti-forgery token in that URL.

The rough rule of thumb is: include an anti-forgery token in all POST requests, but you don't need it for GET requests. However, this rough rule of thumb is a very crude approximation. It makes the assumption that GET requests will all be side-effect-free. In a well-designed web application, that should hopefully be the case, but in practice, sometimes web application designers don't follow that guideline and implement GET handlers that have a side effect (this is a bad idea, but it's not uncommon). That's why I suggest a guideline based upon whether the request will have a side effect to the state of the web application or not, instead of based on GET vs POST.

share|improve this answer
    
I see.. I suppose this does make sense. The only thing I'm worried is making the users annoyed with the fact that if they have two forms open at the same time, and then try to post them - one of them will most likely fail the validation :( –  Artiom Chilaru Feb 12 '11 at 11:08
    
+1, niice. CSRF-twist on the ol' session fixation... Nice paper, too, btw. –  AviD Feb 13 '11 at 9:32
    
Isn't there any solution to the error being received when user logs in from two tabs? –  AntonAnsgar Jun 18 at 13:41
    
@AntonAnsgar, using a CSRF token does not mean there has to be an error when the user logs in from two tabs. If you're getting such an error, use a better CSRF token implementation. –  D.W. Jun 18 at 13:44
1  
Thanks. The user opens the login page on two tabs. Logs in from one, goes to the other one and tries to login again, the app throws an exception. "System.Web.Mvc.HttpAntiForgeryException: The provided anti-forgery token was meant for user "", but the current user is loggedin@user" This is in asp.net mvc 4. I'm using [ValidateAntiForgeryToken] –  AntonAnsgar Jun 18 at 13:48

Where it could be necessary to have the token on a login page is when you need to prevent someone from maliciously logging you into the site with particular credentials. I can see this being the case if someone is being framed for something that requires logging in with a particlar user. With that being said, its a bit of a contrived example.

share|improve this answer
    
Not so contrived... See @D.W.'s answer. –  AviD Feb 13 '11 at 9:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.