Java反序列化是将字节流还原为对象的过程，危险在于盲目反序列化不可信数据会触发恶意代码执行；核心入口是ObjectInputStream.readObject()，风险源于默认不校验类名且易被gadget链利用；防范需禁用原生方案或启用白名单、JDK序列化过滤等机制。
Java反序列化，简单说就是把一串字节（比如从网络、文件或数据库读来的数据）还原成内存中的Java对象。这个过程本身是中性的，但危险在于：如果程序盲目地对不可信的输入执行反序列化，攻击者就可能构造恶意字节流，让JVM在还原过程中触发非预期代码，比如执行命令、读取文件、连接外网等。
核心机制：ObjectInputStream.readObject() 是关键入口
Java原生序列化靠 java.io.Serializable 接口标记可序列化的类，序列化后生成二进制流；反序列化则依赖 ObjectInputStream.readObject() 方法——它会按协议解析字节流，重建对象图，并自动调用特定方法（如 readObject、readResolve），甚至触发构造器和字段赋值。
- 只要类实现了 Serializable，即使没有显式定义 readObject，JVM 也会用默认逻辑还原
- 若类自定义了 readObject 方法，该方法会在字段赋值后被调用，成为攻击常利用的“钩子”
- 某些类（如 URL、BigDecimal、JDBC 连接池对象）在反序列化过程中会间接触发网络请求或类加载，埋下隐患
为什么会有安全风险？因为信任了不该信任的数据
问题不在于反序列化技术本身，而在于很多老系统把反序列化当作“通用数据传输协议”来用，比如用它传用户ID、配置项、甚至整个业务对象，却没校验来源。一旦攻击者能控制输入字节流，就能绕过正常业务逻辑，直达 JVM 底层行为。
- 常见场景：HTTP参数、Redis缓存值、RMI接口、消息队列 payload、日志采集字段
- 典型链路：攻击者构造含 Commons Collections、Groovy、Jython 等第三方库 gadget 的字节流 → 服务端调用 readObject → 触发链式反射调用 → 最终执行 Runtime.getRuntime().exec()
- 根本原因：Java 默认不校验类名和类型，只认 serialVersionUID 和字段结构
怎么防范？本质是控制反序列化的“输入源”和“可加载类”
最直接有效的做法，是避免对不可信数据使用原生 Java 反序列化。如果必须用，就加管控层。
立即学习“Java免费学习笔记（深入）”；
- 优先替换方案：改用 JSON（Jackson/Gson）、Protobuf、Hessian（开启白名单）等更可控的序列化格式
- 若必须用 ObjectInputStream，继承它并重写 resolveClass() 方法，在这里检查类名是否在预设白名单内
- 升级 JDK：JDK 9+ 提供了 jdk.serialFilter 系统属性，JDK 17+ 默认启用更严格的过滤策略（如禁止远程类加载）
- 运行时加固：使用 SecurityManager（虽已弃用但仍有效）或字节码增强工具（如 OpenRASP）拦截可疑反序列化调用
调试与识别：如何确认是不是反序列化漏洞
看代码里有没有对用户可控输入调用了 readObject；看堆栈里是否频繁出现 ObjectInputStream、AnnotationInvocationHandler、BadAttributeValueExpException 等关键词；用 ysoserial 生成测试 payload 发包验证。
- 常见特征：接口接收 base64 字符串、二进制 POST body、或以 AC ED 00 05 开头的十六进制数据
- 报错线索：反序列化失败时抛出 InvalidClassException、ClassNotFoundException 或 Unexpected exception during deserialization
- 注意混淆：有些框架（如 Spring、WebLogic）内部封装了反序列化逻辑，表面看不到 readObject，但实际仍存在风险
基本上就这些。理解反序列化，关键是抓住“字节→对象→方法触发”这条链，以及“谁控制输入、谁决定加载哪个类”这两个安全边界。不复杂，但容易忽略。
