企业官网建设流程全解析

把Java安全里值得反复咀嚼的课题排个序，反序列化漏洞一定能进我的个人榜单前三。而在反序列化这一大块内容里，从CC1到CC7这条完整的利用链演进脉络，又是每一个做漏洞研究、做安全开发、做攻防演练的人迟早都要面对的技术课。我最早看CC链时也被那一串类名绕晕过：AnnotationInvocationHandler、TransformedMap、LazyMap、ChainedTransformer、InvokerTransformer……直到后来把整条链理解成一趟“入口到执行”的接力跑，这堆名词才算真正串起来了。

这篇文章我不打算按教科书方式平铺直叙，而是以这些年实际调试和实战项目的视角，把CC1到CC7这七条链的来龙去脉、构造思路、版本限制、踩坑记录和防守侧的对应思路全部摊开讲。适合刚接触Java反序列化、想在本地复现和理解利用链原理的人，也适合已经在做安全研发、想搞清楚为什么CC6更稳定、为什么某些链被修复后还能绕过的人。

1. 为什么从CC1到CC7是绕不开的必修课

1.1 攻防两端都绕不开的原因

CC链的全称核心是围绕Java生态里一个非常普及的工具库——Commons Collections（下文统一叫CC库）展开的利用链集合。早年大量Java Web应用和中间件都会直接或间接依赖这个库，偏偏它里面又存在几个可以被反序列化流程利用的危险类。CC1到CC7，本质上就是安全研究者们在不同的库版本、不同的JDK版本、不同的入口类限制下，摸索出来的七条能达到相同目标的路径。

对防守方来说，这份素材的重要性甚至比对进攻方还高。如果只知道“升级CC库版本”或者“封掉几个类”，而不理解为什么封掉A类之后还有B类能打进，那漏洞就会反复在别的地方以变种形式出现。我见过不少次甲方明明已经更新了依赖，结果因为目标环境里某个业务模块自己引了老版本Jar，绕过程序包管理直接带病上线，最后还是被打穿。只有把利用链的构造逻辑吃透，才能在设计检测规则和应急策略的时候有据可依。

1.2 一条利用链的三段结构

我一直跟团队里的小朋友讲，CC链不管编号到多少，拆开看都是三段：入口触发点、中间转运器、最终执行点。

入口触发点是反序列化的发动位置，典型如某个类自己的readObject方法被调用后，会不自觉地去操作一个Map或者一个排序队列；中间转运器负责把“反序列化动作”传导成“对危险方法的调用”，比如ChainedTransformer、LazyMap、TiedMapEntry这类组件；最终执行点则是真正干坏事的地方，最常见的就是InvokerTransformer通过反射调用任意方法，或者TemplatesImpl直接加载恶意字节码。

打个比方，入口是发令枪，转运器是一棒接一棒的接力队员，执行点就是终点线后等着的人。很多新手容易犯的错是死记完整调用链，一旦环境版本变化导致某一棒跑不了，就完全不知道该怎么重新接线路。理解了分段结构，你就能针对每一段寻找替代类，这才是CC1到CC7真正的学习价值所在——它们不只是一堆Payload，而是一套“哪里断了就从哪里换接力棒”的动态思维。

1.3 七条链的宏观差异速览

动手研究之前，先看一眼整体版图会省力很多。我整理了一张自己平时参考的表，覆盖入口类、中间关键类、执行方式、适用库版本和主要限制。

这张表不用背，关键是怎么读。你会发现，所谓“新链”，大多数时候只是入口换了、中间某一段换了，最后的执行点往往还是那几个老面孔。这就是为什么钻研CC链至今仍有价值——底层思想没有变，包装方式一直在变。

2. 七条链的逐个拆解：从调用关系到版本限制

2.1 CC1：最经典的开门课

CC1是最早被公开完整披露的一批利用链之一。它走的是AnnotationInvocationHandler这个入口：该类的readObject方法在读入序列化数据后，会对成员变量里的Map执行entrySet操作，而这张Map如果被我们替换成TransformedMap或LazyMap这类由CC库提供的Map包装类，entrySet操作就会传导到危险Transformer上。

