不安全反序列化

攻击原理与 Gadget 链

反序列化的危险不在于「还原数据」本身，而在于「还原过程自动触发的副作用」。

攻击链：反序列化攻击依赖一种称为「Gadget 链（Gadget Chain）」的技术模式。Gadget 是应用或其依赖库中存在的某个类中的一段代码——该代码在对象被反序列化、构造或销毁时自动执行，并且执行的操作可被攻击者间接控制。单个 Gadget 可能无害（如一个类在 __destruct() 中调用文件删除函数），但多个 Gadget 串联在一起——一个 Gadget 的输出成为下一个 Gadget 的输入——可以构成一条「从反序列化入口到命令执行」的完整执行路径。

Java 反序列化（最危险的原生机制）：

Java 的 ObjectInputStream.readObject() 在反序列化一个对象时自动执行该对象所属类（及其所有父类和关联类）的 readObject()、readResolve() 和 finalize() 方法。如果攻击者能够控制反序列化的字节流，就可以构造一个「包含精心选择的一组嵌套对象」的字节流，这些对象按照预定的顺序触发 Gadget 链，最终调用 Runtime.exec() 执行任意系统命令。

Apache Commons Collections 3 和 4 中的 Transformer 接口（InvokerTransformer、ChainedTransformer 等）是历史上最著名的 Java Gadget 来源——Commons Collections 几乎被每一个 Java Web 应用间接依赖，而 Transformer 的设计（本意是将输入映射为输出）恰好提供了「反射调用任意方法」的能力。

由于 Java 反序列化攻击的危险性和普遍性，安全研究员 frohoff 和 gebl 在 2015 年发布开源工具 ysoserial——一个生成 30+ 条不同依赖库弹射链（Spring Framework、Groovy、Hibernate、Wicket、RMI 等）的 payload 生成器。同类工具包括 PHPGGC（PHP Gadget Chains Generator）和 ysoserial.net（.NET 反序列化 Gadget 生成器）。

ysoserial 与 Gadget 发现方法论

Gadget 链的发现是反序列化漏洞研究的核心挑战。安全研究员和攻击者都试图回答同一个问题：「给定这个目标应用所依赖的类库集合，是否存在一条从 readObject() 到 Runtime.exec() 的可达路径？」

Gadget 发现的技术方法：

静态分析（Static Analysis）：扫描应用和依赖库的所有 class 文件，构建「方法调用图」——如果存在一条从反序列化入口点（readObject/finalize/readResolve）到危险接收点（Runtime.exec/ProcessBuilder/FileOutputStream/反射 Method.invoke）的有向路径，则该路径对应的类和方法组合即为潜在的 Gadget 链。静态分析的挑战在于路径爆炸——商业级 Java 应用可能包含数十万个类，理论调用图中入口到接收点的潜在路径数以亿计。
运行时检测（Runtime Detection）：在应用运行期间监控反序列化行为——哪些类被反序列化、反序列化后哪些方法被执行。通过字节码插桩（Java Agent）或 JVM TI 工具在 ObjectInputStream.resolveClass() 处 hook，记录所有反序列化的类，结合白名单机制阻断未预授权的类。

ysoserial 的原理：

ysoserial 的 Gadget 链收录遵循统一结构：序列化一个 HashMap 或 PriorityQueue（充当容器） → 容器的 hashCode()/compare() 在反序列化时被触发 → 链式调用注入的 Gadget 对象 → 最终调用 Runtime.exec()。

以 CommonsCollections5 链为例：

PriorityQueue.readObject() → PriorityQueue.heapify() → PriorityQueue.siftDown() → PriorityQueue.siftDownUsingComparator() → comparator.compare() → BadAttributeValueExpException.toString() → ... → ChainedTransformer.transform() → InvokerTransformer.transform() → Runtime.exec()

