Information Security
web-application appsec csrf asp.net asp.net-mvc
Updated Fri, 17 Jun 2022 12:17:03 GMT

Should I use AntiForgeryToken in all forms, even login and registration?


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

There are possibly other reasons why one should use or not use the token in ones forms. Am I correct in assuming that using the token in every post form is 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

Solution

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.

Comments (5)

  • +1 – 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 :( — Feb 12, 2011 at 11:08  
  • +1 – Isn't there any solution to the error being received when user logs in from two tabs? — Jun 18, 2014 at 13:41  
  • +2 – @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. — Jun 18, 2014 at 13:44  
  • +4 – 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] — Jun 18, 2014 at 13:48  
  • +1 – Am I right in thinking that setting - AntiForgeryConfig.SuppressIdentityHeuristicChecks = true as mentioned in this post stackoverflow.com/questions/14970102/… would effectively leave you back open to the evelyn style attack? — Mar 01, 2017 at 12:37  

External Links

External links referenced by this document:

Linked Articles

Local articles referenced by this article:

References