java - 如何发现 Java 反序列化问题？

Question

我希望能够发现 Java 代码中的反序列化问题。我应该寻找什么？例如，如何确定某些 Java 代码是否试图利用“java calendar bug”？请注意，我不是 Java 程序员，但我理解序列化和 OOP 背后的概念。我正在尝试实现一些安全检查(类似于编译器警告工具)。

编辑:根据评论，我想稍微更改一下问题:我认为所有分析的代码都是“不受信任的”，有没有办法对潜在危险进行评级？我的意思是，关于反序列化错误，我可以说代码 A 比 B 更危险吗？我应该寻找什么？

Answer 1

首先，您需要了解您的上下文以确定安全威胁。 (当我谈论“信任”时，我几乎没有走捷径。我是在故意恶意谈论。)

如果序列化数据是以相同的信任创建、保存和读取的，那么就没有任何真正的问题(标准错误除外)。请注意，如果您写入任何敏感信息，那么序列化数据也是敏感的(这看起来很明显，但其中有相当多的间接性)。

如果序列化数据出于某种原因不受信任，则需要考虑更多。重新创建的对象的内部结构可能是“不寻常的”。数据可能不一致。您可能共享了应该分开的可变对象。反序列化可能会导致无限循环，或者恰好在宇宙热寂之前无法完成的非无限循环。当然，数据可能是谎言。

如果您编写的库代码被不太受信任的代码使用，那么事情会变得更有趣:

在“日历错误”(和类似错误)的情况下，这是关于反序列化带有恶意数据和恶意代码的任意流。 Java 安全编码指南建议在自定义 readObject 方法中进行安全检查(使用“Java2 安全模型”)，这意味着您不应比代码和数据更信任地调用反序列化。

从反序列化对象的角度来看，事情更加棘手。 ObjectInputStream 通过 readObject、readUnshared、defaultReadObject、readFields 或只是默认反序列化可能具有被恶意代码捕获的引用，或者对于非最终类，被恶意子类化。当部分初始化时，也可以在反序列化期间使用对象。反序列化不会调用反序列化类的“真实”构造函数(readObject/readObjectNoData 是一种伪构造函数，无法设置 finals)。这有点像是一场噩梦，所以您可能不想让您的敏感类可序列化。

在序列化和反序列化的实现中存在许多漏洞。你真的不需要担心这个，除非你自己实现。