Is CSRF protection disabled sometimes?

Question

I think of login forms in particular:

By their nature, input forms block action on arbitrary input - without a valid username and password you just get a rebound. Is there a reason why they even need to add authenticity_token or similar protection to fake a request to a cross-site site?

I am curious if registration forms are one example where CSRF may be generally undesirable:

For an anonymous client, it must be allowed for the first point of contact with the site to match the valid POST user credentials. CSRF prevents this direct interaction by first requiring the client to perform a GET to create an anonymous session cookie, which is used as the basis for their authenticity_token. Then the token should be sent back with the login credentials. An additional step forward seems meaningless when the actual goal here is to authenticate a user who comes in without a session and tries to provide his credentials.

Are there any security concerns in this scenario?

Answer 1

Without XSRF protection, an attacker could log in to a malicious account, which they could use to track their activity. This is discussed in Reliable Protection for Cross Site Request Forgery .

I do not understand why the client must have the credentials for POST login as the first point of contact. For the web interface, in most practical cases, the client needs to get a login page in order to get the form.

Answer 2

Awesome question! I had to scratch my head a bit.

How about a scenario where an attacker has already acquired the victim’s password in other ways, but does not have access to the site itself? He tricks his victim on www.evil.com and has this on the homepage:

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

This convinces the victim browser to authenticate the victim on 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 access the internal site, since he has no other access to it. Also note that this CSRF attack should not be performed for a user who actually has an account in the system, only a user who has network access to the site.