第85项：其他序列化优先于Java序列化

  当序列化在1997年被添加到Java时，它被认为有点风险的。该方法已经在一种研究语言（Modula-3）中尝试过，但在生产中的语言从未用过。虽然程序猿承诺在分布式对象上付出点努力得到的成果是很有吸引力的，代价是构造函数是不可见的而且它的API和实现之间的界限很模糊，可能存在正确性、性能、安全性和维护方面的问题。支持者认为这些好处【前面的成果】超过了风险，但历史已经证明并不是这样的。

  本书前几版中描述的安全问题与某些人担心的一样严重。2000年代早期讨论的小漏洞在接下来的十年被转化为严重的漏洞并被利用了，其中包括对旧金山都市交通局市政铁路（SFMTA Muni）的勒索软件攻击，该铁路在2016年11月关闭整个收费系统两天[Gallagher16]。

  序列化的一个基本问题是它的*攻击面（attack surface）*太大而无法保护并且不断增长：通过在ObjectInputStream上调用readObject方法来反序列化对象数据图（object graphs）。这个方法本质上是一个神奇的构造函数，只要类型实现了Serializable接口，就可以在类路径上实例化几乎任何类型的对象。 在反序列化字节流的过程中，此方法可以从任何这些类型执行代码，因此所有这些类型的代码都是攻击面的一部分。

  攻击面包括Java平台库中的类，第三方库（如Apache Commons Collections）和应用程序本身。即使您遵守所有相关的最佳实践并成功编写无法攻击的可序列化类，您的应用程序仍可能容易受到攻击。引用CERT协调中心技术经理Robert Seacord的话：

Java反序列化是一个明显且存在的危险，因为它直接被应用程序广泛使用，并间接地由Java子系统（如RMI（远程方法调用），JMX（Java管理扩展）和JMS（Java消息系统））广泛使用。不受信任的流的反序列化可能导致远程代码执行（RCE），拒绝服务（DoS）以及一系列其他漏洞利用。 应用程序即使没有做错也容易受到这些攻击。[Seacord17]。

  攻击者和安全研究人员研究Java库和常用第三方库中的可序列化类型，查找在反序列化期间调用的执行方法潜在的危险活动。这种方法称为小工具（gadgets）。可以一起使用多个小工具来形成小工具链（gadget chain）。有时会发现在一个足够强大的小工具链中，只要有机会提交精心设计的字节流进行反序列化，就允许攻击者在底层硬件上执行任意本机代码（native code）。这正是SFMTA Muni攻击中发生的事情。这次袭击不是单独的。还有其他的，还会有更多。

  在不使用任何小工具的情况下，你可以轻松地通过反序列化一个需要很长的反序列化时间的短流来发起拒绝服务（denial-of-service）攻击，这种流被称为反序列化炸弹(deserialization bombs )[Svoboda16]。这是Wouter Coekaerts的一个例子，它只使用哈希集和字符串[Coekaerts15]：

// Deserialization bomb - deserializing thi