Apache Shiro漏洞排查：别等被打了才想起补丁

上个月帮一家电商公司做安全审计，洞排他们的洞排后台管理系统用的是Shiro 1.7.1——这个版本恰好存在CVE-2023-46749，一个能直接绕过认证的洞排硬编码密钥漏洞。对方CTO一脸茫然：“我们没收到官方警告邮件啊。洞排”
我当场用默认密钥`kPH+bIxk5D2deZiIxcaaaA==`试了一下，洞排三秒钟就伪造出了管理员Session。洞排这不是洞排个例，国内大量中小团队还在跑着Shiro 1.5.x甚至更老的洞排版本。

第一刀：先看版本号，洞排别信pom.xml

排查Shiro漏洞，洞排第一步永远是洞排确认真实版本。很多人以为看下Maven依赖里的洞排版本号就完事了，但Java的洞排依赖传递机制经常给你“惊喜”——你声明了1.6.0，实际运行时可能因为某个传递依赖被拉到了1.4.2。洞排我曾经在一个Spring Boot项目里发现，洞排shiro-core显示1.8.0，但shiro-web被另一个库强制降到了1.3.2，这种“版本分裂”最容易出问题。
正确做法是打一个fat jar，然后用`java -jar`跑起来后，直接到`/lib`目录下翻shiro-core的jar包，看MANIFEST.MF里的Implementation-Version。或者更狠一点，在代码里临时加一行`System.out.println(org.apache.shiro.version.Version.getVersion())`，输出的一瞬间你就能看到真相。

第二刀：检查密钥配置，这是重灾区

Shiro最经典的漏洞是反序列化攻击，根源在于硬编码的对称加密密钥。默认密钥`kPH+bIxk5D2deZiIxcaaaA==`在网上满天飞，但很多开发为了省事，直接复制粘贴到配置文件里。排查方法很直接：
1. 打开`shiro.ini`或`application.yml`，搜索`cipherKey`、`secret`这类关键词。
2. 如果看到Base64字符串，把它丢到网上搜一下，如果搜索结果超过10条，基本就是公开密钥。
3. 更隐蔽的坑是——有些团队用随机密钥，但把密钥写死在代码里，并且提交到了Git仓库。用`git log --all --oneline`搜一下历史提交，经常能翻出当年为了调试留下的硬编码密钥。
我见过最离谱的案例，有人把密钥写在了README.md里，还美其名曰“方便同事部署”。

第三刀：看RememberMe的Cookie处理逻辑

Shiro的RememberMe功能是另一个高危入口。默认的Cookie名称是`rememberMe`，值为Base64序列化数据。攻击者如果拿到了密钥，就能构造恶意序列化payload，直接触发RCE。
排查时重点看两点：
- 是否启用了RememberMe？如果业务不需要，直接关掉，在配置里设置`rememberMe.enabled=false`。
- 如果必须启用，检查序列化方式。Shiro 1.4.2以上版本默认用AES-CBC，但老版本用AES-ECB，后者更容易被padding oracle攻击。用Burp Suite抓包，看Cookie的加密块长度——CBC模式每个块16字节，ECB模式每个块也是16字节，但解密时对错误填充的响应不同。简单点，直接看官方文档确认版本对应的加密模式。
还有个细节：Shiro 1.7.1之前的版本，Cookie的`HttpOnly`和`Secure`属性默认没开启，这意味着XSS攻击能直接偷走Cookie。检查响应头，如果`Set-Cookie`里没有`HttpOnly`，赶紧改。

第四刀：别忽略动态代理和过滤器链

Shiro的权限控制依赖过滤器链，但有些团队为了省事，把所有请求都放行，只在Controller层做注解校验。这种配置下，如果某个接口忘了加`@RequiresPermissions`，就直接裸奔了。排查方法是用Shiro的`SecurityUtils.getSubject()`配合`isPermitted()`写个测试接口，遍历所有URL路径，看哪些路径没有经过过滤器。
更隐蔽的问题是Shiro的路径匹配漏洞。比如`/admin/*`这种写法，Shiro默认不匹配`/admin/../admin`这种路径，但Tomcat会先做归一化处理，导致绕过。测试时用`curl --path-as-is`发送含`../`的URL，看是否能绕过认证。
我去年处理过一个案例：某系统用Shiro做权限控制，但过滤器链只匹配了`/api/**`，结果开发自己加了个`/debug/**`接口用于本地调试，上线时忘了删——这个接口直接暴露了所有用户数据。

收尾：打补丁不是终点，要验证

把Shiro升级到1.13.0（2024年后的最新稳定版）只是第一步。升级后必须做回归测试，重点验证Session管理、RememberMe、URL匹配是否正常。有个坑是升级后默认的Session存储方式变了，老代码里直接操作`DefaultSecurityManager`的可能报错。
最后用工具扫一遍，推荐`ysoserial`配合`shiro_tool`（GitHub上有现成脚本），模拟攻击路径。如果扫描结果干净，再手动构造几个恶意Cookie试试。
别以为内网系统就安全——上次那个电商公司，攻击者就是从内网Wi-Fi进入的。Shiro漏洞排查不是一次性工作，每次依赖升级后都要重新过一遍。