从一次 Java 反序列化告警看依赖治理与代码审计

背景

Java 反序列化问题这几年被反复讨论，但在真实业务里，它并不会因为框架升级就自然消失。很多告警不是来自新漏洞，而是来自历史依赖、灰度服务、内部工具、测试接口以及“临时兼容逻辑”。我在做代码审计和应急排查时，遇到过不少类似场景：安全设备提示存在反序列化风险，业务侧反馈“没有对外接口”“只是内部调用”，但继续追下去，往往能发现依赖版本、数据入口和对象转换逻辑之间存在比较隐蔽的风险链。

这篇文章不讨论可用于攻击的利用细节，重点放在如何判断一个 Java 服务是否真的存在反序列化风险，以及如何通过依赖治理、入口梳理和代码审计降低长期风险。

典型场景

一个比较常见的场景是：某个业务服务使用 JSON 序列化库处理外部请求，同时项目中保留了较老版本的依赖。安全扫描或流量检测发现请求体中存在异常类型字段、类名片段或可疑结构，于是产生告警。

业务排查时经常会遇到几个问题：

• 项目依赖树里存在多个版本的同一 JSON 组件，实际运行版本不清晰。
• 接口层看起来只接收普通 DTO，但底层工具类存在通用对象反序列化方法。
• 部分内部接口缺少认证或只依赖网段隔离。
• 历史兼容逻辑中开启了高风险特性，例如自动类型识别、宽松对象绑定等。
• 测试环境配置被复制到生产环境，导致安全开关状态不一致。

所以，处理这类问题不能只看单个接口是否“能打通”，更应该确认：数据从哪里来、经过哪些解析器、是否触发类型恢复、类路径中是否存在高风险组件。

技术分析思路

1. 先确认依赖与实际运行版本

Maven 项目建议先查看完整依赖树，重点关注 JSON、XML、RPC、缓存、消息队列相关组件。很多反序列化风险并不直接出现在业务代码里，而是被框架间接引入。

mvn dependency:tree -Dverbose > dependency-tree.txt

# 常见关注点：
# fastjson / jackson-databind / xstream / hessian / kryo
# dubbo / spring-remoting / activemq / shiro / commons-collections

如果是 Gradle 项目，可以使用：

./gradlew dependencies --configuration runtimeClasspath > dependencies.txt

排查时不要只看 pom.xml 或 build.gradle 中的直接依赖。更关键的是运行时类路径，尤其是 fat jar、容器镜像、应用服务器公共 lib 目录中是否存在旧版本 jar。

# 查看 jar 内部依赖
jar tf app.jar | grep -Ei 'fastjson|jackson|xstream|hessian|commons-collections'

# 容器内确认实际文件
find /app /opt /usr/local -type f \( -name "*.jar" \) | grep -Ei 'fastjson|jackson|xstream'

2. 梳理数据入口

反序列化风险的核心不只是“用了某个库”，而是“不可信数据是否进入了危险解析路径”。建议优先梳理以下入口：

• HTTP 请求体：JSON、XML、表单字段、文件上传后的内容解析。
• 消息队列：Kafka、RabbitMQ、RocketMQ、ActiveMQ 等消费者。
• RPC 接口：Dubbo、Hessian、RMI、Thrift、自研 TCP 协议。
• 缓存与会话：Redis、Memcached、Session 存储中的对象恢复。
• 定时任务：从数据库、对象存储、配置中心读取后反序列化。

代码审计时可以全局搜索一些通用解析方法。这里给出的是排查方向，不代表所有调用都有问题，需要结合参数来源判断。

grep -R "parseObject\|parseArray\|readValue\|fromJson\|fromXML\|readObject\|deserialize" -n src/main/java

grep -R "ObjectInputStream\|XMLDecoder\|XStream\|HessianInput\|Kryo" -n src/main/java

3. 关注危险用法，而不是只看组件名

