Explicit Serialization API and Security

David M. Lloyd david.lloyd at redhat.com
Mon Jan 5 14:23:29 UTC 2015

On 01/03/2015 02:29 PM, Peter Firmstone wrote:
> ----- Original message -----
>> Wouldn't it be better to "register" for finalization just those instances that complete their
>> construction or deserialization normally? I'm just trying to understand
>> why it is the way it is.
> Perhaps that might be an option, someone who knows more about finalization might be able to help here.
> In the early days, the sandbox and bytecode verifier were intended to make java secure, additional private methods were created as vulnerabilities were better understood.
> I think a problem with Serialization is you have to establish trust before you can use it.
> It would be nice if there was an input validator like html servers use, to validate the stream before instantiating objects.  Eg array size check before array creation, type check before object instantiation and restrict creation to permitted classes, to a subset of what's available on the class path.

You can do this already, albeit to a more limited extent, by customizing 
class resolution in ObjectInputStream.

Other approaches include using readResolve/writeReplace to create 
serialized representation objects, and the existing validation scheme 
where the validator is deferred until the deserialize operation is complete.


More information about the core-libs-dev mailing list