经典的CC1调用链大致长这样：

AnnotationInvocationHandler.readObject -> Map.entrySet -> TransformedMap / LazyMap.get -> ChainedTransformer.transform -> ConstantTransformer（拿到Runtime.class） -> InvokerTransformer（拿到Runtime实例） -> InvokerTransformer（执行exec方法）

这条链的巧妙之处在于，ChainedTransformer把一串Transformer串起来，前一个transform的输出正好是后一个transform的输入，最终用几个反射调用拼出一个完整的Runtime.exec。早期的攻击代码里可以写死一串命令，也可以动态拼接，原理都一样。

不过CC1有个绕不开的坎：JDK 8u71之后，AnnotationInvocationHandler.readObject不再直接对Map执行entrySet，而是先判断成员变量members是否为空，逻辑一变，原本的入口路径就走不通了。所以后来才有了各种在新版本JDK下仍然可用的链，也是CC2到CC7不断迭代的最初动机。

我第一次调试CC1是在JDK 8u65环境里，当时用了TransformedMap变体，Serializable文件生成后丢进目标进程，看到命令执行的那一刻确实很有成就感。但同样的Jar换到8u121环境里，Payload完全静默，这才促使我去关注“为什么”，而不是停留在“怎么打”。

2.2 CC2：绕开入口限制的另一条路

CC2的思路和CC1完全不同。它不再依赖AnnotationInvocationHandler，而是盯上了PriorityQueue。PriorityQueue是Java自带的优先队列类，反序列化时会把队列元素重新排一遍，排序过程中会调用Comparator的compare方法。如果我们能把一个危险Transformer包装成一个Comparator，反序列化排序动作就等于替我们完成了危险调用。

CC2的完整路径大致如下：

PriorityQueue.readObject -> heapify -> siftDownUsingComparator -> TransformingComparator.compare -> ChainedTransformer.transform -> InvokerTransformer / Runtime.exec

这里有一个关键前提：TransformingComparator在CC库的3.x版本中并没有实现Serializable接口，没法被序列化，所以CC2只适用于CC 4.0及之后版本。正是因为4.0里Comparator相关的几个类被改造成了可序列化，才给了这条链生存空间。

CC2给我的最大体会是“入口不一定要是readObject里直接调危险方法”。PriorityQueue本身跟命令执行毫不相关，但因为它会在反序列化时调用外部传入的Comparator，就变成了一个“借刀杀人”的跳板。这种间接性正是利用链设计的核心美学——每个参与者都只做一点点事，串起来才致命。

2.3 CC3：把命令写死换成字节码加载

CC3的贡献在于改变了最终执行点的选择。前两条链最终都是通过InvokerTransformer去反射调用Runtime.exec，但在实际攻防中，“命令执行”这种特征容易被Java进程内的安全审计代码盯上，而且碰上命令被过滤的环境就不那么灵光了。CC3换成TemplatesImpl来加载字节码。

TemplatesImpl是JDK里处理XSLT模板的类，它有内部属性可以存放自定义的字节码，并在调用newTransformer方法时触发字节码加载。CC3的思路是先用InstantiateTransformer构造一个TrAXFilter对象，而TrAXFilter的构造函数里会调用Templates.newTransformer，这样就完成了“构造对象即触发字节码加载”的接力。

AnnotationInvocationHandler.readObject -> LazyMap.get -> ChainedTransformer -> ConstantTransformer(TrAXFilter.class) -> InstantiateTransformer(TemplatesImpl) -> TrAXFilter构造函数 -> TemplatesImpl.newTransformer -> 加载恶意字节码

对比CC1来看，CC3只是把最后“反射调用Runtime.exec”这一段，换成了“实例化TrAXFilter触发TemplatesImpl”，中间段的ChainedTransformer和LazyMap都还能继续复用。这种“只替换最后一棒”的思路特别值得学习，做蓝队研究时，看到某个执行点被封了，第一反应不该是放弃，而是寻找另一个能达到同类效果的类。

2.4 CC4：CC2与CC3的正交组合

