Java ObjectInputFilter 怎么拒绝危险类型：序列化白名单、深度限制与异常验收

线上服务如果还要读取 Java 原生序列化数据，真正危险的不是“能不能反序列化”，而是输入里的类、对象图和数据量是否都在预期范围内。ObjectInputFilter 可以把这道检查放到 ObjectInputStream 读取对象的边界上：先允许明确的业务类型，再拒绝未知类型，同时限制深度、引用数量和输入字节数。

先判断：问题在类型边界还是资源边界

排查反序列化异常时，先把现场分成两类。输入包含不在业务协议内的类，属于类型边界；输入类型看似正常，但对象图过深、引用过多或读取字节过大，属于资源边界。两者都要在读取前后留下可判断的结果，不能只记录一句“反序列化失败”。

Java 的过滤器会在读取对象图时获得类名、数组长度、引用数量、深度和已读取字节数等信息。它既可以通过模式字符串创建，也可以按 ObjectInputFilter.FilterInfo 写成代码规则。

处理步骤：先写允许类型，再补上资源上限

简单场景可以使用 Config.createFilter 生成模式过滤器。模式由分号分隔，类名规则可以允许或拒绝包名，资源上限使用 maxdepth、maxrefs、maxbytes 和 maxarray。

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
        "com.example.dto.*;java.util.ArrayList;!com.example.internal.*;"
                + "maxdepth=12;maxrefs=200;maxbytes=1048576;maxarray=10000");

这段规则表达的是一个保守边界：业务 DTO 和指定集合可以继续读取，内部实现包明确拒绝；对象图深度、引用数、输入字节数和数组长度也各自有上限。实际项目里的数值要从合法样本的峰值和余量推导，不能照抄成“安全默认值”。

如果规则需要结合业务状态，代码过滤器更容易读懂。下面的判断只展示边界，不把日志、账号或原始输入内容写入异常信息：

ObjectInputFilter filter = info -> {
    if (info.depth() > 12 || info.references() > 200
            || info.streamBytes() > 1_048_576) {
        return ObjectInputFilter.Status.REJECTED;
    }

    Class> serialClass = info.serialClass();
    if (serialClass == null) {
        return ObjectInputFilter.Status.UNDECIDED;
    }

    String name = serialClass.getName();
    if (name.startsWith("com.example.dto.")
            || name.equals("java.util.ArrayList")) {
        return ObjectInputFilter.Status.ALLOWED;
    }
    return ObjectInputFilter.Status.REJECTED;
};

serialClass() 在某些检查点可能还没有可用的类，因此返回 null 时应暂时交给后续判断。这里把资源限制放在前面，是为了让明显超限的输入尽早停止；类型白名单则负责收紧协议范围。

把过滤器装到 ObjectInputStream 的入口

过滤器创建出来还不够，必须安装到实际读取对象的流上。局部安装适合不同接口有不同协议的服务，也更容易在单元测试里替换规则：

try (ObjectInputStream input = new ObjectInputStream(source)) {
    input.setObjectInputFilter(filter);
    Object value = input.readObject();
    // 这里再做业务层的字段校验
}

过滤器只负责反序列化阶段的类型和资源边界，不等于业务校验。即使对象类型被允许，字段范围、状态转换和权限归属仍要在对象读出后单独检查。不要因为过滤器返回 ALLOWED 就把对象当成可信业务数据。

快速判断：拒绝结果应该如何被验收

当过滤器返回 REJECTED，读取过程通常会以 InvalidClassException 结束。调用层应该区分“输入被策略拒绝”和“数据损坏、版本不兼容”等其他读取错误，日志里保留规则版本和边界名称即可，不要记录原始序列化内容。

回滚路径：先缩小入口，再调整规则

如果上线后合法数据被误拒，先确认命中的究竟是类名、深度、引用数还是字节数。临时回退应回到上一版经过验证的过滤规则，不要直接删除过滤器或改成全量放行。对新增 DTO，先加入明确的允许范围，再补一条包含嵌套对象和数组的回归样本。

如果服务已经无法读取历史数据，优先保留原始数据的访问隔离和审计信息，在离线环境里用兼容规则转换到新的协议。不要为了迁移方便，把不受控的序列化流直接接回线上入口。

告警确认与复盘：证明边界真的在工作

告警不要只统计总异常数。至少把拒绝原因分成类型、深度、引用数、字节数和数组长度几类，并记录过滤规则版本。这样才能看出是攻击性输入增加，还是业务发布引入了合法对象图变化。

• 允许 DTO 的读取成功率保持稳定，且字段校验仍然执行。
• 未知类型样本得到明确拒绝，不会落到业务处理分支。
• 逐项提高深度、引用数和字节数样本，确认每个阈值都能触发拒绝。
• 日志不包含原始字节、Cookie、令牌或完整对象内容。

常见问题

ObjectInputFilter 能代替业务字段校验吗？

不能。它解决的是反序列化入口的类型与资源边界，字段是否为空、状态是否合法、对象属于哪个租户仍由业务层判断。

模式过滤器里的未知类型默认会被拒绝吗？

不要靠默认行为猜结果。把允许的包和类写清楚，并为未知类型建立测试，发布前直接观察过滤器返回结果。

maxdepth 和 maxrefs 应该设置多大？

先从合法样本采集峰值，再留出有限余量，并用超限样本验收。过大的上限会削弱保护，过小则会误伤正常对象。

小结

Java 反序列化过滤的核心是把输入当成不可信边界：类型用允许范围收紧，资源用深度、引用数、字节数和数组长度限制，拒绝结果再由调用层明确分类。规则写完后，别只测一个成功样本；允许、未知和超限三组结果都能稳定复现，过滤器才算真正接入了系统。