Java ObjectInputFilter 拒绝后怎么定位：serialClass、depth 与 arrayLength 测试清单

老系统把订单快照存成 Java 序列化字节，升级接口后，最麻烦的不是“能不能读出来”，而是输入里混进了不属于这个模块的类，或者数组和对象引用规模远超正常订单。把数据读进 ObjectInputStream 之前加一层 ObjectInputFilter，可以先按类名和资源上限做一次拦截。

先理清楚：输入要过哪几道校验环节

把一次订单快照读取拆成三步更容易验证：先判断当前类是否属于允许集合，再判断数组和对象图是否超过正常业务规模，最后才让 ObjectInputStream 继续读取。过滤器检查的是反序列化过程中的对象信息，不会提前替你校验每个字段的业务合法性。

这里要特别注意边界：Oracle 官方文档明确说明，不可信数据的反序列化本身就存在风险。过滤器的价值是缩小可接受的类集合并限制对象图复杂度，不能把历史序列化格式变成一种天然安全的交换协议。

最小可用写法：只允许订单快照和基础类型

假设业务只保存 OrderSnapshot、OrderLine 和少量集合数据。先用模式过滤器限制包范围，再把输入流绑定到这个过滤器：

import java.io.ObjectInputFilter;
import java.io.ObjectInputStream;
import java.nio.file.Files;
import java.nio.file.Path;

Object readSnapshot(Path file) throws Exception {
    var pattern = "com.example.order.**;java.base/*;maxarray=200;maxdepth=12;!*";
    var filter = ObjectInputFilter.Config.createFilter(pattern);

    try (var input = Files.newInputStream(file);
         var objects = new ObjectInputStream(input)) {
        objects.setObjectInputFilter(filter);
        return objects.readObject();
    }
}

java.base/* 让基础模块中的必要类型参与匹配，最后的 !* 把没有被前面模式覆盖的类直接拒绝掉。数组上限和深度上限不是可选配置：订单行数量异常、嵌套集合过深时，过滤器应当在读取过程中直接返回拒绝状态。

自定义检查：把“允许什么”和“最多多少”分开处理

预设模式字符串适合配置固定规则；如果还要记录具体的拒绝原因，可以自行实现一个轻量过滤器。返回 UNDECIDED 表示当前过滤器暂不做判定，返回 ALLOWED 或 REJECTED 才是明确的校验结论：

ObjectInputFilter orderFilter = info -> {
    Class> type = info.serialClass();
    if (info.arrayLength() > 200 || info.depth() > 12) {
        return ObjectInputFilter.Status.REJECTED;
    }
    if (type == null) {
        return ObjectInputFilter.Status.UNDECIDED;
    }
    if (type.getName().startsWith("com.example.order.")) {
        return ObjectInputFilter.Status.ALLOWED;
    }
    if (type.getModule().getName().equals("java.base")) {
        return ObjectInputFilter.Status.ALLOWED;
    }
    return ObjectInputFilter.Status.REJECTED;
};

数组检查不能只在 serialClass() 非空时执行，因为数组长度是过滤器单独提供的独立校验指标。对象图深度也应结合真实订单样本测出合理上限，直接套一个过小的通用数字，很可能把合法的嵌套 DTO 一起拦截掉。

防御盲区：黑名单为什么越补越难维护

黑名单的思路是“遇到一个危险类就加一条拒绝规则”，但业务依赖、库版本和类加载范围一变，很容易出现遗漏。白名单的边界更清晰：订单读取器只需要少数 DTO 和基础类型，未声明的类不应该因为“暂时没发现问题”就自动放行。

如果多个模块各自设置流级过滤器，还要核查 JVM 级过滤器和过滤器工厂的合并关系。Oracle 的过滤文档强调，组合过滤器遇到任一明确拒绝时应直接返回拒绝结果；不能在局部过滤器里简单返回新规则，反而绕开全局安全边界。

用四组样本做验证，不要测一次正常就上线

每组样本都要记录过滤器配置、运行的 Java 版本、结果状态和具体失败原因。不要只断言“抛出了异常”，还要确认是输入类不允许、数组超限还是深度超限，否则后续规则调整后很难知道到底放宽了哪一道校验。

上线前的安全核对清单

• 能修改协议就停止新增 Java 原生序列化入口，迁移到字段和版本都更明确的数据格式。
• 必须兼容旧数据时，先盘点每个读取点的 DTO 白名单，再设置数组、深度、引用数和字节数上限。
• 把过滤器拒绝日志接入告警机制，但不要把完整输入内容和敏感订单字段直接写进日志。
• 升级 JDK、引入新 DTO 或新增集合字段后，重新跑一遍四组边界样本校验。

相关问题

ObjectInputFilter 能让不可信序列化数据变安全吗？

不能。它是类和资源边界的防御控制，不能替代避免读取不可信数据、认证来源和迁移到更明确数据格式等措施。

ALLOWED 和 UNDECIDED 有什么区别？

ALLOWED 是当前过滤器明确放行，UNDECIDED 是当前过滤器不表态，组合过滤器或后续规则仍可能给出拒绝结果。

只设置 maxdepth 够不够？

通常不够。对象图深度、引用数、数组长度和输入字节数限制关注的是不同资源维度，应根据正常业务样本组合设置并用边界数据验证。

过滤器应该设置在全局还是单个流上？

全局规则适合统一安全底线，单个流适合配置更严格的业务白名单。多层规则并存时要确认组合逻辑没有绕开全局过滤器。

把过滤器当成协议边界来维护

ObjectInputFilter 最有用的地方，不是帮旧序列化代码“加一行安全配置”，而是把可读类集合、对象图规模和验收样本都明确固化下来。先收紧输入边界，再逐步迁移掉不必要的原生序列化，才是更稳妥的长期方案。可继续参考 OpenJDK JEP 290、Oracle ObjectInputFilter API 和 Oracle Serialization Filtering 指南。