fastjson的组件洞，比你想的漏洞深

2019年某个深夜，某大厂安全群突然炸了。组件有人贴出一段代码——`JSON.parseObject(input,漏洞 Feature.SupportNonPublicField)`，配文“又跪了”。组件第二天，漏洞应急响应报告确认：攻击者用一段15字节的组件恶意JSON，绕过了最新版fastjson的漏洞autotype黑名单，直接弹了个计算器。组件这不是漏洞第一次，也不是组件最后一次。这个阿里出品的漏洞Java JSON库，几乎成了安全圈“老熟人”。组件

fastjson的漏洞漏洞核心，说白了就一句话：它把JSON解析和Java对象反序列化绑得太死，组件攻击者能通过构造特殊字段，诱导程序实例化任意类，进而执行任意代码。官方一直在打补丁，但补丁总被绕过。比如1.2.47版本，黑名单加了又加，结果有人用`java.lang.Class`缓存绕过，照样打穿。后来官方干脆默认关闭autotype，可很多老项目还在用旧配置，一升级就崩，于是继续裸奔。

我见过最典型的场景是某金融公司，核心交易系统用了fastjson 1.2.24，因为改代码成本太高，硬扛了三年。运维说“我们内网隔离，外网打不进来”，结果钓鱼邮件一发，内网某台机器上有个后台接口直接暴露了fastjson解析，攻击者顺着这个洞横向移动，最后拖走了客户数据库。事后复盘，那个接口只是用来接收前端传的筛选条件，根本没必要用JSON.parseObject，换成`JSONObject.parse`都安全得多。

另一个坑是依赖传递。你写了个小工具，引了个第三方SDK，SDK内部用了fastjson，你根本不知道。等漏洞通告出来，你翻遍pom.xml才发现，版本还是1.2.24。更头疼的是，有些老项目用的是fastjson的“阉割版”——比如某个国产中间件自带的修改版，连CVE编号都查不到。这时候你只能祈祷攻击者比你懒。

有人觉得，那不用fastjson不就行了？换Jackson或Gson。但现实是，很多系统里fastjson已经嵌进业务逻辑深处，比如缓存序列化、MQ消息体、日志解析，不是说换就换。而且，Jackson也不是铁板一块，只是它的默认安全策略更保守，触发条件更苛刻。真正的问题不是某个库，而是开发者习惯——习惯用JSON工具直接映射对象，却忘了反序列化本质上是一种“隐式类型转换”，输入永远不可信。

我有个朋友，现在写新代码一律不用fastjson，但老系统维护时，他会在所有parse入口加一层过滤：先检查字符串里有没有`@type`字段，有就直接拒绝。这办法粗暴，但有效。另一个土招是升级到fastjson2，虽然它也不是100%安全，但至少官方在架构上做了隔离，不再把反序列化和解析混在一起。不过，fastjson2的API和旧版不兼容，迁移得改代码，很多团队又卡在这。

说句难听的，fastjson的漏洞史，就是Java安全生态的一面镜子。它暴露的是“便利性优先于安全”的行业通病。你问我现在还敢不敢用？我的答案是：如果非用不可，就把它锁在沙箱里，永远别让它直接碰外部输入。但如果能选，我会用Jackson，至少它的默认配置不会让你在深夜被电话吵醒。