apache shiro 身份认证绕过漏洞

Apache Shiro 的证绕身份认证绕过漏洞，最出名的过漏一个是 Shiro-550，也就是证绕 CVE-2016-4437。这个漏洞的过漏根子不在认证逻辑本身，而在 Shiro 处理“记住我”功能的证绕方式上。简单说，过漏Shiro 会把用户的证绕身份信息序列化后，用 AES 加密，过漏再 Base64 编码，证绕塞进 Cookie 里。过漏问题在于，证绕AES 的过漏密钥是硬编码在代码里的，攻击者只要拿到这个默认密钥，证绕就能自己构造一个合法的过漏 Cookie，把里面的证绕用户名改成 admin，服务端解密后一看，哦，是 admin，直接放行。

我第一次复现这个漏洞的时候，用了个现成的脚本，生成恶意 Cookie，往请求头里一塞，后台就进去了。整个过程不到两分钟。那种感觉挺荒诞的——一个被大量 Java 项目用来做安全框架的组件，居然因为一个写死的密钥，把门直接敞开了。

默认密钥是什么？在 Shiro 1.2.4 及之前的版本里，AES 密钥是 kPH+bIxk5D2deZiIxcaaaA==。这串东西在 GitHub 上随便一搜就能找到。很多开发者压根不知道它的存在，项目里也没改过。更麻烦的是，Shiro 的“记住我”功能默认就是开启的，只要用户勾选了那个选项，Cookie 里就会带上加密后的身份信息。攻击者不需要知道任何用户的密码，只需要一个有效的 Cookie 结构，就能伪造任意身份。

这个漏洞的利用链条其实很清晰：拿到默认密钥 → 构造序列化数据 → AES 加密 → Base64 编码 → 替换 Cookie → 发送请求 → 服务端解密并信任 → 认证通过。每一步都不复杂，但组合起来就是一次完整的身份认证绕过。Shiro 在解密 Cookie 的时候，没有校验数据来源，也没有做完整性检查，它默认这个 Cookie 是自己发出去的，所以解密出来的内容一定是可信的。这个假设在默认密钥泄露的前提下，直接崩塌。

后来 Shiro 在 1.2.5 版本里改了什么？它不再使用硬编码的默认密钥，而是要求开发者自己配置一个密钥。但问题没完，因为很多老项目升级不及时，或者升级了但密钥还是用的默认值。更离谱的是，有些开发者虽然换了密钥，但换成了另一个常见的弱密钥，比如 4AvVhmFLUs0KTA3Kprsdag==，这东西同样在公开的字典里。攻击者拿一个密钥字典去跑，照样能打进去。

我见过一个真实的案例，某企业的后台管理系统用了 Shiro 做认证，版本是 1.2.4，密钥没改。渗透测试的时候，我们直接构造了一个 rememberMe Cookie，把用户名设成 admin，权限设成 *:*:*，请求发过去，系统直接返回了管理员面板的 HTML。整个过程没有触发任何告警，日志里也只记录了一次正常的登录。这种漏洞的隐蔽性在于，它不依赖任何用户交互，也不需要爆破密码，只要网络可达，就能直接绕过认证。

修复方式其实不复杂：升级到 Shiro 1.2.5 以上，并且生成一个足够随机的 AES 密钥，不要用任何公开的默认值。如果项目里用了 Shiro 的 rememberMe 功能，还要考虑密钥的轮换机制，避免一个密钥用到底。另外，可以在服务端加一层校验，比如检查 Cookie 里的身份信息是否和当前会话匹配，或者对序列化数据做签名。但这些都只是缓解，根本还是要把密钥管好。

Shiro-550 不是唯一一个身份认证绕过漏洞，但它足够典型——一个看似安全的加密机制，因为一个默认配置，变成了攻击者的后门。安全这东西，很多时候不是算法不够强，而是实现的时候留了太多“方便”的默认值。默认密钥、默认密码、默认开启的功能，每一个都可能成为突破口。写代码的人觉得“先这样，以后再改”，攻击者可不等人。

很赞哦!（4261）