Effective Java 第三版——88. 防御性地编写READOBJECT方法

Tips

书中的源代码地址：https://github.com/jbloch/effective-java-3e-source-code

注意，书中的有些代码里方法是基于Java 9 API中的，所以JDK 最好下载 JDK 9以上的版本。

88. 防御性地编写READOBJECT方法

条目 50 里有一个不可变的日期范围类，它包含一个可变的私有Date属性。 该类通过在其构造方法和访问器中防御性地拷贝Date对象，竭尽全力维持其不变性（invariants and immutability）。 代码如下所示：

// Immutable class that uses defensive copying
public final class Period { private final Date start;
private final Date end; /**
* @param start the beginning of the period
* @param end the end of the period; must not precede start
* @throws IllegalArgumentException if start is after end
* @throws NullPointerException if start or end is null
*/
public Period(Date start, Date end) {
this.start = new Date(start.getTime());
this.end = new Date(end.getTime());
if (this.start.compareTo(this.end) > 0)
throw new IllegalArgumentException(
start + " after " + end);
} public Date start () { return new Date(start.getTime()); } public Date end () { return new Date(end.getTime()); } public String toString() { return start + " - " + end; } ... // Remainder omitted
}


假设要把这个类可序列化。由于Period对象的物理表示精确地反映了它的逻辑数据内容，所以使用默认的序列化形式是合理的(条目 87)。因此，要使类可序列化，似乎只需将implements Serializable 添加到类声明中就可以了。但是，如果这样做，该类不再保证它的关键不变性了。

问题是readObject方法实际上是另一个公共构造方法，它需要与任何其他构造方法一样的小心警惕。 正如构造方法必须检查其参数的有效性（条目 49）并在适当的地方对参数防御性拷贝（条目 50），readObject方法也要这样做。 如果readObject方法无法执行这两个操作中的任何一个，则攻击者违反类的不变性是相对简单的事情。

简而言之，readObject是一个构造方法，它将字节流作为唯一参数。 在正常使用中，字节流是通过序列化正常构造的实例生成的。当readObject展现一个字节流时，问题就出现了，这个字节流是人为构造的，用来生成一个违反类不变性的对象。 这样的字节流可用于创建一个不可能的对象，该对象无法使用普通构造方法创建。

假设我们只是将implements Serializablet添加到Period类声明中。 然后，这个丑陋的程序生成一个Period实例，其结束时间在其开始时间之前。 对byte类型的值进行强制转换，其高阶位被设置，这是由于Java缺乏byte字面量，并且错误地决定对byte类型进行签名:

public class BogusPeriod {
// Byte stream couldn't have come from a real Period instance!
private static final byte[] serializedForm = {
(byte)0xac, (byte)0xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x06,
0x50, 0x65, 0x72, 0x69, 0x6f, 0x64, 0x40, 0x7e, (byte)0xf8,
0x2b, 0x4f, 0x46, (byte)0xc0, (byte)0xf4, 0x02, 0x00, 0x02,
0x4c, 0x00, 0x03, 0x65, 0x6e, 0x64, 0x74, 0x00, 0x10, 0x4c,
0x6a, 0x61, 0x76, 0x61, 0x2f, 0x75, 0x74, 0x69, 0x6c, 0x2f,
0x44, 0x61, 0x74, 0x65, 0x3b, 0x4c, 0x00, 0x05, 0x73, 0x74,
0x61, 0x72, 0x74, 0x71, 0x00, 0x7e, 0x00, 0x01, 0x78, 0x70,
0x73, 0x72, 0x00, 0x0e, 0x6a, 0x61, 0x76, 0x61, 0x2e, 0x75,
0x74, 0x69, 0x6c, 0x2e, 0x44, 0x61, 0x74, 0x65, 0x68, 0x6a,
(byte)0x81, 0x01, 0x4b, 0x59, 0x74, 0x19, 0x03, 0x00, 0x00,
0x78, 0x70, 0x77, 0x08, 0x00, 0x00, 0x00, 0x66, (byte)0xdf,
0x6e, 0x1e, 0x00, 0x78, 0x73, 0x71, 0x00, 0x7e, 0x00, 0x03,
0x77, 0x08, 0x00, 0x00, 0x00, (byte)0xd5, 0x17, 0x69, 0x22,
0x00, 0x78
}; public static void main(String[] args) {
Period p = (Period) deserialize(serializedForm);
System.out.println(p);
} // Returns the object with the specified serialized form
static Object deserialize(byte[] sf) {
try {
return new ObjectInputStream(
new ByteArrayInputStream(sf)).readObject();
} catch (IOException | ClassNotFoundException e) {
throw new IllegalArgumentException(e);
}
}
}


用于初始化serializedForm的字节数组字面量（literal）是通过序列化正常的Period实例，并手动编辑生成的字节流生成的。 流的细节对于该示例并不重要，但是如果好奇，则在《Java Object Serialization Specification》[序列化，6]中描述了序列化字节流格式。 如果运行此程序，它会打印Fri Jan 01 12:00:00 PST 1999 - Sun Jan 01 12:00:00 PST 1984。只需声明Period类为可序列化，我们就可以创建一个违反其类不变性的对象。

要解决此问题，请为Period提供一个readObject方法，该方法调用defaultReadObject，然后检查反序列化对象的有效性。如果有效性检查失败，readObject方法抛出InvalidObjectException异常，阻止反序列化完成:

// readObject method with validity checking - insufficient!
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException {
s.defaultReadObject(); // Check that our invariants are satisfied
if (start.compareTo(end) > 0)
throw new InvalidObjectException(start +" after "+ end);
}


