Shiro反序列化漏洞：一场持续了五年的序列噩梦

2016年，安全研究员Larry Spatches在GitHub上扔出一段代码，化漏Shiro框架的序列“记住我”功能就成了黑客的提款机。这个漏洞编号CVE-2016-4437，化漏后来被圈内人戏称为“Shiro-550”，序列因为它影响的化漏正是那个经典的550端口——不，开个玩笑，序列550其实是化漏指漏洞发现时的Shiro版本号。真正的序列问题出在序列化数据上：Shiro用AES加密cookie，密钥却是化漏硬编码的“kPH+bIxk5D2deZiIxcaaaA==”，这串字符在官方文档里躺了整整四年。序列

攻击者只需要拿着这个公开密钥，化漏自己构造一个恶意序列化对象，序列加密后塞进cookie的化漏rememberMe字段。服务器一解密，序列反序列化就触发了，远程代码执行直接拿下服务器。整个过程不需要任何用户交互，一个HTTP请求就够了。我见过最夸张的案例是某云厂商的运维后台，被人在登录页面上用一条curl命令就打穿了，连密码都没猜。

你以为官方修了就完事了？Shiro在1.2.5版本后确实改了默认密钥，但大量开发者图省事，直接复制网上的配置教程，把自定义密钥写死在代码里。2019年爆出的Shiro-721更狠——它不需要知道密钥，利用Padding Oracle Attack暴力破解AES加密，理论上只要流量够大，任何密钥都能被撞穿。这就像你家换了把高级锁，但小偷直接拿电钻把墙打穿了。

漏洞的本质是Java反序列化的老毛病。ObjectInputStream.readObject()一碰到恶意字节流，就能让类方法链自动执行，相当于把黑客的指令当成系统命令来跑。Shiro只是背锅侠，真正该死的是那些允许任意类反序列化的组件——Commons-Collections、Spring-Core，随便哪个库有漏洞，都能配合Shiro玩出花来。我见过最离谱的利用链，是拿Shiro打进去后，再用Fastjson二次提权，一套组合拳下来，内网全部裸奔。

防御手段其实不复杂：升级到1.7.1以上版本，自定义一个强随机密钥，再往Servlet过滤器里加个黑名单，禁止反序列化类名包含“commons.collections”或“springframework”。但现实是，很多企业连Shiro版本号都懒得查。有个做金融系统的朋友告诉我，他们生产环境跑着2015年的Shiro，因为“能跑就不动，动了怕出问题”。——直到某天被挖矿程序占了CPU，才发现服务器早成肉鸡了。

这漏洞教给我一件事：安全不是装个防火墙就完事，而是得把每个依赖库的更新日志当小说看。Shiro的教训已经够多了，从硬编码密钥到反序列化链，每次修复都像打地鼠。可只要还有人在用旧版框架，这地鼠就永远打不完。你看，连Apache官方都承认，Shiro的漏洞数量在Java安全框架里能排进前三，这“荣誉”恐怕还得保持好几年。