以 JSON 反序列化为例，安全风险通常来自几个方向：

• 允许客户端控制目标类型或类型标识。
• 使用 Object、Map、泛型擦除后的容器承接外部输入。
• 开启自动类型识别、默认类型绑定、宽松多态反序列化。
• 反序列化后对象存在危险生命周期方法，例如初始化、setter、toString、finalize 等被间接触发。
• 类路径中存在具备危险副作用的第三方类。

审计时可以重点看这种模式：

// 风险较高：外部输入直接进入通用 Object 解析
Object obj = JsonUtil.parse(requestBody, Object.class);

// 风险较高：类型来自请求参数、消息字段或数据库可控字段
Class<?> clazz = Class.forName(typeName);
Object obj = mapper.readValue(body, clazz);

// 相对更可控：固定 DTO，关闭未知字段或做白名单校验
UserCreateRequest req = mapper.readValue(body, UserCreateRequest.class);

这里的重点不是某个 API 一定危险，而是外部数据是否能影响类型选择、对象结构和后续行为。

关键排查步骤

步骤一：建立最小可复现环境

不要直接在生产环境做尝试。建议从生产镜像或发布包中提取依赖，在隔离环境中启动服务或编写最小调用单元，复现解析链路。这样能避免误判，也方便验证修复效果。

