A more practical solution than “stop using serialisation” is to use a modern serialisation system that doesn’t have access to random parts of your language internals i.e. Thrift or Protocol Buffers
Or the old standby of JSON or even (ugh) XML. Actually, the only big issue here is that Java serialization will deserialize arbitrary objects—which means that every Serializable anywhere on your classpath is a potential target. If not for that, this vulnerability would not exist. And since, assuming it doesn’t own your system, the response to getting the wrong class of object from a deserializer is almost always to throw a ClassCastException or similar, it’s a pretty terrible oversight on the part of the language designers that users can’t specify what class or set of classes they expect to get out of the deserializer and not deserialize any other classes.
A more practical solution than “stop using serialisation” is to use a modern serialisation system that doesn’t have access to random parts of your language internals i.e. Thrift or Protocol Buffers
Or the old standby of JSON or even (ugh) XML. Actually, the only big issue here is that Java serialization will deserialize arbitrary objects—which means that every
Serializableanywhere on your classpath is a potential target. If not for that, this vulnerability would not exist. And since, assuming it doesn’t own your system, the response to getting the wrong class of object from a deserializer is almost always to throw aClassCastExceptionor similar, it’s a pretty terrible oversight on the part of the language designers that users can’t specify what class or set of classes they expect to get out of the deserializer and not deserialize any other classes.Maybe an alternative phrasing would be “only serialize to and from the language’s primitive types and structures”
Unfortunately, Java’s primitives structures are classes…