How do I handle CRSF tokens for login pages?

Question

I've recently run into an interesting problem with login pages and CSRF tokens. I want to ensure the login form POST is secured with a CSRF token, however, when/if a user remains on the login page for an extended period of time his/her session will expire and the CRSF token will become invalid. Any advice for how to avoid this issue? I am considering not using a CRSF token for login pages, but this seems to be a bad practice.

Answer 1

Technically speaking, the login page is an out-of-session page (the user hasn't logged in yet) and therefore a CSRF mitigation isn't really needed. There's not a whole lot a hacker can do if the user hasn't established a session. I guess he could trick a user into logging on-- if he knows the user name and password-- but if could do that he could log in from his own browser instead.

If you insist on the CSRF token on the login page, I suggest you render the token as per usual and refresh the page with a Javascript timer (setTimeout) a few seconds before the token is due to expire.

Answer 2

Wikipedia page on CSRF here mentions that a special category of CSRF known as login CSRF is possible. I quote from the page itself

An attacker may forge a request to log the victim into a target website using the attacker's credentials; this is known as login CSRF. Login CSRF makes various novel attacks possible; for instance, an attacker can later log into the site with his legitimate credentials and view private information like activity history that has been saved in the account. The attack has been demonstrated against YouTube.

Also a very popular Java MVC framework (Spring MVC) in its recent releases added inbuilt CSRF protection using CSRF tokens, and they too recommend using the login form to be CSRF protected. Again I quote from here

In order to protect against forging log in requests the log in form should be protected against CSRF attacks too. Since the CsrfToken is stored in HttpSession, this means an HttpSession will be created immediately. While this sounds bad in a RESTful / stateless architecture the reality is that state is necessary to implement practical security. Without state, we have nothing we can do if a token is compromised. Practically speaking, the CSRF token is quite small in size and should have a negligible impact on our architecture.

Answer 3

You should check out the Encrypted Token Pattern when considering CSRF protection methods. It's stateless by design and requires a single Token only, as opposed to the Synchronizer Token or Double Submit Cookie Patterns, which compare two tokens.

In terms of your problem with Tokens expiring on the Login page, you can leverage a framework called ARMOR to protect against CSRF. I wouldn't worry about the login page in terms of CSRF, as you generally don't provide the option for a user to change state at this stage, which is what CSRF is all about. It might be worth considering injecting the Token after the user has logged in, in your case.

Also, the official OWASP Cheat Sheet is a good point of reference.