Is disabling CSRF protection sometimes justified?

Question

I'm thinking of login forms in particular:

By their nature, login forms block action on arbitrary input — without a valid username and password, you just get bounced. Is there a reason why these even need the addition of authenticity_token or similar cross-site request forgery protection at all?

I'm curious if login forms are one example where CSRF might even be generally undesirable:

Given an anonymous client, it should be allowed that the first point of contact with a site is to POST valid login credentials. CSRF prevents this direct interaction by first requiring that the client perform a GET to establish an anonymous session cookie, which is used as the basis for their authenticity_token. The token must then be posted back with the login credentials. The extra up-front step seems pointless when the actual goal here is to authenticate a user who arrives without a session and is trying to give their credentials.

Am I missing some security consideration in this scenario?

Answer 1

Awesome question! It had me scratching my head for a while.

What about the scenario where the attacker has already acquired the victim's password by other means, but doesn't have access to the website himself? He tricks his victim into going to www.evil.com and has this on the initial page:

<image src="http://portal.internal/login.php?user=root&password=hunter2"/>

This convinces the victim's browser to authenticate the victim to the site. Then, on another page of www.evil.com, there is another image tag:

<image src="http://portal.internal/deleteEverything.php/>

In this case, the attacker must use CSRF to gain access the internal site, since he has no other way to access it. Also, note that this CSRF attack need not be executed on a user who actually has an account on the system, only a user who has network access to the site.

Answer 2

Without XSRF protection, an attacker could log the user into a malicious account, which they could use to track their activity. This is discussed in Robust Defenses for Cross-Site Request Forgery.

I don't see why the client should be able to POST login credentials as a first point of contact. For a web interface, in most practical cases the client has to GET the login page to retrieve the form.