Shiro反序列化漏洞：别等被打了才想起补

2023年某大厂内网被攻破，序列溯源时发现入口就是化漏Shiro反序列化。攻击者拿到的洞解不是普通权限，是决方root。而修复方案早就在官网上挂着，序列只是化漏没人当回事。Shiro这漏洞，洞解老，决方但致命。序列

先说原理，化漏别嫌烦。洞解Shiro的决方rememberMe功能会把用户信息序列化后加密存在cookie里，密钥硬编码在代码中。序列攻击者拿到密钥，化漏就能伪造任意cookie，洞解让服务器反序列化恶意对象。说白了，你把保险箱钥匙插在锁孔里，还贴了张纸条写着“钥匙在这”。

最坑的是，很多团队的密钥是默认的——`kPH+bIxk5D2deZiIxcaaaA==`。这串字符在GitHub上被搜了十万次不止。我见过某银行外包项目，三年前上线时用的默认密钥，到现在还没换。他们安全团队不是不知道，是觉得“内网没事”。结果呢？钓鱼邮件进来，员工点了个链接，内网就穿了。

解决方案分三档，按紧急程度排。

第一档，立刻止血。改密钥。生成随机强密钥，替换默认值。别用UUID当密钥，那玩意儿有规律。用`SecureRandom`生成32字节以上随机数，Base64编码后硬编码在配置里。改完重启，旧cookie全部失效，用户重新登录一次，损失可接受。这操作半小时搞定，别拖。

第二档，根治问题。升级Shiro版本。1.7.1之前全有这毛病，1.7.1之后官方改了序列化白名单机制。但注意，白名单默认关闭，你得自己开启。在`shiro.ini`里加一行：`securityManager.rememberMeManager.cipherKey=你的新密钥`，然后`cookieSerializer`配置里加上`setWhiteList`。别嫌麻烦，这步不做等于没升。

还有个细节，很多人忽略。Shiro的反序列化不只走rememberMe，session序列化也中招。如果项目里自定义了sessionDao，记得检查存储介质是否加密。Redis存session时，value用JSON别用Java原生序列化，否则等于把后门留给攻击者。

第三档，防御纵深。加WAF规则拦截`rememberMe`参数异常值，但这只能挡脚本小子。真正靠谱的是在反序列化入口加过滤器，校验对象类型白名单。网上有开源工具叫`SerialKiller`，能定制黑名单，把`commons-collections`这类高危库全禁了。但注意，白名单别太严，否则业务功能会报错。我见过有团队把白名单配死，结果文件上传功能直接崩了，最后回滚配置，漏洞又开了。

说个真实案例。某电商平台，技术总监安全意识强，每季度做一次Shiro密钥轮换。结果有次轮换后，用户反馈“登录状态老丢”。排查发现是密钥更新后，旧cookie解密失败，用户被迫重新登录。总监顶着业务压力硬扛了两天，等所有用户cookie过期后恢复正常。他后来跟我说：“安全性和用户体验永远是矛盾的，但被攻击的代价更大。”

最后说个反直觉的事。别迷信漏洞扫描器。扫描器只能测出默认密钥，测不出自定义密钥的强度。你生成个`123456`当密钥，扫描器报“安全”，实际上等于裸奔。所以密钥生成后，自己写个脚本跑一遍反序列化攻击测试，确认打不穿再上线。

Shiro这漏洞，本质是懒。密钥硬编码是懒，不升级是懒，不测是懒。安全这行，懒一次，就得用十倍代价来还。改完密钥，记得把代码提交记录删了，别把新密钥写进Git历史——那又是另一个故事了。