ObjectInputStream.resolveClass()不是攻击入口，而是反序列化中将类名映射为Class对象的关键钩子；攻击者可通过继承覆写它实现类重定向、绕过黑名单或加载恶意类，但需控制输入流类型且依赖具体上下文。
Java 反序列化中，ObjectInputStream.resolveClass() 方法本身不是攻击入口，而是反序列化流程中负责将字节流里的类名映射为实际 Class 对象的关键钩子。攻击者无法直接“调用”它发起攻击，但可在**自定义子类覆盖该方法**时，动态篡改类加载行为，从而绕过黑名单、加载恶意类或触发特定 gadget 链。
resolveClass 的作用与默认行为
当 ObjectInputStream 读取到序列化数据中的类描述符（如 java.util.ArrayList）时，会调用 resolveClass() 尝试通过当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）加载该类。默认实现就是简单调用 Class.forName(name, false, loader)。
它不参与反序列化逻辑判断，也不校验类是否“安全”——这个责任本应由应用层承担，但常被忽略。
如何通过继承重写 resolveClass 实现类重定向
攻击者或研究者可继承 ObjectInputStream，覆写 resolveClass()，在类名解析阶段插入自定义逻辑：
立即学习“Java免费学习笔记（深入）”；
- 将危险类名（如
org.apache.commons.collections4.functors.InvokerTransformer）映射为无害的存根类（如java.lang.String），用于绕过基础黑名单检测 - 将特定类名（如
com.example.Payload）动态替换为已部署在 classpath 中的恶意 gadget 类（如ysoserial.payloads.Jdk7u21的变体） - 根据类名前缀、包路径或哈希值，选择性委托给不同类加载器（如从远程 URL 加载字节码，需配合
URLClassLoader）
示例片段：
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {String name = desc.getName();
if ("com.unsafe.Payload".equals(name)) {
return Class.forName("com.evil.Gadget", false, myCustomLoader);
}
return super.resolveClass(desc);
}
真实利用场景与限制
这种重定向常见于以下场景：
-
靶场环境绕过：某些 WAF 或反序列化防护只检查原始字节流中的类名，未校验最终加载的
Class对象来源 -
定制化反序列化服务：如旧版 WebLogic、WebSphere 的 T3 协议处理逻辑允许传入自定义
ObjectInputStream子类 -
测试工具链集成：ysoserial 的
--classloader模式或 JavaSec 工具中，通过覆写resolveClass注入 payload
但注意：该方法需在反序列化前就控制输入流类型（即能实例化自定义 ObjectInputStream 子类），且目标应用必须使用该实例——这意味着它不是通用“0day”，而是依赖具体上下文的链路拼接点。
防御建议：别只拦名字，要控源头
单纯在字节流里过滤类名远远不够。有效缓解需多层协同：
- 禁用
ObjectInputStream，改用 JSON、Protobuf 等不带执行语义的格式 - 若必须用 Java 序列化，使用白名单机制，在
resolveClass中严格校验类名和ClassLoader来源 - 运行时限制：通过 SecurityManager（JDK 8 及以前）或模块系统（JDK 9+）禁止动态类加载、反射关键方法
- 监控反序列化行为：对
ObjectInputStream子类实例化、敏感类加载事件进行日志与告警
