A CSRF attack can occur when a malicious program causes a user’s web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate an action instead of getting user data because the attacker has no way to see the response to the forged request.
Auth0 obviously provides login operations, and login operations are a form of “state-changing request” so i can see how this applies. However, if a CSRF attack is against “a trusted site on which the user is currently authenticated”, then it sound like this doesn’t apply to the login operation, so it sounds like there’s no need to protect the login form from it. (We’re having issues with using the state parameter for our OAuth logins, so this sounds like we could avoid pain by not using it.)
Although it may seem originally that there is little that can be compromised by [an attacker logging a user into my website without their knowledge if the attacker already knew their username and password], if you log any data about your user while they’re logged in which they can access … then login request forgery vulnerabilities can allow a malicious user to massively compromise user privacy.
…
A login request forgery vulnerability on Google, for instance, would allow the malicious user to snoop on search queries, watched YouTube videos, location lookups and more.
So my points are:
The current information from Auth0 on CSRF protection do not seem to suit an authentication scenario. Is anyone from Auth0 able to provide updated advice (and update that page in the docs)?
If my app doesn’t “log any data about your user while they’re logged in which they can access” (except, ironically enough, perhaps by a data protection-related request), is there any other reason why we shouldn’t dispense with the CSRF protection?
Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.
Wanted to reach out to know if you still require further assistance?
It would still be useful to have enhanced guidance from Auth0 on when CSRF is necessary or recommended.
This is related to my other topic, which describes the problems we’ve had with the state parameter; one solution to that problem is not to apply CSRF protection. In trying to understand the consequences there would be for that decision, Auth0’s CSRF page was not very useful, so in any case in my opinion that page could do with a refresh to apply it to login scenarios specifically.
Are you able to provide any additional guidance on CSRF protection for login scenarios?
I wanted to follow up on this subject, I personally feel that CSRF should be leveraged in any authentication request through a web browser. However I know you are looking for a more in-depth response. So I will see if I can find a senior engineer to elaborate more.
In terms of guidance about CSRF protection in login scenarios I think it pretty much boils down to what James already mentioned, that is, you should employ CSRF protections for this scenario. In terms of what is contained in the documentation, if we focus solely on that single phrase you mentioned that states that a CSRF attack can occur by a malicious actor performing an unwanted action on an authenticated site I would agree that this could be interpreted as only considering scenarios where the user is already authenticated, however, I don’t see this as implying that the login scenario is excluded and only see it as an example (likely the most common one) of that attack.
In addition, when the whole page focus on a technique to prevent CSRF on OIDC/OAuth 2.0 transactions then it would be hard to say that it is excluding login scenarios from this attack vector. As an additional and more personal note I would say it’s likely better to mitigate against CSRF everywhere then to try to review if specific scenarios require this or not. However, this is mostly a personal opinion and there will likely be scenarios where you could omit such protection, but they will be likely very specific to the application/system in question so it’s hard to voice an opinion on it without knowing the entire system.
So far I’ve been unable to explain in business terms to the business user what the the consequences would be of not having CSRF - e.g. describing the severity of the potential vulnerabilities it could open.
