4

While playing with Spring security, I was wondering about the approach of CSRF (Cross Site Request Forgery) Token lifecycle at application logout.

Let's say a user logs in and navigates on my website. Then he logs out. Should I invalidate the CSRF token (implemented as a cookie in my case, if it matters)?

If no, is there any caveat I should be aware of in term of security?

If yes, how am I supposed to manage any further action of the user on the application? Without any CSRF Token, the server-side will forbid some actions. Should I generate a new Token then?

I'm using Spring boot for the server side, and it seems it invalidates by default the Token (or I made something wrong that leads to this result...)

Thanks for any help.

Rémi Doolaeghe
  • 2,262
  • 3
  • 31
  • 50

2 Answers2

4

I'm assuming you're talking about the Double Submit Cookies CSRF prevention method.

If not, then this is not a secure solution - for some methods of securing against CSRF see Why is it common to put CSRF prevention tokens in cookies?

Yes, you should refresh CSRF tokens upon logout and login. Note that login CSRF is something not every site needs to protect against. See this answer if you need to do this.

The (very low) risk of not refreshing the CSRF token upon login is that if another user logs in using the same browser, the original user knows the CSRF token and could use a CSRF attack themselves if they entice the new user to follow a malicious link. Of course, if the first user had control of the browser or operating system, they could simply have installed something on the machine itself in order to do this. However, if the second user thoroughly checks the machine before use then this type of CSRF attack would be undetectable (although if the user is being so vigilant then they would not go clicking any received links while logged in).

In short, if you're implementing CSRF protection then you may as well do this properly and refresh tokens upton login and logout.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
1

Logging In

In order to protect against forging log in requests the log in form should be protected against CSRF attacks too. Since the CsrfToken is stored in HttpSession, this means an HttpSession will be created immediately. While this sounds bad in a RESTful / stateless architecture the reality is that state is necessary to implement practical security. Without state, we have nothing we can do if a token is compromised. Practically speaking, the CSRF token is quite small in size and should have a negligible impact on our architecture.

Logging out

Adding CSRF will update the LogoutFilter to only use HTTP POST. This ensures that log out requires a CSRF token and that a malicious user cannot forcibly log out your users.

One approach is to use a form for log out. If you really want a link, you can use JavaScript to have the link perform a POST (i.e. maybe on a hidden form). For browsers with JavaScript that is disabled, you can optionally have the link take the user to a log out confirmation page that will perform the POST.

See this link for more info : Csrf protection you can alse see csrf timeout

Amit khanduri
  • 57
  • 7
  • Thanks @Amit. I had seen this extract from Spring security documentation. But this does not really answer my question: What happens to the token after logging out? I imagine a new one should be generated by the server (that would be logical, as the session is cleared). I just wanted to ensure this was the correct approach, and that there were no caveat I hadn't seen. – Rémi Doolaeghe Nov 04 '15 at 12:55