每条 ysoserial 链公开后，安全厂商（WAF/RASP/EDR）会添加该链的序列化签名。但攻击者可以通过「链变异」（修改链中不改变功能但改变字节串的非关键元素）绕过签名检测——这是反序列化防御中检测 vs. 绕过的恒久竞赛。

JEP 290（Java 9+, 2017）与 JEP 415（Java 17, 2021）：

Java 在语言层面做出了反序列化安全增强：

JEP 290：允许通过系统属性（jdk.serialFilter）在 JVM 级别配置序列化过滤器——限制允许反序列化的类、最大的数组长度、最大的对象嵌套深度。但 JEP 290 不是默认启用的。
JEP 415：引入「上下文相关反序列化过滤器」（Context-Specific Deserialization Filters），允许应用为每条反序列化流独立配置过滤器，实现更细粒度的控制。

防御策略与安全替代方案

反序列化的防御应从以下四个层面分层实施：

第一层：不要反序列化不可信数据（根本原则）

这是反序列化安全的第一准则——只要你不反序列化来自网络、用户输入或任何不可信来源的数据，反序列化攻击就无从发生。工程实践中「不使用反序列化」的替代方案：

JSON/XML + 类型安全绑定：使用 JSON 或 XML 等「无副作用」的数据格式进行序列化通信。JSON.parse()（JavaScript）和 json.loads()（Python）不会执行任意代码或实例化任意类（仅还原为字典/列表/基本类型）。但如果 JSON 库在配置了不当的「对象钩子」后解析 JSON——如 Jackson 的 @JsonTypeInfo 和 enableDefaultTyping()——JSON 反序列化仍可构成攻击面（这就是 2019 年 Jackson RCE CVE 系列——CVE-2019-12384 等——的根因）。
Protocol Buffers（protobuf）：Google 开发的语言无关的结构化数据序列化格式。protobuf 不包含类型信息（类名不嵌入序列化数据），反序列化过程不会触发自定义行为——仅将数据填充到预定义的字段结构中。
Apache Avro：另一种语言无关的无副作用序列化方案。

第二层：类型白名单与序列化过滤器

当不得不接受非 JSON/XML 的序列化格式时（如为了兼容旧式 RPC 协议），须实施严格的类型白名单——仅允许反序列化预先定义的、已知安全的类。任何不是白名单中的类在反序列化时出现，立即拒绝。

Java 的序列化过滤器（serialFilter / ObjectInputFilter）允许在反序列化时根据「类名模式」做出允许/拒绝决策。一个保守且安全的过滤器配置应遵循「默认拒绝，仅允许明确授权」的原则。

第三层：应用层完整性校验

在发送端的序列化数据之上附加完整性校验机制——数字签名（HMAC-SHA256）或消息认证码（MAC）。接收端在反序列化之前校验完整性和签名——如果数据在传输中被修改，完整性校验失败，反序列化流程直接拒绝。此层防御无法阻止「合法发送者本身就是恶意方」的场景（如内部威胁场景），但可以有效抵御中间人篡改。

第四层：运行时自我保护（RASP）与纵深监控

应用运行时自我保护（RASP, Runtime Application Self-Protection）技术可以在应用进程内部 hook 关键危险函数（如 Runtime.exec()、ProcessBuilder.start()、ObjectInputStream.readObject()），在反序列化 gadget 链达到执行点之前阻断执行。RASP 的优势是无需编译时配置、可保护遗留应用；代价是性能开销和生产现场的误阻断风险。

OWASP 的「反序列化防护速查表（Deserialization Cheat Sheet）」和 Java、PHP、Python 的安全编码规范均将「不反序列化不可信数据」列为最高优先级的安全要求。这一原则在行业中的普遍共识是：「反序列化安全不是可选的——如果你反序列化不可信数据，你最终将被入侵。」

攻击原理与 Gadget 链

ysoserial 与 Gadget 发现方法论

防御策略与安全替代方案

声明与维护记录

参考资料