2

I've been reading a lot about CSRF protection, however I have a doubt that I haven't been able to clarify, not even here in stackoverflow.

So, i'm using flask to build a web-app, and there is a function named csrf_token that you can call to generate a token and put it into a form (in this case the login form) as a hidden input. However, i was thinking, if an attacker enters the login site to get his csrf token, doesn't this kill the csrf protection on the site? because then he can attach his csrf token to an ajax request and this would be equal to having no protection at all basically.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Cesar Cuevas
  • 63
  • 8
  • See this question: https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work – Clayton L Jul 16 '19 at 19:46
  • Although the question has been answered already, thank you as well, the thing is that what i didn´t fully comprehend was the behavior of the CSRF token, not the CSRF methodology itself. – Cesar Cuevas Jul 16 '19 at 20:01

1 Answers1

5

You misunderstand how CSRF works.

No, an attacker can't just take any CSRF token. The CSRF token sent to different users differs. Taking an existing CSRF token then using that to try to trick a different user with that different token is going to fail because the token will not match what was already given to the browser the user is accessing the form with.

Not only is the token going to differ, the point of a CSRF token is that it is given to a user twice, in ways where an attacker can't access both values. The CSRF token is stored both in a cookie (preferably with HttpOnly set to True, so it is not even accessible to code running in the browser) and it is embedded in the form. When the form is submitted, the token posted with the form must match the token in the cookie.

So not only can't the attacker use an earlier CSRF token (which would differ already from what the user was given), the attacker also can't know what cookie the browser would have sent the user, nor can they ever access that cookie even if HttpOnly was not set, because an attacker on domain A can't read cookies for domain B.

Presumably you are using the Flask-WTF CSRF protection here (given the function name). This package stores CSRF tokens in the Flask session, and cryptographically signs tokens and attaches timeout, so an attacker can't replace the session with another that contains their own token, either. In addition, if your users are accessing the site over HTTPS, the HTTP Referer header must match the hostname that the client accessed.

As for the question if login forms, specifically, need to be protected with CSRF: Yes, because if an attacker can choose what login is used by the victim, they can then get access to whatever else the victim has entered into the site. By protecting your login form from CSRF attacks, you protect your users from this scenario.

Fun fact, I reported this issue to then-still-very-new Mozilla project in May 2000 to discuss how browsers could help to mitigate what is now known as CSRF, after having identified the issue on the Open Source Zope platform. Boy, that makes me feel old now.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • Thank you so much!! This is what i was looking for! I misunderstood the behavior of the token, i thought that it was just for validating that the request was made within the authentic server ( by consequence taking as valid any request that included a valid CSRF token). – Cesar Cuevas Jul 16 '19 at 20:00
  • As an additional note, with respect to "Should login forms be protected with Anti Forgery Tokens" - Most CSRF attacks take advantage of pre-existing user sessions with another domain. To perform a CSRF attack (on a login page) from domain A to domain B you would need to POST the login credentials to domain B, which likely isn't accessible, or you have a bigger issue. It is okay to use them here, but it is most important to use them on pages that allow users to insert/edit/delete data, such as a change password pages, update profile, or etc. – h0r53 Jul 16 '19 at 20:54
  • @CaitLANJenner: if anyone can create a login, then there can be advantages to having a victim log in using credentials chosen by the attacker. Because now the attacker has access to whatever the victim is doing, when the victim hasn't noticed that they are now logged in with the wrong credentials. – Martijn Pieters Jul 17 '19 at 11:09
  • @MartijnPieters from my experience such cases are uncommon in practice, but that is still a fair point. As a general rule of thumb, if you are going to use AntiForgery Tokens, use them on each form. – h0r53 Jul 17 '19 at 13:18
  • 1
    @CaitLANJenner: exactly. There may be attack vectors we just haven't conceived of yet. – Martijn Pieters Jul 17 '19 at 13:55