虽然这样可以防止攻击者创建无效的Period实例，但仍然存在潜在的更微妙的问题。 可以通过构造以有效Period实例开头的字节流来创建可变Period实例，然后将额外引用附加到Period实例内部的私有Date属性。 攻击者从ObjectInputStream中读取Period实例，然后读取附加到流的“恶意对象引用”。 这些引用使攻击者可以访问Period对象中私有Date属性引用的对象。 通过改变这些Date实例，攻击者可以改变Period实例。 以下类演示了这种攻击：

public class MutablePeriod {
// A period instance
public final Period period; // period's start field, to which we shouldn't have access
public final Date start; // period's end field, to which we shouldn't have access
public final Date end; public MutablePeriod() {
try {
ByteArrayOutputStream bos =
new ByteArrayOutputStream();
ObjectOutputStream out =
new ObjectOutputStream(bos);
// Serialize a valid Period instance
out.writeObject(new Period(new Date(), new Date())); /*
* Append rogue "previous object refs" for internal
* Date fields in Period. For details, see "Java
* Object Serialization Specification," Section 6.4.
*/
byte[] ref = { 0x71, 0, 0x7e, 0, 5 }; // Ref #5
bos.write(ref); // The start field
ref[4] = 4; // Ref # 4
bos.write(ref); // The end field // Deserialize Period and "stolen" Date references
ObjectInputStream in = new ObjectInputStream(
new ByteArrayInputStream(bos.toByteArray()));
period = (Period) in.readObject();
start = (Date) in.readObject();
end = (Date) in.readObject();
} catch (IOException | ClassNotFoundException e) {
throw new AssertionError(e);
}
}
}


要查看正在进行的攻击，请运行以下程序：

public static void main(String[] args) {
MutablePeriod mp = new MutablePeriod();
Period p = mp.period;
Date pEnd = mp.end; // Let's turn back the clock
pEnd.setYear(78);
System.out.println(p); // Bring back the 60s!
pEnd.setYear(69);
System.out.println(p);
}


在我的语言环境中，运行此程序会产生以下输出：

Wed Nov 22 00:21:29 PST 2017 - Wed Nov 22 00:21:29 PST 1978
Wed Nov 22 00:21:29 PST 2017 - Sat Nov 22 00:21:29 PST 1969


虽然创建了Period实例且保持了其不变性，但可以随意修改其内部组件。 一旦拥有可变的Period实例，攻击者可能会通过将实例传递给依赖于Period的安全性不变性的类来造成巨大的伤害。 这并非如此牵强：有些类就是依赖于String的不变性来保证安全性的。

问题的根源是Period类的readObject方法没有做足够的防御性拷贝。 对象反序列化时，防御性地拷贝包含客户端不能拥有的对象引用的属性，是至关重要的。 因此，每个包含私有可变组件的可序列化不可变类，必须在其readObject方法中防御性地拷贝这些组件。 以下readObject方法足以确保Period的不变性并保持其不变性：

// readObject method with defensive copying and validity checking
private void readObject(ObjectInputStream s)
throws IOException, ClassNotFoundException {
s.defaultReadObject(); // Defensively copy our mutable components
start = new Date(start.getTime());
end = new Date(end.getTime()); // Check that our invariants are satisfied
if (start.compareTo(end) > 0)
throw new InvalidObjectException(start +" after "+ end);
}


请注意，防御性拷贝在有效性检查之前执行，并且我们没有使用Date的clone方法来执行防御性拷贝。 需要这两个细节来保护Period免受攻击（条目 50）。 另请注意，final属性无法进行防御性拷贝。 要使用readObject方法，我们必须使start和end属性不能是final类型的。 这是不幸的，但它是这两个中较好的一个做法。 使用新的readObject方法并从start和end属性中删除final修饰符后，MutablePeriod类不再无效。 上面的攻击程序现在生成如下输出：

Wed Nov 22 00:23:41 PST 2017 - Wed Nov 22 00:23:41 PST 2017
Wed Nov 22 00:23:41 PST 2017 - Wed Nov 22 00:23:41 PST 2017


下面是一个简单的石蕊测试(litmus test)，用于确定类的默认readObject方法是否可接受：你是否愿意添加一个公共构造方法，该构造方法把对象中每个非瞬时状态的属性值作为参数，并在没有任何验证的情况下，将值保存在属性中？如果没有，则必须提供readObject方法，并且它必须执行构造方法所需的所有有效性检查和防御性拷贝。或者，可以使用序列化代理模式（serialization proxy pattern））(条目 90)。强烈推荐使用这种模式，因为它在安全反序列化方面花费了大量精力。

readObject方法和构造方法还有一个相似之处，它们适用于非final可序列化类。 与构造方法一样，readObject方法不能直接或间接调用可重写的方法（条目 19）。 如果违反此规则并且重写了相关方法，则重写方法会在子类状态被反序列化之前运行。 程序可能会导致失败[Bloch05，Puzzle 91]。

总而言之，无论何时编写readObject方法，都要采用这样一种思维方式，即正在编写一个公共构造方法，该构造方法必须生成一个有效的实例，而不管给定的是什么字节流。不要假设字节流一定表示实际的序列化实例。虽然本条目中的示例涉及使用默认序列化形式的类，但是所引发的所有问题都同样适用于具有自定义序列化形式的类。下面是编写readObject方法的指导原则:

• 对于具有必须保持私有的对象引用属性的类，防御性地拷贝该属性中的每个对象。不可变类的可变组件属于这一类别。

• 检查任何不变性，如果检查失败，则抛出InvalidObjectException异常。 检查应再任何防御性拷贝之后。

• 如果必须在反序列化后验证整个对象图（object graph），那么使用ObjectInputValidation接口(在本书中没有讨论)。

• 不要直接或间接调用类中任何可重写的方法。