18.5.1 Timeouts

One issue is that the expected CSRF token is stored in the HttpSession, so as soon as the HttpSession expires your configured ​​AccessDeniedHandler​​​ will receive a InvalidCsrfTokenException. If you are using the default ​​AccessDeniedHandler​​, the browser will get an HTTP 403 and display a poor error message.

What is the best way to handle Invalid CSRF_html

One might ask why the expected ​​CsrfToken​​​ isn’t stored in a cookie by default. This is because there are known exploits in which headers (i.e. specify the cookies) can be set by another domain. This is the same reason Ruby on Rails ​​no longer skips CSRF checks when the header X-Requested-With is present​​​. See ​​this webappsec.org thread​​ for details on how to perform the exploit. Another disadvantage is that by removing the state (i.e. the timeout) you lose the ability to forcibly terminate the token if it is compromised.

A simple way to mitigate an active user experiencing a timeout is to have some JavaScript that lets the user know their session is about to expire. The user can click a button to continue and refresh the session.

Alternatively, specifying a custom ​​AccessDeniedHandler​​​ allows you to process the ​​InvalidCsrfTokenException​​​ any way you like. For an example of how to customize the ​​AccessDeniedHandler​​​ refer to the provided links for both ​​xml​​​ and ​​Java configuration​​.

Finally, the application can be configured to use ​​CookieCsrfTokenRepository​​ which will not expire. As previously mentioned, this is not as secure as using a session, but in many cases can be good enough.

​​https://docs.spring.io/spring-security/site/docs/4.2.3.RELEASE/reference/htmlsingle/#csrf-timeouts​​

What is the best way to handle Invalid CSRF token found in the request when session times out in Spring security

The easiest way I found to handle invalidate CSRF token when session times out at the login page is one of the followings:

  1. Redirect the request again to the login page again vi CustomAccessDeniedHandler:
staticclassCustomAccessDeniedHandlerextendsAccessDeniedHandlerImpl{@Overridepublicvoid(HttpServletRequest,HttpServletResponse,AccessDeniedException)throwsIOException,ServletException{if(accessDeniedException instanceofMissingCsrfTokenException||instanceofInvalidCsrfTokenException){if(request.getRequestURI().contains("login")){.sendRedirect(request.getContextPath()+"/login");}}super.handle(request,,);}}
  1. Add refresh header as Neil McGuigan suggested:

​​<meta http-equiv="refresh" content="${pageContext.session.maxInactiveInterval}"> ​​

  1. Furthermore you must create a bean for the new CustomAccessDeniedHandler and register it. The following example shows this for Java config.

In any config class:

@BeanpublicAccessDeniedHandler(){returnnewCustomAccessDeniedHandler();}

In your security config modify the configure method as follows:

@Overrideprotectedvoid(finalHttpSecurity)throwsException{// ....and().exceptionHandling().accessDeniedHandler(accessDeniedHandler());}

Also see ​​here​​.

a more Optimum solution will be for Spring security to handle this situation in their framework.

​​https://stackoverflow.com/questions/32446903/what-is-the-best-way-to-handle-invalid-csrf-token-found-in-the-request-when-sess​​

未找到预期的CSRF令牌。您的会话已过期403
​​​https://gxnotes.com/article/245164.html​​

 Spring Security – Customize the 403 Forbidden/Access Denied Page
​​​http://www.baeldung.com/spring-security-custom-access-denied-page​​