CC4是一条经常被人忽略、但结构上非常工整的链。它把CC2的PriorityQueue入口和CC3的TemplatesImpl执行点结合在一起，中间用TransformingComparator做转运。简单地讲，CC4就是用CC2的进场方式，跑CC3的终点线。

PriorityQueue.readObject -> TransformingComparator.compare -> ChainedTransformer -> ConstantTransformer(TrAXFilter.class) -> InstantiateTransformer(TemplatesImpl) -> TrAXFilter构造函数 -> TemplatesImpl.newTransformer

这也解释了为什么CC4必须依赖CC 4.0的TransformingComparator可序列化能力。CC4的实战价值在于它同时绕开了两个方向的限制：既不用AnnotationInvocationHandler，也不依赖InvokerTransformer直接反射执行命令。很多防守规则如果只针对“CC1特征”或“CC3特征”，就容易漏掉这条组合链。

我个人的学习建议是，把CC2、CC3、CC4放在一起看。CC2解决入口，CC3解决执行点，CC4证明这两个维度是自由组合的。一旦建立这种意识，再面对未来新公开的链时，就不会觉得又是什么全新东西，本质上还是熟悉的那些积木换了拼法。

2.5 CC5：从Map入口转到异常类入口

CC5的诞生背景是CC1入口失效。它选的入口是BadAttributeValueExpException，这是Java标准库里的一个异常类，反序列化时它的readObject方法会对传入的val对象调用toString。而TiedMapEntry这个CC库类正好在其toString方法里调用了map.get，再配合LazyMap，整条链就活了。

BadAttributeValueExpException.readObject -> valObj.toString -> TiedMapEntry.toString -> LazyMap.get -> ChainedTransformer.transform -> InvokerTransformer / Runtime.exec

这条链里面的明星是TiedMapEntry，它本质上是一个“键值对条目”的包装类，内部持有Map和key两个成员变量。toString、hashCode、equals这些最常见的方法，它都会转发给内部的Map操作。这种“借力”设计让其成为后续多条CC链通用的中间转运器，CC6、CC7里都能看到它的身影。

CC5的实战应用场景多在高版本JDK的默认环境中，因为BadAttributeValueExpException和TiedMapEntry都不涉及高版本JDK的变更逻辑。不过这条链的限制也很明显：反序列化入口是否能触发异常类的toString，取决于目标环境的Java安全管理器和类加载策略，不同JDK小版本的行为差异也需要逐一验证。

2.6 CC6：目前最通用也最稳妥的链

CC6是我个人平时测试时最常用的链，没有之一。它把入口换成了HashMap——这是所有JDK版本都自带、必然可序列化的类。HashMap在反序列化时会对每个key执行hashCode，如果把key设计成TiedMapEntry，它的hashCode会转发给内部Map.get，后面接LazyMap，就能一路触发到InvokerTransformer。

HashMap.readObject -> hash(key) -> TiedMapEntry.hashCode -> TiedMapEntry.getValue -> LazyMap.get -> ChainedTransformer.transform -> InvokerTransformer / Runtime.exec

CC6的稳定性来自它对JDK版本的挑剔极少。HashMap从Java 1.2到目前最新版本，读入元素后的hash逻辑基本没动过；CC库里的TiedMapEntry和LazyMap在3.x和4.x版本中都存在且可序列化。这让它成为跨版本测试时的首选路径，也是我在培养新人的时候教的第一条完整可复现链。

构造CC6时有个小坑：你直接把TiedMapEntry作为key放进HashMap，序列化前HashMap会先计算一次hash。如果TiedMapEntry对应的LazyMap里有危险Transformer，那么它在本地构造阶段就会提前触发命令执行，导致Payload还没发出去，自己环境先中招。解决办法是把危险Transformer数组先放进一个空的LazyMap里，但放入HashMap时要保证LazyMap的某个标记为未触发状态，等反序列化时才真正生效。这块细节等到第三节实操部分我再展开。

2.7 CC7：利用Hashtable哈希碰撞的神奇路径

CC7可能是七条链里最巧妙也最绕的一条。它选的入口是Hashtable，这是另一个Java老牌集合类。Hashtable反序列化时会调用reconstitutionPut方法把元素重新放回哈希表，这个方法内部会对key做hash和equals比较，处理哈希碰撞时还会调用equals。CC7利用的恰恰是两次元素在同一个哈希桶里碰撞时，对两个LazyMap包装后的TiedMapEntry执行equals，最终push到LazyMap.get。

