Java Security   «Prev  Next»

Mutable Objects

Improve Security by reducing use of and limit access to Mutable objects.

Let us talk about the reduced use of and limit access to mutable objects. Security Coding Guideline 6 from Oracle
The use of mutable objects may seem harmless but these guidelines explore why this is not the case. This is a large topic as one can conclude from the guidelines. It is a good read so going through it is not a waste of time. Familiarize yourself with the guideline headings for the exam.

java.util.Date mutable API Class

One interesting API note:
The java.util.Date is an example of a mutable API class. In an application, it would be preferrable to use the new Java Date and Time API (java.time.*) which has been designed to be immutable, and this will help you write secure applications.

Guideline 1:

Prefer immutability for value types. Important Points: 1. Make classes immutable as much as possible.
  1. Hide constructors by using private or default access (package-private)
  2. Immutable classes should declare fields final.
  3. Construction of immutable objects can be made easier by providing builders.

Guideline 2:

Create copies of mutable output values.
Important Points: 1. Client code may modify the internal state of an internal mutable object if it is returned from a method. If your intention is not to share the state, return a copy. a. To create a copy they trusted mutable object, call a copy constructor or a supplied creation method before returning the object.

Guideline 3:

Create safe copies of mutable and sub-classable input values.
Important Points: Mutable objects may be changed after or even during the execution of a method or constructor call.
  1. Subclassed types could behave incorrectly, inconsistently, and/or maliciously
  2. If a method is not meant to alter mutable input parameter, create a copy of the input before performing method logic on the copy.
  3. If the input is stored in a field, a caller can exploit “race conditions” in the enclosing class.

Guideline 4:

Create safe copies of mutable and sub-classable input values.
Important Points:
  1. To create a copy of an untrusted mutable object, call a copy constructor or creation method. Do not rely on a clone or copy on the object.
  2. This guideline does not apply to classes that are designed to wrap a target object. For instance, java.util.Arrays.asList operates directly on the supplied array without copying.
  3. In some cases a deep copy may be needed; Constructors should complete the deep copy before assigning values to a field. An object should never be in a state where it references untrusted data, even briefly.

Guideline 5:

Support copy functionality for a mutable class
Important Points: When designing immutable value class, provide a means to create safe copies of its instances by:
  1. 1) Provide an accessible copy method with one of the following:
    1. a static creation method 2. a copy constructor 3. Implementing public copy method (for final classes).
  2. 2) If a class is final it does not provide an accessible method as described above, callers could resort to performing a manual copy. Performing such a manual copy can be fragile.
  3. 3) The java.lang.Cloneable mechanism is problematic and should not be used. a) In non-final classes Object.clone will make a new instance of a potentially malicious subclass.

Guideline 6:

Do not trust identity equality when overridable on input reference objects. Overridable methods may not behave as expected. Object.equals may be overridden to return true for different objects, this is especially egregious for collection elements so the use of IdentityHashMap is recommended.

Guideline 7:

Treat passing input to untrusted object as output. Important Point: Appropriate copying should be applied if you are passing a mutable object as an argument to an untrusted object’s method.

Guideline 8:

Treat output from untrusted object as input Point: Appropriate copying should be applied if you get an object returned from an untrusted objects method.

Guideline 9:

Define wrapper methods around modifiable internal state. Important Point: Modifiable internal state needs to be protected, and wrapper methods can be used to perform input validation prior to setting state to a new value.
  1. If it must be publicly accessible and modifiable : then declare a private field and enable access to it by means of public wrapper methods.
  2. If it is only intended to be accessed by subclasses, then - declare a private field and enable access by means of protected wrapper methods.
  3. Make additional defensive copies and getState and setState if the internal state is mutable.

Guideline 10:

Make public static fields final.
Important Points: Public static fields that are not final are problematic. Access and modifications cannot be guarded against and newly set values cannot be validated.
  1. Always declare public static fields as final.
  2. If using an interface, the modifiers "public static final” can be omitted since they are implicitly public, static, and final on an interface.
  3. Constants can alternatively be defined using an enum declaration.
  4. Protected static fields suffer from the same problem.

Guideline 11:

Ensure public static final field values are constants.
Important Points: Only immutable or unmodifiable values should be stored in public static fields.
  1. Enum values should never be mutable.
  2. Arrays and collections are mutable and easy to overlook in this instance.
    1. The copyOf methods, which were added in Java 10, can be used to create unmodifiable copies of existing collections.
    2. The of() and ofEntries() methods, added in Java 9, can also be used to create unmodifiable collections.
    3. You use the Stream methods toUnmodifiableList(), toUnmodifiableSet(), and toUnmodifiableMap() which return an immutable collection.
    4. Do not use the Collections methods
      unmodifiableCollection(), unmodifiableList(), and unmodifiableMap() because these return an unmodifiable VIEW, which does not ensure that the underlying source will not mutate.

Guideline 12:

Do not expose mutable statics.
Important Points: Private statics are easily exposed through public interfaces.
  1. Treat them as if they were public
  2. Mutable objects should never be cached in statics.

Guideline 13:

Do not expose modifiable collections. Classes that expose collections either through public variables or get methods have the same potential for side effects, where calling classes can modify contents of the collection.
  1. Expose read only copies of collections relating to security authentication or internal state.
  2. Use immutable collections.