1. 项目概述从一次真实的应急响应说起去年我们团队负责维护的一套核心业务系统突然收到了安全部门的紧急告警。告警信息指向一个我们使用了多年的权限认证框架——Apache Shiro。经过排查发现攻击者利用了一个经典的Shiro反序列化漏洞尝试在服务器上执行任意命令。虽然因为其他防护措施攻击并未成功但这次事件让我们惊出一身冷汗。事后复盘我们发现开发团队虽然知道Shiro但对这个潜伏的“老漏洞”及其变种缺乏系统性的认知和防护。这促使我花了大量时间深入梳理了Apache Shiro反序列化漏洞的来龙去脉并形成了一套从原理到修复、从临时缓解到彻底根治的完整解决方案。今天我就把这些实战经验分享出来希望能帮你绕过我们踩过的坑。简单来说Apache Shiro是一个强大且易用的Java安全框架用于身份验证、授权、加密和会话管理。其反序列化漏洞的核心在于Shiro为了提供“记住我”RememberMe功能而使用的默认加密方式存在缺陷。攻击者可以构造恶意的序列化数据在服务器反序列化时触发远程代码执行RCE。这个漏洞影响范围极广从2016年的CVE-2016-4437开始后续又衍生出多个利用链和绕过方式至今仍是红蓝对抗中的高频考点。无论你是开发、运维还是安全工程师只要你的系统涉及Shiro理解并解决这个问题都是必修课。2. 漏洞原理深度拆解为什么Shiro会成为靶子要真正解决问题必须首先理解问题是如何产生的。Shiro的反序列化漏洞并非设计之初就存在的后门而是其功能特性在特定使用方式下暴露出的安全风险。2.1 核心祸根RememberMe功能的加密与解密过程Shiro的“记住我”功能本质是在用户浏览器端存储一个加密的Cookie。当用户下次访问时Shiro会读取这个Cookie解密并反序列化其中的数据从而自动完成登录。这个过程可以简化为序列化与加密服务端 - 客户端用户成功登录并勾选“记住我”后Shiro会将用户的身份信息如PrincipalCollection进行Java序列化然后使用一个硬编码的默认密钥kPHbIxk5D2deZiIxcaaaA进行AES加密最后Base64编码设置为Cookie名为rememberMe发送给浏览器。解密与反序列化客户端 - 服务端用户再次访问时浏览器会携带这个rememberMeCookie。Shiro接收到后会进行Base64解码使用相同的密钥进行AES解密最后对解密后的字节流进行Java反序列化还原用户身份信息。漏洞就爆发在最后一步反序列化。Java的反序列化机制本身是危险的它会根据字节流中的类描述自动调用类的readObject方法。如果攻击者能够控制被反序列化的数据并让服务器反序列化一个精心构造的、包含恶意代码的类对象就能实现RCE。2.2 攻击链的形成密钥与利用链的双重问题攻击者要利用此漏洞需要突破两个关键点获取或爆破加密密钥由于Shiro 1.2.4及之前版本使用了众所周知的默认密钥且很多开发者在部署时并未修改这相当于把家门钥匙放在了门口的垫子下。即使后续版本在生成随机密钥但如果密钥泄露如通过代码泄露、配置文件泄露攻击者就能伪造合法的加密Cookie。构造有效的反序列化利用链Gadget Chain仅有密钥还不够解密后的数据必须是一个能成功触发RCE的Java对象。这依赖于目标服务器的Classpath中是否存在可被利用的第三方库如CommonsCollections、CB、Hibernate等。攻击者会将这些库中一系列类的特性像搭积木一样组合起来形成一条从反序列化入口到最终执行命令的完整调用链。关键认知这个漏洞的利用是“条件触发”式的。服务器上必须存在相应的利用链依赖库漏洞才能被成功利用。这解释了为什么有些系统“中招”了有些却没有。但绝不能抱有侥幸心理因为现代Java应用引入这些常见库的概率非常高。2.3 漏洞的变种与绕过一场持续的攻防战最初的漏洞CVE-2016-4437修复后攻防并未停止。安全研究人员和攻击者发现了多种绕过方式Padding Oracle AttackCVE-2020-1957利用AES加密的CBC模式缺陷在不知道密钥的情况下通过服务端返回的差异如报错信息、响应时间来逐字节爆破出明文或构造出合法的Padding从而绕过密钥验证。利用其他编码方式除了Base64攻击者尝试使用Hex等编码方式来封装Payload以绕过一些简单的WAF规则检测。新的利用链Gadget挖掘随着新的第三方库被广泛使用不断有新的利用链被挖掘出来例如基于CommonsBeanutils、ROME等的链扩大了攻击面。这些变种使得单一的修复措施往往不够需要一套组合拳。3. 解决方案全景图从紧急止血到根除病根面对Shiro反序列化漏洞我们的应对策略应该是分层、递进的。下图概括了从应急到根治的完整路径发现漏洞告警 | v [ 阶段一紧急处置临时缓解 ] |—— 3.1 临时禁用RememberMe功能 |—— 3.2 部署WAF/IPS规则拦截 | v [ 阶段二针对性加固中期修复 ] |—— 3.3 升级Shiro至安全版本 |—— 3.4 修改并强化加密密钥 |—— 3.5 引入反序列化过滤器 | v [ 阶段三架构免疫长期治理 ] |—— 3.6 弃用Java原生反序列化 |—— 3.7 建立软件成分清单与漏洞监控接下来我们详细拆解每一个步骤的具体操作和背后的考量。3.1 紧急处置发现漏洞后的第一时间响应如果监控系统告警或怀疑已被攻击首要任务是立即止损为后续修复争取时间。操作1全局禁用RememberMe功能这是最直接、最有效的一键止血方案。通过修改Shiro的配置彻底关闭该功能入口。在Spring Boot的application.yml中配置shiro: # 禁用记住我功能 rememberMe: enabled: false在传统Shiroini或Java Config中Bean public SecurityManager securityManager(Realm realm) { DefaultWebSecurityManager securityManager new DefaultWebSecurityManager(); securityManager.setRealm(realm); // 不设置RememberMe管理器或显式设置为null // securityManager.setRememberMeManager(null); return securityManager; }实操心得在线上紧急处理时我推荐直接修改配置并重启应用。虽然有些文章提到可以通过Filter拦截Cookie但在高并发或复杂过滤链场景下配置方式更彻底、更可靠。禁用后所有用户的“记住我”Cookie将失效需要重新登录务必通过公告等方式告知用户。操作2部署虚拟补丁或WAF规则在应用层修复之前可以在网络边界或应用前端如Nginx、Apache部署拦截规则识别并阻断带有恶意特征的rememberMeCookie请求。示例Nginx规则片段需根据实际Payload特征调整location / { # 检查Cookie中rememberMe的值如果匹配特定模式则返回403 if ($http_cookie ~* rememberMe([^;])) { set $shiro_cookie $1; # 这是一个非常简单的示例实际应使用更复杂的正则匹配Payload特征 if ($shiro_cookie ~* rO0ABXQ.*) { # 匹配Java序列化流的Base64开头 return 403; } } proxy_pass http://your_app_server; }注意事项WAF规则容易被绕过如编码变形、分块传输且可能产生误报。它只能作为临时辅助手段绝不能替代应用自身的修复。规则需要安全团队持续维护和更新。3.2 针对性加固修复漏洞本体的核心步骤紧急措施稳定局面后需要立即着手进行实质性修复。3.2.1 升级Shiro至安全版本这是官方推荐的首选方案。新版本通常修复了已知的漏洞并可能引入更安全的默认行为。目标版本至少升级到1.7.0及以上版本。1.7.0之后Shiro在RememberMeManager中增强了对反序列化的防护。升级步骤检查当前项目的pom.xml或build.gradle中Shiro的版本号。修改版本号为最新稳定版如1.13.0。注意兼容性建议先在测试环境验证。dependency groupIdorg.apache.shiro/groupId artifactIdshiro-web/artifactId version1.13.0/version !-- 升级至此版本或更高 -- /dependency执行依赖更新命令mvn clean install或gradle build解决可能出现的API变更导致的编译错误。重要提示仅仅升级Shiro版本并不能完全免疫反序列化攻击如果密钥仍然弱或泄露且Classpath中存在利用链攻击者依然可能利用旧版Payload尝试攻击。升级必须与其他措施结合。3.2.2 修改并强化加密密钥这是切断已知攻击路径的关键一步。务必不要使用默认密钥。生成强密钥使用Shiro提供的工具或自行生成一个足够长且随机的Base64编码密钥。# 使用Shiro的CommandLineMain工具生成需shiro-tools依赖 java -cp shiro-tools-hasher-1.13.0.jar org.apache.shiro.tools.Hasher -a AES -i 128 # 或者使用任何安全的随机数生成器生成16、24或32字节的密钥然后Base64编码在配置中指定密钥# application.yml shiro: rememberMe: cipherKey: base64:你的新强密钥字符串 # 注意前缀 base64:// Java Config Bean public CookieRememberMeManager rememberMeManager() { CookieRememberMeManager manager new CookieRememberMeManager(); byte[] cipherKey Base64.decode(你的新强密钥字符串); manager.setCipherKey(cipherKey); // 建议同时设置Serializer见下一节 return manager; }密钥管理最佳实践环境隔离开发、测试、生产环境使用不同的密钥。定期轮换制定密钥轮换策略尽管对RememberMe功能来说轮换会导致所有用户退出但可作为高风险时期的安全增强措施。安全存储将密钥存储在环境变量或专业的密钥管理服务KMS中而非硬编码在配置文件里。3.2.3 引入反序列化过滤器白名单机制这是目前最有效的防御手段之一。其原理是在反序列化过程中拦截并检查即将被反序列化的类只允许预定义的安全类被加载。使用Shiro内置的DefaultSerializer推荐从Shiro 1.7.0开始CookieRememberMeManager支持设置Serializer。我们可以配置一个DefaultSerializer并为其指定一个AllowList反序列化器。import org.apache.shiro.io.DefaultSerializer; import org.apache.shiro.subject.SimplePrincipalCollection; Bean public CookieRememberMeManager rememberMeManager() { CookieRememberMeManager manager new CookieRememberMeManager(); manager.setCipherKey(cipherKey); // 1. 创建允许类的集合 SetClass? allowedClasses new HashSet(); allowedClasses.add(SimplePrincipalCollection.class); // Shiro身份集合必须 allowedClasses.add(String.class); // 可能存储的用户名 allowedClasses.add(Long.class); // 可能存储的时间戳 // 添加你的业务中RememberMe功能需要序列化的所有安全类 // 2. 创建并配置允许列表序列化器 DefaultSerializer serializer new DefaultSerializer(); // 关键设置允许的类列表 serializer.getAllowList().addAll(allowedClasses); // 或者更严格地只使用允许列表拒绝其他所有类 // serializer.setWhiteList(true); // 新版本API可能有所不同需查证 manager.setSerializer(serializer); return manager; }使用第三方安全库对于更复杂的场景或历史版本可以集成专门的反序列化过滤库如SerialKiller。你需要将其封装成一个Shiro能识别的Serializer。public class SerialKillerSerializer implements SerializerObject { private final SerialKiller serialKiller; public SerialKillerSerializer() { // 配置SerialKiller定义黑名单/白名单 Config config new Config.Builder() .addAllowedClass(org.apache.shiro.subject.SimplePrincipalCollection) .addAllowedClass(java.lang.String) .setBlacklistPattern(.*\\.*) // 示例更激进的黑名单 .build(); this.serialKiller new SerialKiller(config); } Override public Object deserialize(byte[] serialized) throws SerializationException { try (ByteArrayInputStream bis new ByteArrayInputStream(serialized); ObjectInputStream ois serialKiller.newObjectInputStream(bis)) { return ois.readObject(); } catch (Exception e) { throw new SerializationException(反序列化失败, e); } } // ... serialize 方法 }白名单配置的挑战最大的难点在于确定完整的白名单列表。你需要仔细审计RememberMe功能到底序列化了哪些业务对象。建议从SimplePrincipalCollection开始在测试环境开启详细日志观察正常登录时的序列化行为逐步构建白名单。宁可开始名单过小导致部分功能需要重新登录也绝不要盲目扩大名单。3.3 架构免疫面向未来的根本性解决方案以上的加固措施主要围绕Shiro自身的功能进行。要从根本上降低此类风险需要考虑架构层面的改进。3.3.1 弃用或替换Java原生反序列化Java原生反序列化是万恶之源。在新的系统或模块中应尽量避免使用ObjectInputStream/ObjectOutputStream。替代方案JSONJackson/Gson对于简单的数据传输JSON是更安全、更通用的选择。Shiro的Session信息可以考虑用JSON序列化后存储。Protocol Buffers / Thrift对于性能要求高、跨语言交互的场景这些二进制协议是更优选择它们有严格的模式Schema天生免疫任意类加载。改造RememberMe可以自定义一个RememberMeManager内部使用JSON来存储用户标识如用户ID而非完整的PrincipalCollection对象。当Cookie被送回时根据用户ID从数据库重建用户信息。这彻底移除了反序列化环节。public class JsonRememberMeManager extends CookieRememberMeManager { private ObjectMapper objectMapper new ObjectMapper(); Override protected byte[] serialize(PrincipalCollection principals) { String userId extractUserId(principals); // 提取核心ID try { return objectMapper.writeValueAsBytes(new RememberMeToken(userId, System.currentTimeMillis())); } catch (JsonProcessingException e) { throw new SerializationException(e); } } Override protected PrincipalCollection deserialize(byte[] serialized) { try { RememberMeToken token objectMapper.readValue(serialized, RememberMeToken.class); // 根据token中的userId从数据库或缓存查询并构建PrincipalCollection return rebuildPrincipals(token.getUserId()); } catch (IOException e) { throw new SerializationException(e); } } // ... 内部类 RememberMeToken }3.3.2 建立软件成分清单与持续漏洞监控Shiro漏洞的利用依赖外部库利用链。管理好这些依赖至关重要。使用SCA工具集成像OWASP Dependency-Check、Snyk、GitHub Dependabot等软件成分分析工具到CI/CD流水线中。每次构建都自动检查项目依赖库的已知漏洞包括Shiro本身及其潜在的危险依赖如Commons-Collections。维护许可与安全策略明确禁止引入已知的高危库如commons-collections:3.1。如果业务必须使用需经过安全团队评审并制定额外的防护措施。订阅安全通告关注Apache Shiro官方安全页面、国家漏洞库CNNVD/NVD以及安全社区一旦有新的漏洞披露能第一时间评估影响并响应。4. 实战操作记录一步步修复一个Spring Boot项目理论说再多不如亲手做一遍。假设我们有一个使用Spring Boot 2.7和Shiro 1.8.0的遗留项目现在需要对其进行加固。4.1 环境诊断与现状分析首先我们通过检查来了解现状。检查依赖打开pom.xml确认Shiro版本。dependency groupIdorg.apache.shiro/groupId artifactIdshiro-spring-boot-web-starter/artifactId version1.8.0/version !-- 存在漏洞的版本 -- /dependency检查配置查找application.yml或Java Config中关于rememberMe的配置。发现使用了默认配置且没有显式设置密钥。检查依赖树中的危险库运行mvn dependency:tree搜索commons-collections、commons-beanutils等常见利用链组件。mvn dependency:tree | grep -E commons-collections|commons-beanutils发现存在commons-collections:3.2.2。4.2 分步实施修复我们采取组合策略升级 修改密钥 设置白名单。步骤一升级Shiro版本修改pom.xml将版本升级至1.13.0。由于是次版本号升级需要关注API变更。查阅官方发布说明1.9.0到1.13.0之间没有破坏性变更但测试必不可少。dependency groupIdorg.apache.shiro/groupId artifactIdshiro-spring-boot-web-starter/artifactId version1.13.0/version /dependency运行mvn clean compile确保编译通过。步骤二生成并配置强密钥使用在线工具或代码生成一个随机的32字节256位AES密钥并Base64编码。import javax.crypto.KeyGenerator; import java.util.Base64; //... KeyGenerator keyGen KeyGenerator.getInstance(AES); keyGen.init(256); // 使用256位密钥 byte[] key keyGen.generateKey().getEncoded(); String base64Key Base64.getEncoder().encodeToString(key); System.out.println(新密钥: base64Key);将生成的密钥配置到application.yml中shiro: rememberMe: cipherKey: base64:q4vJ7FgT2XpL9MkR8YwC1zAnB5DcE6HjN # 替换为你的密钥 # 注意旧Cookie将全部失效用户需重新登录步骤三配置反序列化白名单Java Config方式如果项目使用的是Java配置类修改或创建Shiro的配置类。Configuration public class ShiroConfig { Value(${shiro.rememberMe.cipherKey}) private String cipherKey; Bean public CookieRememberMeManager rememberMeManager() { CookieRememberMeManager manager new CookieRememberMeManager(); // 1. 设置强密钥 byte[] keyBytes Base64.decode(cipherKey.replace(base64:, )); manager.setCipherKey(keyBytes); // 2. 创建并配置带白名单的序列化器 DefaultSerializer serializer new DefaultSerializer(); SetClass? allowedClasses new HashSet(); allowedClasses.add(SimplePrincipalCollection.class); allowedClasses.add(String.class); allowedClasses.add(Long.class); allowedClasses.add(ArrayList.class); // SimplePrincipalCollection内部可能使用 allowedClasses.add(HashMap.class); // 同上 // 将允许列表设置给序列化器 // 注意Shiro 1.13.0中DefaultSerializer的AllowList可能通过构造器或setter设置 // 此处为示例具体API请查阅对应版本文档 // serializer.setAllowedClasses(allowedClasses); // 另一种方式使用BeanSerializer如果可用或自定义Serializer manager.setSerializer(new SafeSerializer(allowedClasses)); return manager; } // 自定义安全序列化器 static class SafeSerializer implements SerializerObject { private final SetString allowedClassNames; private final DefaultSerializer defaultSerializer new DefaultSerializer(); SafeSerializer(SetClass? allowedClasses) { this.allowedClassNames allowedClasses.stream() .map(Class::getName) .collect(Collectors.toSet()); } Override public Object deserialize(byte[] serialized) throws SerializationException { // 简易实现先反序列化再检查类型生产环境需更严谨如重写ObjectInputStream Object obj defaultSerializer.deserialize(serialized); if (obj ! null !allowedClassNames.contains(obj.getClass().getName())) { throw new SerializationException(反序列化检测到非法类: obj.getClass().getName()); } return obj; } Override public byte[] serialize(Object object) throws SerializationException { return defaultSerializer.serialize(object); } } // 将RememberMe管理器注入SecurityManager Bean public SecurityManager securityManager(Realm realm, CookieRememberMeManager rememberMeManager) { DefaultWebSecurityManager securityManager new DefaultWebSecurityManager(); securityManager.setRealm(realm); securityManager.setRememberMeManager(rememberMeManager); // 注入 return securityManager; } }步骤四测试与验证功能测试启动应用测试正常登录、记住我登录、退出功能是否正常。漏洞验证使用安全扫描工具如Burp Suite的Shiro插件、专门的Shiro检测脚本对修复后的服务进行检测确认漏洞是否已被修复。回归测试确保系统的其他功能不受影响。4.3 配置清单与检查表为了确保修复的完整性你可以使用下表进行核对检查项操作说明预期结果/配置示例是否完成Shiro版本升级至1.7.0shiro-spring-boot-starter:1.13.0☐RememberMe密钥已从默认密钥修改cipherKey: base64:你的强随机密钥☐反序列化过滤器已配置白名单机制仅允许SimplePrincipalCollection,String,Long等必要类☐危险依赖检查并评估commons-collections等考虑升级至无害版本或排除☐会话存储确认Session管理器未使用不安全序列化如使用EnterpriseCacheSessionDAO确保缓存安全☐WAF/IPS规则已部署或更新拦截规则能识别常见Shiro攻击Payload☐监控告警已配置对异常登录/反序列化错误的监控出现相关异常能及时告警☐5. 常见问题与排查技巧实录在实际操作中你肯定会遇到各种问题。下面是我在多次修复和加固过程中积累的一些典型问题及其解决方法。5.1 修复过程中的典型问题问题1升级Shiro后应用启动报错提示NoSuchMethodError或ClassNotFoundException。原因这通常是依赖冲突或API不兼容导致的。Shiro的新版本可能依赖了不同版本的slf4j、spring或其他库。排查运行mvn dependency:tree -Dincludesorg.apache.shiro查看Shiro相关依赖树确认传递依赖的版本。检查是否有其他依赖强制指定了旧版Shiro组件。解决在pom.xml中显式声明可能冲突的公共依赖的版本通过dependencyManagement。使用mvn dependency:analyze分析依赖。清理本地Maven仓库~/.m2/repository/org/apache/shiro重新拉取依赖。问题2配置了白名单后正常的“记住我”功能也失效了用户无法自动登录。原因白名单过于严格遗漏了RememberMe功能实际序列化的某些类。Shiro在SimplePrincipalCollection中可能存储了自定义的Principal对象或使用了特定的Map/Collection实现。排查开启调试日志在application.yml中设置logging.level.org.apache.shiroDEBUG。正常登录一个用户并勾选“记住我”观察日志中序列化和反序列化过程中的类名信息。在反序列化失败时日志通常会打印出试图加载的类名。解决将日志中看到的类逐步添加到白名单中。一个更稳妥但繁琐的方法是在自定义的Serializer的deserialize方法中捕获异常并打印出试图反序列化的类名然后将其评估后加入白名单。如果业务复杂可以考虑转向使用JSON序列化方案一劳永逸。问题3修改密钥后所有已登录用户被迫退出用户体验不好。原因这是预期行为。新的密钥无法解密旧的Cookie。解决沟通与公告如果必须立即修改密钥应提前发布维护公告告知用户。平滑过渡如果架构允许实现一个短暂的“双密钥”支持期。自定义一个RememberMeManager在解密时先用新密钥尝试失败后再用旧密钥尝试。一旦用旧密钥解密成功就用新密钥重新加密并设置Cookie。过渡期结束后移除旧密钥逻辑。此方案实现复杂需谨慎评估。5.2 漏洞排查与应急响应技巧技巧1如何快速判断系统是否存在Shiro漏洞手动检测发送一个请求在Cookie中设置rememberMexxx任意值。观察响应。如果返回的Set-Cookie头中也有rememberMedeleteMe基本可以确定目标使用了Shiro并且RememberMe功能已开启存在漏洞利用条件。使用Burp Suite的Shiro Scanner插件或开源工具如ShiroAttack2进行更精确的检测和密钥爆破。日志分析在Shiro的RememberMeManager相关类中增加审计日志记录解密失败和反序列化失败的信息。频繁的解密失败日志可能意味着正在遭受密钥爆破攻击。技巧2服务器疑似被入侵如何排查立即隔离将疑似服务器从网络中断开防止横向移动。保护现场对内存、磁盘进行镜像备份以便后续取证。日志溯源重点检查应用日志中Shiro相关的错误如解密异常、反序列化异常。检查Web访问日志如Nginx、Tomcat access log寻找带有超长或特殊字符rememberMeCookie的请求记录记录下源IP和时间。检查系统命令执行历史~/.bash_history和进程列表ps auxf查找可疑进程。文件排查在Web目录如/tmp/dev/shm下查找可疑的.jsp、.war或脚本文件攻击者常会上传Webshell。时间线关联将攻击请求的时间点与服务器上可疑文件创建时间、异常进程启动时间进行关联分析。技巧3修复后如何进行有效性验证工具复测使用之前成功的攻击Payload和工具再次对修复后的系统进行测试应全部失败。代码审计重点审计RememberMeManager、Serializer、CipherService等相关配置类的代码确保加固措施已正确生效。渗透测试邀请安全团队或使用专业的渗透测试服务进行一次针对性的测试。修复Apache Shiro反序列化漏洞是一个系统工程涉及从紧急响应到代码修复再到架构优化的多个层面。没有一劳永逸的银弹关键在于理解漏洞原理采取纵深防御策略并将安全实践融入到开发和运维的日常流程中。每次安全事件都是改进的契机希望这份详细的解决方案能成为你构建更安全系统的一块坚实基石。