Forcing users to be logged out by querying without a CSRF token

[rishabhpoddar]

• In the refresh API, if we query the API without the anti-csrf token, the the user might get logged out cause we throw unauthorised error which clears the session cookies

[rishabhpoddar]

TLDR; We will NOT clear cookies if refresh fails due to missing custom header & the anticsrf mode is VIA_CUSTOM_HEADER. Else, we will clear cookies

Analysis of this attack vector:

If using custom header as a way to prevent CSRF

• This is only secure if CORS is set correctly - to allow requests from only known domains.
• So if an attacker manages to query the refresh API without a custom domain (via a third party site), then the browser won't allow the request to go through in the first place (if the OPTIONS API is called).
• If the OPTIONS API is not called, then this should not clear the cookies, and the user will be unaffected.

If using anti-csrf token

• Then it may be that the CORS setting allows any domain to query the API, in which case, the /auth/session/refresh POST will go through.
• The SDK will clear the cookies, and the user will be logged out.
• If we do not clear the cookies, then the user will be unaffected. However, in browsers like Safari, where the frontend set cookies are removed every 7 days, this will leave users in a "stuck" state where they can't use the app - they can't logout / refresh or verify their session. The only way out is to manually delete the httpOnly cookies, which we can't expect users to do.
  • The stuck state happens because when refreshing the session, anti-csrf won't be sent (Cause it's removed after 7 days of inactivity). And that time, the refresh API won't work anymore and it won't clear the cookies either.

[porcellus]

Upon later review we've decided that:

• we see no reason to skip clearing tokens if it's a CSRF failure
• Overall, this makes maintaining a consistent state across HTTPOnly and frontend cookies easier
  • this way 401 responses during session refresh will always mean that the session doesn't exists
  • the frontend SDKs this way can (and do) handle the refresh endpoint responding with a 401 by clearing all tokens. So if we do not clear the backend tokens, it leads to an inconstant state where the frontend thinks that the session doesn't exist, but it actually does on the backend.