1

We have react SPA application which call a back REST API. According to this paper (section 4.1) it is recommended to make a pre-session and then implement token-based CSRF protencion to stop login CSRF attacks.

The way we are thinking to solve this problem is to create and endpoint in the backend that returns a token in a JSON which encodes information about the IP of the client. Then, the frontend takes this token and adds it to the login form as a hidden input. Then, when the login process starts the backend validates that the IP in the token contained in the hidden input corresponds to the client IP that requested for login.

This have some problems, as stated in these answers

https://security.stackexchange.com/a/59413 -> Clients behind proxies could have the same IP address https://stackoverflow.com/a/14193117/5616564 -> Client IP address could change in each request

Our approach is different from the one stated in the paper. What is the correct approach to mitigicate login csrf in this scenario? How can I make a secure pre-session as stated in the paper?

J.Horcasitas
  • 13
  • 2

1 Answers1

0

I'd suggest you to follow OAWSP recommendation:

Login CSRF can be mitigated by creating pre-sessions (sessions before a user is authenticated) and including tokens in login form. You can use any of the techniques mentioned above to generate tokens.

For instance, you can use Double Submit Cookie. When user loads login form, you can generate a CSRF protection token (a random string) on the server side and set it to a cookie. When client submits the login request, it should read this token from the cookie and set it to a hidden field in the login form (if you use <form> tag) or add a parameter to the request (if you use AJAX call). On the server side you check, if these values match. An attacker cannot read and use this cookie, because JavaScript from another domain is not allowed to do that.

In case of <form> tag, I'd recommend to set it via script just before submitting the form. Otherwise, if the application sets the token on the server side to a hidden field, user can save HTML page and send it to somebody for discussion, and thus will reveal the token.

For the token cookie use a name that starts with __Host- prefix. Such cookie will not be available for subdomains. See details here.

Set attribute SameSite to at least Lax for this cookie. Despite some browsers treat cookies without this attribute as if it was set to Lax, you can set it explicitly, to be sure. Then for requests initiated by the attacker the browser will not send such cookie.

And of course use POST method for login, because SameSite=Lax is ignored for GET requests.

mentallurg
  • 10,256
  • 5
  • 28
  • 44
  • But why do I need a pre-session? In the double submit cookie pattern there is no need for a session. Maybe what I am missing is that this pre-session only applies if I wanted to use the synchronizer token pattern – J.Horcasitas Jan 12 '23 at 19:29
  • It is a matter of wording. It depends on how we define session. If we mean that session is a sequence of interactions that use some *state* stored on the server, then what OWASP calls session is not a session. If we mean that session is a sequence of interactions that use some *data associated with a specific user* (in the case of double submit cookie this is an ID that is set to cookie and to the login form and that will be contained in each request and response, even if the user loads login form many times), then it is a session. – mentallurg Jan 13 '23 at 01:03