Explicit Serialization API and Security

[Peter Firmstone]

The following is a summary of our exploration so far:

We have narrowed down to two options:

A. constructors with static invariant check methods.

B. Continue to use readObject(), we have a proposed solution to the
   final field problem and could modify the jvm to register for
   finalization late to avoid finalizer attacks.  



Question: How can a programmer protect against reference stealing attacks?

Once this is taken into consideration, B's complexity exceeds A.



This is a good guideline for constructors, but deserialization offers more attack vectors: 

https://www.securecoding.cert.org/confluence/display/java/TSM01-J.+Do+not+let+the+this+reference+escape+during+object+construction


Item A.:

 * Prevents reference stealing attacks.
 * A subclass checking its invariants can only create a
   superclass instance for intra invariant checking, if 
   superclass invariants are satisfied.



Logic Steps for item A:

1. Framework calls child class serial constructor
2. Child class constructor calls static invariant check.
3. For each class in hierarchy:
   a. If current class has no intra class invariants:
      * Check invariants and return result to super class constructor
        or throw Exception.
   b. Else if the child class has intra class invariants:
      * Create a superclass instance (invariants are checked before it
        can be created).
      * Check invariants and return result to super class constructor
        or throw Exception.

7. Each Superclass checks its invariants, repeating step 3, until Object's constructor is called,
   or an Exception is thrown.
8. Constructors return, each class descending down the object hierarchy sets
   fields.  Process is complete and new object is published.


Remember that when satisfying invariants, class types can be checked before deserializing an object.  For flexibility this could be in the form of a permission check.


Regards,

Peter.