Record the problems that occurred after the Shiro version was upgraded

The project was originally using Shiro version 1.3.0, and Shiro officially issued a risk notice for Apache Shiro Permission Bypass Vulnerability (CVE-2020-17523). Users of Shiro and Spring will need to upgrade to the latest shiro-1.7.1 version. After changing the version number in POM.xml, the project was republished and tested. Some problems found during the tests due to the upgrade of shiro are noted here.

A request with Chinese characters in the URL was blocked

When testing the interface, it was found that part of the original interface would concatenate Chinese parameters in the URL path, such as /hello/ hello. This request mode was fine in the earlier version of Shiro, but the request was blocked after the upgrade. After reviewing the source code, we found that 1.7.1 ShiroFilterFactoryBean has an InvalidRequestFilter loaded in globalFilters by default.

On the third check of the Filter, request.getPathInfo() decodes the encoded URL, and isValid() checks the URL for non-ASCII characters, so the request is blocked.

The solution

  1. If there are a few non-standard urls, it is recommended to modify the URL and send Chinese as a parameter, such as /hello? Key = how are you.
  2. If you don’t want to go through the URL specification extensively, you can change thisShiroFilterFactoryBeanThat will beInvalidRequestFilterRemoved. My implementation is posted below.

Excessive redirection times

Some users reported that the number of redirection times on some interfaces was too high. After investigation, SameSite=lax is found in the value of set-cookie of Response Headers in a redirected request. The attribute browser is used to prevent CSRF attacks, when using third-party cookies, the value of this attribute will decide whether to allow to send the cookie, see: www.ruanyifeng.com/blog/2019/0… . The single sign-on in the system is connected to the third party, and a cookie will be returned after login, and our system will carry this cookie when requesting, indicating that the user has logged in successfully. However, our system and the third party’s system are not in the same network segment, so the request exists across domains, and the single sign-on cookie becomes the third party cookie for our system, which is prohibited by the browser to send. Then it becomes: Request background interface (without cookie) -> Check whether login -> No login, redirect to the login system (at this moment, the interface will be recorded to jump back after login) -> Check whether login (because the login system is a third party, So this time with cookie) -> Logged in -> jump to the requested interface (no cookie) -> then the loop will continue until an error is reported.

Where is SameSite set up?

By looking at the discovery system USES the org.. Apache shiro. Web. Servlet. SimpleCookie to set cookies. This rimmer thinks SAN ‘me

The solution

  1. Replace the request with an HTTPS request and change theSameSiteThe value is set to None. (Never tried)
  2. Set the default value to NULL.

The way I adopted is not good, which will reduce the security of the system to some extent. If there is a better way, please share it with me.