Hashtable.readObject -> reconstitutionPut -> key.hashCode -> TiedMapEntry.hashCode -> LazyMap.get -> 碰撞时 key.equals -> TiedMapEntry.equals -> LazyMap.get -> ChainedTransformer.transform -> InvokerTransformer / Runtime.exec

这条链构造复杂，因为它需要你先构造出一对哈希值相同但又不完全相等的TiedMapEntry，才能让Hashtable在反序列化过程中调用到equals，并确保此时加载的Transformer才被赋值到LazyMap里。序列化前和序列化后，LazyMap的状态必须被精细控制，稍微差一步就会在本地构造阶段提前触发。

CC7给我的启发是，入口触发点远不只是一堆readObject方法。Java集合类的底层实现细节，比如哈希表碰撞处理，也能成为反序列化触发链的一部分。研究这类链时，重要的已经不是“这个类能不能序列化”，而是“这个类的内建逻辑会不会在某个时期调用到我们可控的外部对象”。

3. 本地复现与调试：从PoC到断点的完整过程

3.1 搭建可复现的实验环境

复现CC链不需要高性能机器，一个干净的操作系统加一个老版本JDK就够了。建议准备JDK 8u65和8u121两个版本，前者用于体验CC1等旧链，后者用于验证新链在高版本下的表现。然后在IDE里建一个Maven工程，引入CC库老版本依赖。

<dependencies> <dependency> <groupId>commons-collections</groupId> <artifactId>commons-collections</artifactId> <version>3.2.1</version> </dependency> </dependencies>

如果你还想尝试CC2和CC4，需要换成4.0版本。最方便的做法是把两个版本的Jar都下载到本地，用IDE里的“添加外部Jar”功能切换，避免反复改pom.xml。我自己习惯建两个Module，一个用3.2.1，一个用4.0，调试起来互不干扰。

实验环境里还要准备好序列化工具方法。所谓PoC，说白了就是先把一个构造好的危险对象通过ObjectOutputStream写进文件，再用ObjectInputStream读出来。触发点在反序列化的“读”这一侧。

public static void serialize(Object obj, String path) throws Exception { try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(path))) { oos.writeObject(obj); } } public static void deserialize(String path) throws Exception { try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream(path))) { ois.readObject(); } }

这两个工具方法虽然简单，却是几乎所有CC链复现的基础设施。真正研究时，你写的主要精力都花在“如何构造成一个Object”上，也就是构造阶段。

3.2 在断点里读懂一次完整的调用栈

我强烈建议所有初学者不要只跑通工具生成的Payload，一定要亲手在IDE里下一组断点，亲眼看清调用栈是怎么一步步推进的。

以CC6为例，你可以在这几个位置下断点：

• HashMap.readObject，看反序列化开始后第一次进入HashMap的逻辑。
• TiedMapEntry.hashCode，看key的hash计算如何触发到TiedMapEntry。
• LazyMap.get，看get方法里如何判断不存在时触发factory.transform。
• ChainedTransformer.transform，看一串Transformer如何按顺序执行。
• InvokerTransformer.transform，看到达最终反射调用的现场。

调试时最震撼的一刻是，你在InvokerTransformer的断点里回看完整调用链，发现从HashMap到最终命令执行，每一层的调用都毫无多余动作。这种直观感受比看任何文档都有用。

实践中可以这样构造CC6的核心对象：

Transformer[] transformers = new Transformer[] { new ConstantTransformer(Runtime.class), new InvokerTransformer("getMethod", new Class[] { String.class, Class[].class }, new Object[] { "getRuntime", new Class[0] }), new InvokerTransformer("invoke", new Class[] { Object.class, Object[].class }, new Object[] { null, new Object[0] }), new InvokerTransformer("exec", new Class[] { String.class }, new Object[] { "open -a Calculator" }) }; ChainedTransformer chainedTransformer = new ChainedTransformer(transformers);

