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

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.

[Note]

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:

    static class CustomAccessDeniedHandler extends AccessDeniedHandlerImpl{ @Override public void handle(HttpServletRequest request, HttpServletResponse response, AccessDeniedException accessDeniedException) throws IOException, ServletException { if (accessDeniedException instanceof MissingCsrfTokenException || accessDeniedException instanceof InvalidCsrfTokenException) { if(request.getRequestURI().contains("login")){ response.sendRedirect(request.getContextPath()+"/login"); } } super.handle(request, response, accessDeniedException); } }
  2. 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:

@Bean
public AccessDeniedHandler accessDeniedHandler() { return new CustomAccessDeniedHandler(); }

In your security config modify the configure method as follows:

@Override
protected void configure(final HttpSecurity http) throws Exception { http // ... .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

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Tomcat在处理请求目标时发现了无效字符。有效的字符包括字母、数字和一些特殊符号。一旦请求中包含了无效字符,Tomcat将无法正确解析请求,导致出现错误。 无效字符是指那些不被HTTP协议允许出现在请求目标中的字符。例如,某些特殊符号和非ASCII字符可能被认为是无效字符。其中一个被提到的无效字符是“a”。 如果碰到这个错误,您可以考虑以下解决方案: 1. 检查请求目标中是否存在无效字符。可以使用ASCII字符集中允许的字母、数字和一些特殊符号,如连字符或斜杠。 2. 检查请求目标中是否存在非ASCII字符。如果存在,可以尝试将其转换为相应的ASCII字符或使用URL编码来处理。 3. 检查URL中是否存在空格或其他不允许的字符。如有需要,可以使用URL编码来替换这些字符。 4. 检查请求目标中是否存在其他错误。无效字符错误可能是由其他问题引起的。检查其他相关信息,如请求头和请求体,以寻找可能的错误。 总之,当在Tomcat中遇到“invalid character found in the request target”的错误时,应该仔细检查请求目标中是否包含无效字符,并采取适当的措施来解决该问题。 ### 回答2: Tomcat报错"invalid character found in the request target. the valid characters"意思是在请求目标中发现了无效字符,有效字符包括a。 这个错误通常发生在使用Tomcat服务器时,客户端发起了一个带有无效字符的请求。在URL中,请求目标代表要请求的资源的路径。例如,以GET方法请求http://example.com/my-page时,"my-page"就是请求目标。 Tomcat服务器对请求目标中的字符有一些限制。根据HTTP/1.1规范,请求目标只能包含ASCII字符,并且某些字符需要进行转义。如果在请求目标中发现了无效字符,就会出现这个错误。 在错误信息中提到的有效字符"a"指的是ASCII字符中的字母"a"。根据HTTP/1.1规范,字母"a"是允许在请求目标中使用的有效字符之一。 要解决这个错误,可以检查请求中的URL是否包含了无效字符。确保请求目标只包含ASCII字符,并将其中的无效字符进行转义。可以使用URL编码来确保请求目标中的特殊字符正确转义。 例如,如果请求目标中包含了非ASCII字符,可以使用URL编码将其转换为%xx的格式。对于字母"a",由于它是有效字符,所以不需要进行特殊处理。 总之,当在Tomcat服务器中出现"invalid character found in the request target. the valid characters"的错误时,需要检查请求目标中是否包含了无效字符,并对其进行相应的转义处理,确保请求目标只包含ASCII字符。 ### 回答3: Tomcat invalid character found in the request target问题的原因是在请求目标中存在无效字符。在Tomcat中,请求目标是指HTTP请求中URL中的路径部分。根据HTTP协议,请求目标只能包含特定的有效字符。 有效字符是指被允许在URL中使用的字符,包括字母(大小写),数字以及一些特殊字符,如连字符(-)、下划线(_)、点号(.)等。 然而,为了确保请求的安全性和可靠性,Tomcat对请求目标进行了严格的检查和验证。如果在URL中的请求目标中发现无效字符,Tomcat会拒绝处理该请求,并返回"invalid character found in the request target"错误。 在这种情况下,解决方法是确保请求目标中只包含有效的字符。你提到的有效字符是字母"a",所以可以查看请求目标中是否包含了其他无效字符。 通常情况下,无效字符可能是由URL编码错误引起的。URL编码是一种将特殊字符转换为URL安全字符的方法。对于包含非ASCII字符的URL,应该使用适当的URL编码方法。 另外,如果你使用的是Web应用程序框架,例如Spring MVC,也可能是在生成URL时出现了编码问题。在此情况下,建议检查URL生成的代码,确保使用了正确的URL编码机制。 总之,要解决Tomcat invalid character found in the request target问题,需要检查并确保请求目标中只包含有效字符,并正确处理URL编码。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值