核心在于从数据入口、类加载、方法调用三层面系统性干预：先定位readobject等隐蔽入口（如rpc、缓存、日志框架），再识别classpath中高危gadget类（如commons collections），最后通过objectinputfilter白名单、移除readobject、替换json协议等方式切断调用链。
识别并修复 Java 反序列化漏洞中的 gadget chain 攻击点，核心在于“先看清链路，再切断关键环节”。这不是靠堵一个方法就能解决的问题，而是要从数据入口、类加载、方法调用三个层面系统性地梳理和干预。
定位反序列化入口点
攻击必须从某个 readObject() 或类似调用开始。不要只盯着业务代码里显眼的 ObjectInputStream.readObject()，更要排查隐蔽入口：
- RPC 框架（如 Dubbo、RMI）默认启用 Java 原生序列化，接口参数可能直接触发反序列化
- 缓存层（Redis、Memcached）中存储的 session 或对象，若未经校验就反序列化，极易成为跳板
- 日志框架（如 Log4j 2.x 早期版本）、模板引擎（Freemarker、Thymeleaf）在解析用户输入时，可能间接调用反序列化逻辑
- 第三方库的自动解析行为：Fastjson ≤1.2.83、Jackson ≤2.13.3、XStream ≤1.4.19 等都曾因默认开启反序列化而引入风险
识别运行时存在的 gadget 类
gadget chain 不是凭空构造的，它依赖目标环境中真实存在的类及其方法逻辑。重点检查 classpath 中是否包含已知高危组件：
-
Apache Commons Collections（3.1–3.2.1 / 4.0–4.3）：经典
Transformer链、InvokerTransformer是 RCE 主力 -
Groovy（≤2.4.15）：利用
GroovyShell或MethodClosure执行任意代码 -
Spring（CVE-2018-1273）：通过
AbstractBeanFactory和 SpEL 表达式触发 - JDBC 驱动（如 MySQL Connector/J）：配合 JNDI 注入，实现远程类加载
可使用 java-chains 或 ysoserial 的 --list 功能扫描当前 JDK 和依赖版本支持哪些 gadget 链；也可静态分析 mvn dependency:tree 输出，标记出含已知漏洞版本的 jar 包。
拦截或限制危险调用路径
即使 gadget 类存在，只要阻断其被链式调用的条件，攻击就无法落地：
- 升级 JDK 到 9+ 后，强制启用
ObjectInputFilter：在ObjectInputStream构造后立即设置白名单策略，例如只允许java.util.*和业务自定义类，拒绝org.apache.commons.collections.*等高危包 - 禁用
readObject自动调用：对所有实现了Serializable的敏感类，移除自定义private void readObject(ObjectInputStream)方法；或改用serialPersistentFields+writeObject显式控制字段序列化 - 替换序列化协议：将 Java 原生序列化彻底替换为 JSON（Jackson/Gson）、Protocol Buffers 或 Avro，这些格式本身不执行代码，天然规避 gadget chain
验证修复是否生效
修复后必须实测验证，不能仅靠版本号判断：
- 用
java-chains生成一条针对目标环境的 payload（如指定 JDK 17 + commons-collections 3.2.1），发送到疑似入口点，观察是否仍能触发 DNSLog 回调或命令执行 - 在测试环境开启 JVM 参数
-Dsun.rmi.transport.tcp.readTimeout=5000 -Dcom.sun.jndi.rmi.object.trustURLCodebase=false，防止 JNDI 相关链绕过 - 监控日志中
ClassNotFoundException或InvalidClassException异常突增——这往往是 filter 生效、恶意类被拒的信号
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
