I’m aware of Cross-Site Request Forgery (CSRF) attacks, and consider it standard practice to try to protect against them.
In the Auth0 article Mitigate CSRF Attacks with State Parameters I read:
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.)
But my research has turned this up from an old article Passive-Monitoring Login Request Forgery by Joseph Foulds:
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?