1

We develop an OpenId Connect server with asp.net core and IdentityServer4 and we use cross-site requests forgery (CSRF) protection provided by the asp.net framework.

Currently, we add the [AutoValidateAntiforgeryToken] attribute to controllers, which adds the CSRF protection to all POST endpoints within the controller.

I understand that CSRF protection is needed in these cases:

  • state-changing requests for authenticated users (because a browser could automatically add the auth cookie to the request)
  • submitting forms that log the user in (to prevent Login CSRF)

But does it make any sense to have CSRF protection for following POST endpoints that are used by unauthenticated users?

  • forgot password (submit username or email for the user who should receive a password reset email)
  • password reset (submit new password)
  • new user registration
  • user activation (submit password and possibly additional personal data)
valdian
  • 11
  • 2

1 Answers1

0

The problem that you try to solve is to help the server determine if the POST request that you receive came from a form I generated and not from some random hacker.

For example if a hacker would just sent a lot of spam requests to your "password reset (submit new password)", then your system would start to send out a lot of password reset emails. So by adding CSRF those request without a proper token would not even execute.

enter image description here

So, I would add it to all of the endpoints you listed. It also makes it harder for bots to try to create fake accounts for example.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • 1
    If the password reset form contains CSRF protection and an attacker wants to send a lot of password reset emails, he writes a script with 2 steps: 1. Send a GET request to get the forgot password page. 2. Extracts the hidden field value and cookie value and use them in a POST request. CSRF protection does not stop him at all. I would say that CSRF protection is helpful only when an attacker needs to send requests from the victim's browser. And regarding forgot password page, it does not matter whether the request is sent from the victim's browser or by the attacker's script. – valdian Mar 14 '22 at 09:49
  • Yes, the hackers can issue GET requests to get the secret key in the form. But there is also often an associated CSRF cookie issued as well and together with the samesite cookie protection, the hacker can't trigger requests towards your site from another domain/origin. – Tore Nestenius Mar 14 '22 at 10:16
  • But if the endpoint does not require any form of authentication, the attacker can run his script from anywhere (e.g. run a nodejs script from the command line on his device). Then he can extract also the cookie from the request and append it to the subsequent POST request. – valdian Mar 14 '22 at 10:31
  • Yes, CSRF is not foolproof, but still a good practice that blocks many forms of attacks against your services.. – Tore Nestenius Mar 14 '22 at 10:36
  • What I try to say, is, that if an attacker wants to send requests to an endpoint that does not require authentication, he has no motivation to try to make a victim visit his malicious sites which submit hidden forms behind the scenes. It is even easier for him to just run a CLI script. – valdian Mar 15 '22 at 10:36
  • Someone could tell me that it is just about decorating controller actions with the `[ValidateAntiforgeryToken]` attribute, so why not do it for every POST action. But adding this validation, brings also some troubles, as descibed for example in https://stackoverflow.com/questions/52760424/antiforgeryvalidationexception-when-trying-to-login-by-two-different-tabs or https://github.com/dotnet/aspnetcore/issues/4847 or https://github.com/dotnet/aspnetcore/issues/13632. Therefore I would like to omit the anti-forgery validation on actions where it does not bring any benefit. – valdian Mar 15 '22 at 10:39
  • CSRF is mostly about protecting authenticated users with a session cookie. For services that does not require authentication, then using a CSRF token can be a way to mitigate some bots, rate-limiting is another way to reduce attacks against forms. Or using some CAPTCHA functionality. I think the main thing is to be aware of its tradeoffs and yes, using ValidateAntiforgeryToken everywhere for non-authenticated endpoints might be overkill. – Tore Nestenius Mar 15 '22 at 10:39