0

I'm not sure whether this is necessary, but I don't see any csrf tokens in the login form. Usually when you create a form, you add form_rest(form) at the end, and that adds the csrf token. But the login form is handled differently, it's not really a form object, it's kind of automagic. You can see that in the docs.

So what's up with that? Why there is no csrf protection for the login form? I know CSRF attacks are for authenticated users, but anonymous users in Sf2 are technically authenticated (see the session cookie), and also I might want to have some kind of gradual engagement, like in stackoverflow, where you can perform some actions without being a confirmed member.

Any thoughts?

ChocoDeveloper
  • 14,160
  • 26
  • 79
  • 117

3 Answers3

3

CSRF protection is not necessary on login forms.

CSRF definition: an attacker can force a victim to send an HTTP request to a server.

Typical school-book example: to initiate a money transfer. The attacker can force a request like this: http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve

As you see, the attacker must bake a URL beforehand.

In the case of a login request, it does not make sense, because the attacker must bake a URL like this: http://example.com/login?user=pierre.ernst&pwd=secret.

If the attacker has this information (credentials) already, chances are he will not try a CSRF :-)

Hoping it helps.

Pierre Ernst
  • 514
  • 3
  • 7
  • 3
    Actually, there is another risk. See http://stackoverflow.com/questions/6412813/do-login-forms-need-tokens-against-csrf-attacks – Pierre Ernst Jun 18 '13 at 19:35
0

Actually, form_rest(form) does a lot more than throw in the CSRF token, this function prints out any form rows that have yet to be rendered, and is good to put in to ensure that any additional fields that have been neglected are sure to be rendered.

The reason you're not seeing a CSRF token is because the FOSUserBundle login form is not a Symfony form, it's just a regular HTML form that is then processed by the FOSUser form handler.

I'm not entirely sure why this decision was made but I am sure there was a technical reason behind it, and that if it is a problem you could add one in manually and extend the form handler to process and validate it in the response, I believe the service is parameterised so it should be relatively easy to swap out.

My big question though would be why you would bother doing this? Is it a massive deal? CSRF is a useful step but not the be-all-and-end-all solution for security, and personally, I'd have bigger priorities than this, if it's a big deal it'll get fixed in FOS at some point.

With your latter point, I'm not sure of the relevance, how does this stop you from achieving gradual engagement? A quick tip regardless, whilst I didn't architect this part of the system myself, on an ecommerce project I've been working on recently, the lead decided that to achieve gradual engagement (so people could checkout anonymously) but still persist a lot of their actions, very early on new users are persisted with a autogenerated username and a custom role such as ROLE_GUEST, with the default functionality in Symfony proving insufficient for our use case.

Steve
  • 5,771
  • 4
  • 34
  • 49
  • I'm not using FOSUserBundle. Check the docs I posted, they don't use a form object. About gradual engagement, I just thought CSRF could cause actual damage, but I was confused I think. Anyway, what I need is to know whether Sf2 has CSRF protection in the login form (I don't see it), and whether not having CSRF protection in a login form is bad, how bad, and how do I fix it. – ChocoDeveloper Dec 04 '12 at 00:47
0

Some extra info for those who want it: You can explicitly add the CSRF token to your form.

You can use {{ form_row(form._token) }} to generate the required CSRF token field to your form render in Symfony 3 and up

Glenn
  • 36
  • 3