然后包一层LazyMap，再包一层TiedMapEntry，最后put进HashMap。构造时需要注意：在把TiedMapEntry放进HashMap之前，先不把真正的chainedTransformer传给LazyMap，否则本地会提前执行命令。标准套路是先给LazyMap传一个无害的Transformer，等序列化前再通过反射把factory替换成真正的chainedTransformer。利用反射修改私有字段是这条链里最常用的技巧，JDK高版本还需要加上setAccessible处理模块限制。

3.3 快速识别当前环境的版本约束

调试过程中，最常见的困惑是“这条链在这个环境里为什么不触发”。排查思路主要看三个维度：

第一看JDK版本。如果入口走的是AnnotationInvocationHandler这条老路，检查当前JDK是否高于8u71；如果高于8u71，请优先换用CC6这种HashMap入口的链。

第二看CC库版本。老版本的TransformingComparator不可序列化的坑已经提过，如果你确认目标里CC库是4.x，才考虑CC2和CC4；如果目标是3.2.1，则选择CC1、CC3、CC5、CC6或CC7。

第三看目标环境是否启用了反序列化过滤机制。如果JVM启动参数或容器层配置了ObjectInputFilter，你会发现连序列化流里的类解析都会被拦截，此时需要先确认过滤规则是黑名单还是白名单，黑名单通常可以通过寻找未列入名单的入口类绕过，白名单则难度大得多。

识别这些信息时有个经验：不要急着一次就试完全部链，而是先构造一个“最小验证”对象，比如只反序列化一个自定义类，确认反序列化功能本身正常，再一步步加中间环节。很多“不触发”其实是环境里反序列化被整体禁用了，跟利用链选择毫无关系。

4. 防守视角：修复、过滤、检测的落地方式

4.1 升级版本只是起点，不是终点

CC库官方对漏洞的回应是逐步封堵高危类。3.2.2版本里，InvokerTransformer等类不再实现Serializable，等于从根上让依赖反射调用的链失效；4.1和4.2中，更多中间组件也被加入了黑名单或取消了序列化能力。这个方向是对的，但放在真实企业环境里，只盯“框架依赖升级”远远不够。

我见过太多系统，主程序确实升到了最新版本，可某个内部业务模块依然以独立的Jar形式引入老版本CC库，或者某个自研框架把CC库的低版本逻辑复制了一份内嵌进去。这种依赖下沉的问题，用集中升级的方式根本查不出来。应对办法是上线前扫描全部依赖树，不只扫描顶层pom文件，还要扫描最后打包产物里包含的所有Jar，看看有没有低版本类潜伏在里面。

4.2 代码层的纵深防御：不只是黑名单

从代码维度看，反序列化过滤是现阶段最有效的手段之一。JEP 290为Java平台引入了对象输入过滤机制，可以通过ObjectInputFilter配置允许或拒绝类。白名单策略比黑名单可靠得多，因为你只需要列举出业务运行时需要反序列化的合法类，其他类一律拒绝，这样就算利用链如何变化，只要危险类不在白名单里就打不进来。

但白名单在真实项目里推行并不容易，很多老系统的反序列化数据里混杂着大量动态代理类、第三方框架类，列白名单会带来兼容问题。折中方案是分级实施：对核心涉密系统采用严格白名单，对普通业务系统采用黑名单加RASP兜底。黑名单里的重点关注对象基本上就是CC链里反复出现的那些类：InvokerTransformer、InstantiateTransformer、TransformingComparator、TemplatesImpl、LazyMap、TiedMapEntry等等。

另外可以考虑对ObjectInputStream做全局子类化，比如定义一个安全ObjectInputStream，重写resolveClass方法，在里面统一执行类过滤逻辑。这种方式改动量小，又能集中管控，很适合已有项目接入。

4.3 检测与溯源：如何发现利用行为

检测层面最实用的是调用链采样。RASP类产品之所以能抓漏洞利用，本质上不是靠正则匹配Payload，而是靠方法调用栈里出现了“正常业务不该出现的组合”——例如TemplatesImpl.newTransformer往下跟TrAXFilter构造函数连续出现，或者InvokerTransformer.transform往上翻到LazyMap.get。这种基于行为和调用关系的检测，比单纯匹配类名准得多，也很难被简单混淆绕过。

