...
In this compliant solution, the readObject() method throws an exception unless the potentially dangerous class was whitelisted in the manner used for the compliant solution of SER12-J. Prevent deserialization of untrusted classes. The reasoning is that a programmer who expressly whitelists a class for deserialization can reasonably be presumed to be aware of what the whitelisted class does during deserialization. For example, for a web app, whitelisting the above OpenedFile class might be considered an acceptable risk when deserializing data from an authenticated adminstrator but an unacceptable risk when deserializing data from an untrusted Internet user.
Note that the below following compliant solution for SER13-J is different from and complementary to the compliant solution in SER12-J. In the compliant solution for SER12-J, the source code location that invokes deserialization is modified to use a custom subclass of ObjectInputStream. This subclass overrides the resolveClass method () method to check whether class of the serialized object is whitelisted before that class's readObject method () method gets called. In contrast, in the compliant solution below for SER13-J, the whitelist is checked inside the readObject method () method of the dangerous serializable class. When both solutions are used together, a minor downside is that there is some redundancy, since the whitelist is checked twice (once before readObject(), and once during readObject()) even though a single check would have sufficed. However, the upside is that it now requires mistakes in two different places of the code to yield an exploitable vulnerability.
...