可以显式删除对lambda的序列化支持

Question

众所周知，当目标接口尚未继承可序列化的时，很容易向lambda表达式添加序列化支持，就像

我要求的是一种相反的方法，即在目标接口继承Serializable时显式删除序列化支持。

由于无法从类型中删除接口，基于语言的解决方案可能看起来像是（@NotSerializable TargetInterface）（）-

即使在类实现可序列化时拒绝序列化在过去是一种合法的行为，并且类在程序员的控制下，模式如下：

public class NotSupportingSerialization extends SerializableBaseClass {
    private void writeObject(java.io.ObjectOutputStream out) throws IOException {
      throw new NotSerializableException();
    }
    private void readObject(java.io.ObjectInputStream in)
      throws IOException, ClassNotFoundException {
      throw new NotSerializableException();
    }
    private void readObjectNoData() throws ObjectStreamException {
      throw new NotSerializableException();
    }
}

但是对于lambda表达式，程序员无法控制lambda类。

为什么会有人费心删除支持？好吧，除了为包含序列化支持而生成的更大代码之外，它还会产生安全风险。考虑以下代码：

public class CreationSite {
    public static void main(String... arg) {
        TargetInterface f=CreationSite::privateMethod;
    }
    private static void privateMethod() {
        System.out.println("should be private");
    }
}

在这里，只要程序员小心，即使TargetInterface是public（接口方法始终是public），对私有方法的访问也不会公开，不会将实例f传递给不受信任的代码。

但是，如果TargetInterface继承Serializable，情况就会发生变化。然后，即使CreationSite从未分发实例，攻击者也可以通过反序列化手动构建的流来创建等效实例。如果上面示例的接口看起来像

public interface TargetInterface extends Runnable, Serializable {}

这非常简单：

SerializedLambda l=new SerializedLambda(CreationSite.class,
    TargetInterface.class.getName().replace('.', '/'), "run", "()V",
    MethodHandleInfo.REF_invokeStatic,
    CreationSite.class.getName().replace('.', '/'), "privateMethod",
    "()V", "()V", new Object[0]);
ByteArrayOutputStream os=new ByteArrayOutputStream();
try(ObjectOutputStream oos=new ObjectOutputStream(os)) { oos.writeObject(l);}
TargetInterface f;
try(ByteArrayInputStream is=new ByteArrayInputStream(os.toByteArray());
    ObjectInputStream ois=new ObjectInputStream(is)) {
    f=(TargetInterface) ois.readObject();
}
f.run();// invokes privateMethod

请注意，攻击代码不包含安全管理器将撤销的任何操作。

支持序列化的决定是在编译时做出的。它需要在CreationSite中添加一个合成工厂方法，并向metafactory方法传递一个标志。如果没有该标志，生成的lambda将不支持序列化，即使接口恰好继承了可序列化的。lambda类甚至会有一个writeObject方法，如上面的示例NotSupportingSerialization中所示。如果没有合成工厂方法，反序列化是不可能的。

我发现这导致了一个解决方案。您可以创建接口的副本并将其修改为不继承Serializable，然后针对该修改后的版本进行编译。因此，当运行时的真实版本恰好继承了Serializable时，序列化仍然会被撤销。

另一个解决方案是，至少在目标接口继承了可序列化的代码的情况下，永远不要在安全相关代码中使用lambda表达式/方法引用，在根据接口的较新版本进行编译时，必须始终对其进行重新检查。

但我认为必须有更好的，最好是语言内的解决方案。

Answer 1

如何处理可串行性是EG面临的最大挑战之一；可以说没有很好的解决方案，只有各种缺点之间的权衡。一些政党坚持所有lambdas都是自动可序列化的 (!); 另一些人坚持lambdas永远不可序列化（这有时看起来是一个有吸引力的想法，但可悲的是会严重违反用户的期望。）

您注意到：

另一个解决方案是在安全相关代码中永远不要使用lambda表达式/方法引用，

事实上，序列化规范现在正是这么说的。

但是，这里有一个相当简单的诀窍来实现您想要的。假设您有一些需要可序列化实例的库：

public interface SomeLibType extends Runnable, Serializable { }

使用期望此类型的方法：

public void gimmeLambda(SomeLibType r)

您想将lambda传递给它，但不想让它们可序列化（并承担后果。）因此，为自己编写这个助手方法：

public static SomeLibType launder(Runnable r) {
    return new SomeLibType() {
        public void run() { r.run(); }
    }
}

现在可以调用库方法：

gimmeLambda(launder(() -> myPrivateMethod()));

编译器会将您的lambda转换为不可序列化的Runnable，而洗钱包装器会将其包装为满足类型系统的实例。当您尝试序列化它时，这将失败，因为r不可序列化。更重要的是，您无法伪造对私有方法的访问权限，因为捕获类中所需的$desializeLambda$支持甚至不存在。