流量侧检测也不可放弃。序列化数据以二进制形式传输，但开头通常带有Java序列化流头的特征字节。如果看到某个请求体里出现0xACED 0x0005这样的开头，或者经过Base64编码后对应ACED0005字样，都要高度警惕。很多企业只盯着HTTP明文流量，忽略了二进制体统中大量反序列化入侵，这是防守盲区。

我自己做检测规则时有个习惯：先跑通所有CC1到CC7的本地复现，把每条链在关键方法处的调用栈特征记录下来，再把这些特征转换成RASP规则。这个工作看起来费时，但它能让规则真正贴合利用链的骨架，而不是浮在表面匹配类名。

5. 常见问题、误区和我的实操体会

5.1 实战中踩过的几个大坑

第一个坑是CC1在JDK 8u71之后的静默失败。早期我不看JDK版本，直接拿现成Payload打内网，结果目标毫无反应。排查了大半天，最后发现目标JDK版本已经高于8u71，入口类行为变了。这件事之后我的习惯就变成了：每到一个环境，第一件事不是打Payload，而是先想办法摸清JDK版本和CC库版本。

第二个坑是CC6的构造阶段直接触发命令。有一次我在本地生成Payload时，想确认命令是否真的被执行，结果序列化还没写完，弹出一次命令执行窗口。原因就是构造HashMap时，没有把LazyMap里的factory先换成无害Transformer。那时起我就养成了“构造链时必须先把危险组件和集合对象彻底隔离”的纪律。

第三个坑是系列化流里的类在目标环境不存在。同一个CC链在本地跑得通，到了目标环境就报ClassNotFoundException。原因往往是你的测试依赖里有额外的库，而目标环境没有。排查方法是查看异常堆栈里缺少的是哪个类，去判断是链本身的问题还是环境依赖的问题。这个教训让我更注重用最小化依赖来测试链，避免把无关Jar一并打进Payload。

5.2 我平时选择利用链的次序

真到复盘排查的时候，我不会一条条盲试，而是按通用程度排优先级。首选CC6，因为它对JDK和CC库版本的容忍度最高，HashMap入口基本是百搭；如果CC6失败，再试CC5，考虑BadAttributeValueExpException入口是否被过滤；接着试CC2和CC4，但前提是确认目标用了CC 4.0及以上版本；最后才考虑CC1和CC3，因为它们受高版本JDK限制太明显，只有在明确是老环境时才值得花时间。

这个次序不是固定金科玉律，它只是基于“入口类是否受版本影响、中间类是否随处可用、执行点是否容易被拦截”这三条标准的自然排列。你也完全可以按自己的需求做调整，但建议每一轮测试都要记录失败原因，而不是单纯换一个链继续撞运气。

5.3 研究的边界和方法论复盘

反序列化研究做久了，我最大的心得是：危险的不是某个库的某个类，而是Java生态里“把对象序列化或反序列化”这件事本身太过隐式。任何能被反序列化且内部逻辑会对外部对象调用方法的地方，都可能成为利用链的一环。CC1到CC7虽然已经是有些年头的样本，但那种“从一个普通入口一步步编排到命令执行”的思维方式，放到今天依然能指导我们发现新型链。

还要说一句常被忽略的话：做这些研究一定要控制在自有环境或获得授权的测试环境中。利用链本身是安全研究的教学内容，但同一条链落在不合适的地方就会变成违法工具。理解攻法是为了更好地防，这个边界越清晰，技术研究的路才能走得越稳越远。

最后再分享一个我自己保留的习惯：每研究完一条链，我都会在笔记里画一张带注释的调用图，把每个类在每个环节里扮演的角色写清楚，下一次做检测规则或排查问题时直接翻笔记定位关键节点。这个习惯让我没有陷入“过一段时间就忘”的循环。这个内容后续还可以延伸的方向也不少，比如研究其他库与CC库的串联利用、分析不同JDK版本的过滤机制演进，或者把精力花在反序列化检测规则的自动化生成上。CC1到CC7只是个入口，背后那片海才值得慢慢游。