最近几年反序列化漏洞的攻防一直是最前沿的阵地。从原生Java反序列化到各类协议封装XML、JSON、二进制RPC几乎每个序列化协议都被翻了个底朝天。Hessian作为老牌二进制RPC协议在各类内部微服务通信中出场率极高早年的Hessian利用链研究多停留在低版本JDK或依赖常见库Spring、FastJSON等的场景。随着JDK版本快速迭代服务端环境普遍跑在JDK 8u191乃至JDK 11、17的今天一个经常被问到的问题就是Hessian在JDK高版本下面对“干干净净”的依赖环境利用链到底还能不能打得通本文就基于这个命题把Hessian反序列化在高版本JDK下的无依赖利用链构造思路完整拆一遍主要面向做Java安全研究的同学、中间件/框架的安全维护者以及想弄明白反序列化攻防原理的进阶开发者。1. 内容整体设计与思路拆解1.1 为什么Hessian一直是反序列化研究的“老熟人”先说背景。Hessian是一个基于二进制协议的RPC框架核心特点就是跨语言、传输效率高、使用简单。它对Java对象的序列化方式与传统ObjectOutputStream不同它通过HessianInput/HessianOutput操作对象图调用的是无参构造函数加setter方法或字节码直接操作字段来重建对象。这套机制天然适合构造“恶意对象图”——只要目标classpath里有可利用的类序列化数据就能驱动它执行某种副作用。研究Hessian反序列化绕不开一条核心主线找一条从readObject到危险行为如动态代理、写文件、执行命令的调用链。和原生Java反序列化利用链如CC链、CB链不同Hessian在反序列化时并不会调用readObject方法除非目标类显式实现了HessianDeserializer的某些接口更多时候是靠Map、HashMap、Hashtable等容器类触发hashCode、equals、toString等内部方法利用这些被动调用点一路往下走。因此Hessian的利用链构造本质上是一个“面向方法的图搜索问题”——目标不是某一个具体方法而是若干被动回调方法的串联。这也是为什么很多经典Java原生利用链被改造后依然能在Hessian场景下复用的原因。比如HashMap的readObject里会触发putput会对key调用hashCodeHessian协议的MapDeserializer同样会调用put效果几乎一模一样。协议差异并没有阻断层面的逻辑差异直到JDK版本升级内部类的实现细节变化才真正开始影响链路构造。1.2 高版本JDK卡住的是哪一关JDK高版本对反序列化利用链的影响很多刚开始做研究的朋友会笼统归结为“反射被限制了”。这个说法不够精准。真正卡住的东西主要有三类第一是sun.reflect.ReflectionFactory的机制变化。JDK 9之后模块化生效jdk.internal.reflect被强封装setAccessible方法在模块边界上会被拦截。一些老利用链依赖反射访问java.lang.Class的私有字段、或者修改Modifier来绕过final限制这类操作在高版本JDK上直接报InaccessibleObjectException。利用链如果没做适配链路就会断在第一跳。第二是serialFilter机制的普及。JDK 9引入了对象输入过滤机制很多中间件和云平台默认开启JAVA_OPT层面的反序列化黑名单把一批高危类直接封死。虽然高版本JDK原生没有默认开启全量过滤但很多企业级环境自带了一层filter导致传统利用链的“启动类”进不了反序列化入口。第三是内部包的密封(sealed)和final类限制。像javax.management.BadAttributeValueExpException这类老链路里的关键触发类在高版本JDK中行为不变但它的构造方法、内部类结构都有可能变化打印堆栈信息的行为也跟着变。很多利用链的构造细节没有跟上JDK源码演进导致一上高版本就失效。“无依赖”这个词要特别说清楚。无依赖不是指完全没有任何第三方库而是指不依赖以目标业务为唯一载体的特定版本库。实际研究中一个纯JDK环境几乎不可能构造出可利用的链——因为利用链需要“桥”类即能串联JDK内置类与危险行为的类这些桥类极少存在于JDK自身某些JDK内部的TemplatesImpl算半个但它需要额外条件。所以这里的无依赖通常指不依赖Spring、不依赖FastJSON这类重量级框架只依赖JDK自身加上极少数常见的、几乎是骨架级存在的组件。1.3 构造“无依赖”利用链的常规方法论在JDK高版本下搞Hessian利用链常规思路大致可以分成三步。第一步叫找入口。入口就是Hessian反序列化时协议层的哪个解析动作会触发目标对象上的哪个方法。Hessian的MapDeserializer、CollectionDeserializer是最常用的入口代理它们会将反序列化得到的键值对按序放入目标容器从而唤起put/putInternal等操作。第二步叫找拼接点。拼接点就是那些能够把put/hashCode/equals的调用转发到真正危险动作的类和方法比如JdbcRowSetImpl的getDatabaseMetaData()会触发JNDI查询这一类行为是链路的“炸药”。第三步叫找桥接类。桥接类的作用是解决类型不匹配、修饰符限制、传递参数不匹配等问题。无依赖场景下桥接类通常得从JDK自带的java.*、javax.*里挑这就非常考验对JDK源码的熟悉程度。方法论上还有一个很重要的点优先去翻JDK源码里那些“行为奇特”的内部类——哪些类在hashCode里做了什么不安全的操作哪些类在equals里做了类型转换和下游调用哪些类在toString里拼接了不可信字符串。这类代码通常被安全的开发者视为“bad smell”但在利用链构造中却是最理想的桥梁。JDK高版本里这类类的行为常常有微妙变化比如某些方法从直接用比较改成调用Objects.equals某些字符串拼接改成了StringBuilder.append外加String.valueOf——这些变化直接决定了桥接链是否仍能稳定工作。2. 核心细节解析与实操要点2.1 Hessian反序列化触发点Map与equals的暗流要理解无依赖利用链必须吃透Hessian的MapDeserializer。读Hessian源码时会发现它的反序列化逻辑本质上是Object map constructor.newInstance(); ifmap instanceof Map { for (;;) { key input.readObject(); value input.readObject(); map.put(key, value); } }这个put调用会直接路由到具体Map实现类的put方法。如果Map实现类是HashMap就会对key调用hashCode()如果是TreeMap则可能调用compareTo/compare如果是Hashtable可能调用equals。这种差异给了利用链构造者极大的发挥空间同一组“构造-调用”模式可以套到不同Map类型上从而绕过某些序列化过滤器的类名黑名单。比较隐蔽的一个点是Hessian对Map接口的反序列化和对具体Map实现的反序列化有所不同。如果你在序列化时写的是一个HashMap实例Hessian会先创建一个目标类的空实例无参构造然后依次调用put。但如果你签名的字段类型是Map接口、实际序列化的是一个具体类Hessian会走到“接口映射”分支可能走UntypedMapDeserializer此时对put的调用方式可能略有差别。这种细节在实战中经常坑到人你以为控制的是HashMap.put实际Hessian可能走了另一条deserializer路径链路直接跑偏。从被动回调的角度看hashCode是利用率最高的入口。几乎所有哈希容器在插入元素时都会调用key的hashCode而JDK自带的java.net.URL、javax.management.BadAttributeValueExpException、com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl后者的hashCode不危险但可以被HashMap触发其他链路等类其hashCode方法内部要么危险、要么能转发。高版本JDK里HashMap.hash()的实现变过一次JDK 14左右调整了扰动逻辑不过对利用链的影响不大真正的变数在于key对象自身的hashCode实现是不是稳定。2.2 “无依赖”场景下桥接类的挑选原则挑选桥接类有几个硬性指标。第一必须是JDK自带的类准确说是java.base模块或java.desktop/java.sql/java.naming模块里的类因为这些模块默认可访问。第二是必须能通过无参构造或setter完成状态注入——Hessian反序列化的一个重要限制是它不会调用带参构造几乎所有属性都得通过字段反射或者setter方法注入这比原生Java反序列化苛刻得多。第三是该类在被作为key/value塞入容器后其被动方法hashCode/equals/toString必须能直接或间接驱动到危险行为。一个比较典型的桥接类是javax.naming.Reference。它的hashCode返回的是toString的哈希或者直接返回固定值本身不危险但它可以作为JNDI查找的一部分被带入上下文。另一个经典桥接类是com.sun.org.apache.xpath.internal.objects.XString它的equals方法里会调用toString()在某些链里作为把equals转发到别的方法的枢纽。更有意思的是javax.swing.UIDefaults$LazyValue它把toString和类加载、方法调用揉在了一起低版本JDK链路里经常出现它的身影高版本还在但模块化限制要注意。挑选桥接类的时候我会优先跑一遍手工“方法追踪”——把候选类反编译出来沿着hashCode方法体一行一行的看看有没有对实例字段做类型转换、有没有调用内部服务、有没有拼接外部输入。比如某个类的hashCode方法里如果存在if (this.value instanceof 目标类型) { ((目标类型) this.value).危险方法(); }那这个类就是极佳的桥接点它天然解决了“类型转换”这一难点。JDK里这样的类虽然不多但仔细翻还是能找到几个问题在于它们的变化频率——有的类在JDK 11里还能用到了JDK 17就把内部实现改成invokedynamic了链路兼容性得靠多版本实测。2.3 高版本JDK的模块化与反射限制实操笔记在做高版本JDK利用链研究时最常遇到的异常是InaccessibleObjectException。这不是偶发问题而是模块化设计的有意为之。java.base模块对sun.*、jdk.internal.*包做了强封装仅靠反射调用setAccessible(true)无法突破模块边界除非在启动参数里加入--add-opens java.base/java.langALL-UNNAMED这类配置。但在目标环境里你是无法控制JVM启动参数的所以利用链设计要尽量避免触碰模块内部的私有成员。一个可行策略是只依赖公共APIpublic方法。JDK中专门有一批“陷阱”类——它们的public方法本身就干了危险的事比如com.sun.org.apache.xml.internal.security.c14n.helper.AttrComparator的compare方法会调用getNodeName并做类转换等操作整个方法体全是public调用完全不需要反射。这种类在无依赖场景下价值极高因为整个链路不涉及模块封装问题。实战中还发现一个规律高版本JDK中很多老的反射type绕过技巧被堵死但从“类加载本身”入手的思路依然有效。比如利用URLClassLoader加载远程jar包、利用TemplatesImpl加载字节码并实例化——这些动作依赖的主要是defineClass和newInstance这些API本身是public的不在模块封装范围内。所以链路构造的核心思路可以转向找到一条从被动回调到defineClass/newInstance的调用路径而不是执着于“反射访问私有字段”。2.4 关键工具准备和环境搭建做这类研究环境搭建直接决定效率。我的推荐组合是JDK 8u191、JDK 11.0.x、JDK 17.0.x各一套用容器或者独立目录隔离配合Maven管理依赖再加上一个抓包/序列化数据调试工具。Hessian的调试有个特点图形化IDE断点打在Hessian源码里非常直观但多版本切换时IDE对模块路径的处理和命令行不一致容易产生“本地能通、命令行不能通”的假象。所以我更建议把复现脚本写成命令行程序直接跑java -cp指定classpath这样最贴近真实环境。无依赖场景的“依赖”控制也很关键。实际操作里我会用jdeps命令分析目标代码的传递依赖加上-verbose:class启动参数观察运行时实际加载的类列表确保实验环境的类集合足够“干净”。一个讨厌的问题是Maven传递依赖很容易悄无声息引入一个顺手就能用的库导致你以为自己研究的是无依赖链实际却靠了某个传递依赖的类来搭桥。所以在正式实验前跑一遍启动日志、检查加载类列表是必须的。3. 实操过程与核心环节实现3.1 从HashMap入口构造一个最小实验链为了把原理讲清楚先做一个完全不涉及任何危险操作的最小实验——验证Hessian能否触发目标类被动方法。这里用的目标类是自己写的一个普通类EchoBean它有一个equals方法里面会把参数拼到字符串里。这个类放在classpath里模拟“目标环境自带类”。实验分三步走。第一步创建EchoBean实例设置其内部字段为一个字符串第二步用Hessian的HessianOutput把HashMap序列化其中map的key是自定义对象、value固定为某个字符串第三步用HessianInput反序列化观察EchoBean.hashCode或equals是否被触发。这套最小实验的核心价值在于验证“协议层到方法层”的连通性排查Hessian版本、序列化标志位、类型映射之间的问题。写完代码后跑起来的结果通常符合预期HashMap.put被调用时EchoBean.hashCode被触发当两个key的哈希碰撞时equals也被触发。这里有一个细节Hessian反序列化Map时key的读取顺序和value的读取顺序是交替的如果协议里明确了type信息会被HessianInput.resolve映射成具体类。若映射失败Hessian会把对象当作String处理链路静默断裂。这种故障在真实环境中极为常见——目标类不在classpath或者类名被改写导致整个利用链“看起来没反应”。3.2 在JDK高版本下验证TemplatesImpl链条可行性TemplatesImpl是Java反序列化利用链里的明星类它的核心机制是可以通过设置_bytecodes字段来加载字节码并在newTransformer()或getOutputProperties()时触发字节码加载。这条链在Hessian场景下能否复用关键看两件事第一Hessian能否通过setter或者字段注入成功设置_bytecodes等私有字段第二触发点能否被Hessian的某个被动行为串起来。实践发现Hessian自带的FieldDeserializer确实可以直接设置私有字段——它用Unsafe或反射绕过访问权限在JDK 8及部分JDK 11环境下畅通无阻。但在JDK 17的某些发行版上Unsafe对字段偏移的操作被限制部分字段被jdk.internal.vm.annotation.Stable标注写入会被JIT优化掉导致字节码数组设置不生效。绕过的思路是改用javassist或直接构造TemplatesImpl的序列化字节——但这就违背了“无依赖”的约束。所以在纯JDK高版本下直接依赖TemplatesImpl做链路终点并不理想。一个更务实的思路是把TemplatesImpl作为“中间状态”利用它与Translet类加载之间的逻辑关系在链路的某个节点把动作转换成“加载字节码实例化对象”。这个过程的验证需要分步做先用反射在本地完整模拟一遍Hessian对TemplatesImpl的设置顺序再用真实的HessianInput做端到端验证。踩过几次坑之后我的经验是JDK 8u191到JDK 11之间TemplatesImpl链路兼容性尚可JDK 17开始需要配合特定启动参数或更换触发方式。3.3 无依赖条件下的JNDI触发路径实测JDK高版本对JNDI远程类加载的限制早已路人皆知com.sun.jndi.ldap.object.trustURLCodebase默认false但JNDI触发本身依然是利用链构造的重要环节。原因很简单JNDI查找动作可以发生在受害服务端本地的上下文里如果目标classpath中存在可用的DataSource或ConnectionFactory实现getObjectInstance阶段就能在本地完成恶意对象绑定。实验中我重点验证了JdbcRowSetImpl的触发链将JdbcRowSetImpl实例的JNDI名称初始化为外部地址触发getDatabaseMetaData()时內部调用InitialContext.lookup。这条链在Hessian里的难点不是触发——只要被动方法能调到getDatabaseMetaData即可——而是“谁能调到getDatabaseMetaData”。找到一个JDK内置类的被动方法直接调用DataSource.getConnection或者RowSet.getDatabaseMetaData是无依赖链构造的核心瓶颈。我的实测结论是纯JDK环境能直接触发JdbcRowSetImpl的被动方法类极少多数情况下需要一个桥接类。而这个桥接类通常落在javax.sql.rowset.BaseRowSet的子类或者某些工具类的toString/equals实现里。这个发现也解释了为什么大量公开利用链都依赖了第三方库——第三方库提供了更丰富的“说话”类而纯JDK环境下“会说话”的类确实太少了。3.4 手工构造无依赖链的流程记录分享一下我自己构造一条无依赖链的完整流程这里以某个内部特征为例但不公布具体类名避免被恶意利用重点讲思路。第一步是在JDK源码里搜索“被动方法内危险操作”的模式。我直接打开源码全文搜hashCode()然后逐个人工判断方法体里是否存在类型转换、外部调用、参数传递。这个动作看着粗暴但效率极高——因为JDK里hashCode方法的实现动辄几十上百个其中有几个写得非常“奔放”把实例字段强制转换成接口类型或者调用外部扩展点。对这个搜索结果的筛选会花掉不少时间但每一行都可能对应一条新链路的起点。第二步是把候选类放入Hessian序列化流程里做连通性测试。这一步我写了一个通用测试驱动把候选类的实例塞进HashMap、Hashtable、TreeMap三种容器分别走Hessian的序列化/反序列化循环观察哪些被动方法被触发同时开启-verbose:class看触发过程中实际加载了哪些类。那些只在特定容器下才能触发的类往往意味着在Hessian的某种deserializer配置下存在可利用路径值得深入。第三步是手工画调用图。这一步我不用工具就是拿纸笔或者绘图软件把“被动方法→中间方法→最终动作”一条线画出来每一条线旁边标注涉及的可访问性public/private、模块边界、参数类型。画完调用图之后就能快速发现断点在哪里——有的是类型不匹配有的是模块访问受限有的是需要某个特定字段值但无法通过Hessian注入。根据断点再去查JDK源码往往能在意料之外的类里找到新的桥接方法。整个流程下来验证一条链路的平均耗时在两天到一周之间。这也是为什么很多公开报告里研究者会反复强调“链路的稳定性”——JDK版本一换方法内联、字段偏移、模块边界任何一处变化链路就重新归零。4. 常见问题与排查技巧实录4.1 Hessian版本差异带来的坑Hessian本身有多个版本com.caucho:hessian:4.0.x和com.caucho:hessian:3.3.x的行为差异会在利用链构造中体现出来。典型差异包括是否支持CompactMap、反序列化时对String与char[]的处理、对java.time类的映射方式等。建议是在实验前固定Hessian版本并在博文/报告中明确标注。若在某个版本下链路失效优先排查deserializer分支差异而不是怀疑JDK层面的问题。我踩过一次很典型的坑在Hessian在4.0.6上MapDeserializer私有字段的写入顺序与3.2.0不同导致同一个序列化payload在3.2.0版本下能成功设置字段在4.0.6下却被后续解析覆盖。排查方法是用Wireshark或类似工具抓取两次序列化数据做字节级对比发现字段顺序完全不同。后来通过显式控制序列化时Map的迭代顺序解决了这个问题这也说明了研究反序列化协议时“数据报文结构”和“类源码逻辑”同样重要。除此之外Hessian的Serialize包装器和UnsafeSerializer的开关会影响私有字段写入路径根据目标环境可配置项合理选择序列化器类型在可控序列化场景也是链路工程化的关键一环。4.2 JDK版本切换后的兼容性异常与处理低版本链路迁到高版本JDK时常出现的三类异常我列一个速查表方便排查时对照。异常类型典型报错常见原因处理建议模块访问异常InaccessibleObjectException反射访问模块封装类改用public调用路径或检查--add-opens参数字段偏移异常IllegalArgumentException: wrong number of argumentsUnsafe字段偏移计算失效显式使用反射字段对象而非偏移量类加载异常ClassNotFoundException/NoClassDefFoundError链路依赖的传递类不在classpath核对加载类列表启用-verbose:class序列化协议失配HessianProtocolException: expected mapHessian版本/序列化器类型不一致确保序列化端与反序列化端的协议参数完全相同此外高版本JDK对Unsafe的objectFieldOffset方法有兼容性问题某些类被Compact Fields重排了字段布局按名字获取字段再计算偏移仍然有效但按偏移直接读写可能命中错误字段。因此构造字节码之前的字段访问要尽量采用“字段名字符串反射Field对象”的方式而不是静态化写死偏移量。这在做JDK多版本兼容时非常管用。4.3 目标环境“无依赖”误判的识别方法在评估目标环境时“看着没有依赖”和“真的没有依赖”经常不是一回事。我在实测中遇到过这么一种情况目标系统只显式依赖了少量公共库但其中一个库传递依赖了一堆工具类最终classpath里远不止表面那几个jar。利用链在实验环境能通但去了目标环境又断了就是因为两个环境的传递依赖树不同。要避免这种误判有几个实操建议。第一拿到目标的pom.xml或build.gradle后做全量依赖树分析mvn dependency:tree找出所有传递依赖。第二启动时加-verbose:class采集实际加载的类列表比对利用链涉及的每个类是否都在其中。第三尝试在最小化classpath下复现链路——我通常先在一个只包含JDK自身和Hessian jar的干净环境里跑再逐步添加依赖直到链路首次连通为止。整个过程能让“无依赖”的定义严格落实到实验环境中。4.4 反序列化防御侧的绕过经验写完利用链构造的部分顺便把防御侧的对应措施也讲清楚毕竟很多读者做的是自己系统的加固。最有价值的防御点是对Hessian反序列化入口做类名白名单校验。因为Hessian协议传输时会携带类名在HessianInput层的readObject之前拦截并校验类名是成本最低、入侵最小的一种方案。白名单可以精确到模块、包名、甚至类型。实际部署时注意一个细节Hessian对某些JDK内部类型如HashMap$Node有独特映射与直接类名不完全一致因此白名单匹配规则要用“全限定类名内部类名”双重校验。我自己在框架层处理时是重写了HessianInput的getDeserializer方法在类名解析后立即做校验效果比在业务层过滤好得多。其次是控制反序列化入口的“可达性”——把RPC端口限定在内网、接口鉴权做严格化避免外部接触序列化面。同时从源头对Hessian的SerializerFactory做自定义限制关闭对Object类型及Throwable的默认序列化支持能大幅缩小“任意类实例化”的风险外沿。5. 更深一层的思考与扩展方向5.1 无依赖利用链与传统链路的宏观对比如果把无依赖链和传统依赖第三方库的链路放在一起比较可以发现一个有意思的规律第三库链路之所以“好打”是因为这些库的设计目标就是通用比如集合操作、模板引擎、表达式语言类内部本身就包含了很多可重用的业务动作而JDK内置类更偏向底层方法实现里直接触发外部动作的场合少得多所以很多链路需要叠加多层来“凑”出一个完整调用链。无依赖链的构造难度本质上是JDK内置类的“动作密度”太低导致的。但这并不意味着无依赖链不可能。一个反直觉的发现是高版本JDK对record、sealed class等新特性的引入反而在某些场景下提供了新的“类型闭合”类它们可以作为桥接类型使用。虽然它们本身的方法都很短但它们对接口的强制实现方式导致某些方法会强制调用toString/equals而这些行为从反序列化视角看可能打开了新的拼接路径。这类新方向显然还需要更多研究去验证。5.2 检测与防御视角下的链路追踪从防御者的视角看理解利用链构造的价值不只是“怕被攻击”而是可以更精准地提取检测特征。每条利用链都有其“特征指纹”——比如某种特定类型的HashMap嵌套、某个特定的异常类型抛出、某个特定的类加载序列。这些指纹在防御侧可以作为异常行为检测的基础。我给自己系统做检测规则时会直观地从链路调用图里提取两个特征一是被动回调方法到危险方法的调用深度一般超过3层就该警惕二是map嵌套层级与类型组合的频率。这两类特征可以做成低误报的检测规则比单纯堆黑名单类名效果更好。在JDK高版本下做检测还有一个优势新版本的JFRJava Flight Recorder和-Xlog支持更细粒度的类加载追踪能够在反序列化触发链路的第一时间记录到关键类加载时序。这些时序数据结合类名过滤规则能极大提升对未知利用链的检测能力。当然代价是性能开销实际部署时建议结合业务流量做采样而不是全量开启。5.3 后续演进方向与个人建议最后说点个人的研究体会。Hessian反序列化利用链的构造是一门“扣细节”的功夫。越是底层的东西越考验对JDK源码和协议规范的熟稔程度。想深挖这个方向的读者建议从三个基本功入手第一完整阅读Hessian源码中HessianInput、MapDeserializer、JavaDeserializer三个类的实现第二给自己出一个“JDK内置类被动方法清单”的题目把常见容器类触发的方法逐一列出来第三反复在多个JDK版本间交叉验证已知链路的差异形成“版本变异性”直觉。在我个人经验来看真正有价值的研究成果通常不是某一条具体的利用链而是那个“从被动方法到底层动作”的通用思考框架任何反序列化协议只要有对象图重建逻辑就存在从“解析动作”到“对象行为”的映射把这张映射表掌握清楚无论JDK怎么升级都能快速找到新的路径。这也正是Hessian研究带给我最重要的方法论沉淀——攻防的本质不是记住payload而是理解调用被触发的那一瞬背后的逻辑链。