# 示例：提取运行环境中的 jar 列表
mkdir -p audit-libs
cp /app/libs/*.jar audit-libs/

# 记录 Java 版本
java -version

# 记录启动参数
ps -ef | grep java

有些风险与 JDK 版本、类路径、框架配置强相关。单独看源码不一定能判断完整结果。

步骤二：确认是否存在不可信输入

建议画一条简单的数据流：

请求/消息/缓存数据
    ↓
Controller / Consumer / Listener
    ↓
通用解析工具类
    ↓
DTO / Object / Map / 自定义类型
    ↓
业务处理 / 反射调用 / Bean 拷贝 / 表达式执行

如果输入只来自内部系统，也不能直接认为安全。内部系统被攻破、测试环境误连生产、消息队列权限过宽、服务间调用缺少鉴权，都会让“内部输入”变成不可信输入。

步骤三：检查安全配置

常见 JSON 库和 XML 库都有自己的安全选项。不同版本配置方式差异较大，建议以项目实际版本文档为准。总体原则是：

• 关闭自动类型识别、默认类型绑定等高风险能力。
• 固定反序列化目标类型，避免由外部传入类名。
• 对确需多态的场景使用白名单，而不是黑名单。
• 限制最大输入长度、最大嵌套层级，避免资源消耗型风险。
• 解析失败要中断流程，不要降级为通用 Object 继续处理。

例如 Jackson 场景下，应避免对外部输入启用宽泛的 default typing。对于确需多态的业务对象，可以用明确的子类型注册和业务字段校验替代。

// 示例：固定目标 DTO，并对字段做校验
ObjectMapper mapper = new ObjectMapper();
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, true);

OrderRequest req = mapper.readValue(json, OrderRequest.class);
validateOrderRequest(req);

步骤四：检查对象后处理逻辑

有时反序列化本身没有直接问题，但后续处理会放大风险。需要重点检查：

• 反序列化后是否进行反射调用。
• 是否根据字段值动态加载类、执行脚本或表达式。
• 是否把对象直接传入模板引擎、规则引擎、SQL 构造器。
• 是否存在 BeanUtils.copyProperties 这类宽松属性拷贝，并影响敏感字段。
• 是否把反序列化结果写入日志、错误信息或监控标签，导致信息泄露。

一个常见问题是“类型解析”与“业务执行”分散在不同模块，单独看某一段都不明显。审计时要把调用链串起来看。

修复建议

1. 依赖升级与收敛

升级不是简单把版本号改高。建议同时做依赖收敛，避免同一组件多个版本共存。

# Maven 检查依赖收敛
mvn -DskipTests enforcer:enforce

# 查看重复依赖
mvn dependency:tree -Dverbose | grep "omitted for conflict"

可以在父 pom 中统一版本，并禁止子模块私自引入旧版本。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.x.x</version>
    </dependency>
  </dependencies>
</dependencyManagement>

2. 类型白名单

如果业务确实需要根据类型字段还原对象，建议把可接受类型限制在业务 DTO 范围内，并且类型标识使用业务枚举，不要直接使用完整类名。

enum MessageType {
    ORDER_CREATED,
    ORDER_CANCELLED
}

Object parseMessage(MessageType type, String body) throws IOException {
    switch (type) {
        case ORDER_CREATED:
            return mapper.readValue(body, OrderCreatedEvent.class);
        case ORDER_CANCELLED:
            return mapper.readValue(body, OrderCancelledEvent.class);
        default:
            throw new IllegalArgumentException("unsupported message type");
    }
}

这类写法看起来不够“通用”，但安全边界清晰，后期维护成本反而更低。

3. 输入校验与资源限制

对反序列化入口增加基础限制，可以降低误用和资源消耗风险：

• 限制请求体大小。
• 限制集合长度和字符串长度。
• 限制 JSON/XML 嵌套层级。
• 对枚举、金额、时间、ID 等字段做严格校验。
• 拒绝未知字段，避免隐藏字段影响后续逻辑。

网关、应用容器和业务代码都可以做限制。不要只依赖某一层。

4. 移除不必要的危险组件

有些高风险类库只是历史遗留，业务并未真正使用。建议从依赖树中排除，减少类路径攻击面。

<dependency>
  <groupId>example.group</groupId>
  <artifactId>example-sdk</artifactId>
  <version>1.0.0</version>
  <exclusions>
    <exclusion>
      <groupId>commons-collections</groupId>
      <artifactId>commons-collections</artifactId>
    </exclusion>
  </exclusions>
</dependency>

排除前要跑完整测试，确认没有运行时依赖。安全修复不能以业务不可用为代价。

检测与监控

生产侧可以从几个维度做长期监控：

• 接口层记录解析失败率，异常升高时告警。
• 日志中关注异常类名、类型字段、未知字段、超大请求体。
• 网关或 WAF 侧对异常序列化特征做低置信度告警，不建议直接阻断核心业务。
• CI 阶段加入依赖漏洞扫描和依赖收敛检查。
• 对消息队列消费者增加死信队列监控，避免异常消息反复触发解析。

日志不要记录完整请求体，特别是包含令牌、手机号、身份证号、业务密钥等敏感信息的场景。可以记录摘要、长度、来源、接口名、异常类型，便于排查即可。

常见误区

• 只要接口不对公网开放就安全：内部链路也需要鉴权、最小权限和输入校验。
• 升级组件就一定修好：危险配置和不安全代码模式仍然可能存在。
• 扫描器没报就没有问题：很多风险依赖业务调用链，静态扫描覆盖有限。
• 黑名单足够：类库和依赖变化很快，黑名单维护成本高且容易遗漏。
• 测试环境无所谓：测试环境常保存真实配置或可访问内部资源，风险不低。

一个实用审计清单

总结

Java 反序列化风险的排查，不能停留在“有没有某个 CVE”或“某个接口能不能复现”这个层面。更可靠的方式是围绕数据流做审计：不可信输入从哪里进入，经过什么解析器，目标类型如何确定，反序列化对象后续又参与了哪些业务逻辑。

长期治理上，建议把依赖收敛、安全配置基线、危险 API 检查和入口鉴权纳入日常研发流程。这样即便后续出现新的组件漏洞，也能更快判断影响范围，减少临时救火成本。

安全修复最怕“只修告警，不修模式”。把通用解析、动态类型、内部弱鉴权这些问题逐步收敛，才是减少反序列化类风险的关键。