java反序列化漏洞核心成因是objectinputstream.readobject()无条件触发敏感方法且不校验不可信输入，攻击者可构造gadget链（如cc链）执行任意代码；关键在于默认信任classpath中所有可序列化类，缺乏类型与行为白名单限制。
ObjectInputStream反序列化漏洞的核心成因
漏洞本质不是ObjectInputStream本身有缺陷，而是它在调用readObject()时会无条件触发对象生命周期中的敏感方法，比如readObject()、readResolve()、static代码块、constructor，甚至finalizer。只要反序列化的字节流来自不可信源，且其中包含可利用的类（如Apache Commons Collections中的InvokerTransformer），攻击者就能拼装出一条“反序列化链”（Gadget Chain），最终执行任意代码。
关键点在于：Java反序列化不校验输入合法性，也不限制类加载范围，默认信任所有存在于ClassPath中的可序列化类。
常见高危利用链与典型触发场景
最经典的是CC链（Commons Collections链），利用TransformedMap + ChainedTransformer + InvokerTransformer组合，在反序列化过程中通过反射调用Runtime.getRuntime().exec()。其他常见链还包括：
- JBoss JMXInvokerServlet 接口暴露导致远程命令执行
- WebLogic T3协议中反序列化入口未过滤，被ysoserial payload直接击穿
- Redis存储的session数据若含
ObjectInputStream读取逻辑，可能被注入恶意payload - 日志框架（如Log4j 1.x）中使用
ObjectInputStream解析MDC/NDC字段，构成隐式反序列化入口
有效防护手段必须分层落地
单靠“不用readObject()”不现实，真实系统中常有遗留通信或缓存逻辑依赖它。实用防护策略包括：
- 禁用不可信源反序列化：网络请求体、HTTP参数、文件上传、Redis/Memcached缓存值等一律视为不可信，禁止直接传给
ObjectInputStream - 启用JDK原生过滤器：JDK 9+支持
ObjectInputFilter，可通过System.setProperty("jdk.serialFilter", "your.whitelist.pattern")或运行时设置filter，例如java.util.ArrayList;com.example.*;!* - 升级并精简依赖：移除旧版
commons-collections:3.1等已知高危库；如必须使用，升级至4.4+并确认未启用危险transformer - 替代方案优先：对外接口统一改用Jackson（禁用
DefaultTyping）、Gson或Protobuf；内部模块间通信可考虑Kryo（开启RegistrationRequired模式）
代码审计与应急响应要点
面试中常被追问“怎么快速定位风险点”，答案很明确：
- 全局搜索
ObjectInputStream.readObject()、ObjectOutputStream.writeObject()，尤其关注参数是否可控（如来自request.getInputStream()、new FileInputStream(xxx)、socket.getInputStream()） - 检查是否绕过了filter：比如自定义
ObjectInputStream子类重写了resolveClass()但未做白名单校验 - 验证是否启用了JEP 290过滤机制：在
readObject()前调用ois.setObjectInputFilter(filter)，且filter规则不含宽泛通配符（如***） - 上线前用
ysoserial生成测试payload发包探测，配合WAF日志观察是否拦截AC ED 00 05（Java序列化魔数）高频出现
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
