6

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?

Andrew Vit
  • 18,961
  • 6
  • 77
  • 84

2 Answers2

2

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.

Jeremy Powell
  • 3,426
  • 2
  • 21
  • 29
  • Actions like this should never be accessible by a http GET request in the first place, especially destructive ones: that's a much bigger problem than CSRF in my opinion. – Andrew Vit Apr 11 '11 at 19:31
  • True. But then again, assuming that GET-able actions like this don't exists is even worse. – Jeremy Powell Apr 12 '11 at 02:58
  • This is usually an OK assumption with Rails applications, especially Rails 3 applications, that follow the standard Rails conventions. – yfeldblum Oct 02 '11 at 02:44
1

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.

Gelatin
  • 2,393
  • 1
  • 24
  • 29
  • Thanks for the link, that's good reading. I think a web service API is a reasonable place where the client shouldn't have to GET the login page first, before submitting credentials. – Andrew Vit Oct 02 '11 at 03:14
  • If it's a web service and you're just sending a token for future requests in the response (not setting a cookie) that shouldn't be a problem, since it doesn't cause a any side effects for the user. – Gelatin Oct 02 '11 at 10:56