Page History

...

Additionally, returning references to an an object's internal mutable components affords provides an attacker with the opportunity to corrupt the state of the object. Accessor methods must consequently return defensive copies of internal mutable objects; see guideline OBJ09-J. Defensively copy private mutable class members before returning their references for additional information.

...

This noncompliant code example contains a TOCTOU inconsistency. Because cookie is a mutable input, an attacker can cause the cookie to expire between the initial check (the hasExpired() call) and the actual use (the doLogic() call).

public final class MutableDemo {
  // java.net.HttpCookie is mutable
  public void useMutableInput(HttpCookie cookie) {
    if (cookie == null) {
       throw new NullPointerException();
    }

    // Check whether cookie has expired
    if (cookie.hasExpired()) {
      // Cookie is no longer valid, handle condition by throwing an exception
    }

    // Cookie may have expired since time of check 
    doLogic(cookie);
  }
}

...

This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and performing all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect the copy. Acceptable techniques include using a copy constructor or implementing the java.lang.Cloneable interface and declaring a public clone method (for classes not declared as final). In cases like HttpCookie where the mutable class is declared final — that is, it cannot provide an accessible copy method — perform a manual copy of the object state within the caller. See guideline OBJ08-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely for more information. Note that any input validation must be performed on the copy and not on the original object.

...

When the class of a mutable input is non-final, or is an interface, an attacker can write a subclass that maliciously overrides the parent class's clone() method. The attacker's clone() method could then subvert defensive copying. This noncompliant code example demonstrates the weakness.

// java.util.ArrayListCollection is mutable and non-finalan interface
public void copyNonFinalInputcopyInterfaceInput(ArrayListCollection<String> listcollection) {
  doLogic(listcollection);
}

Compliant Solution

This compliant solution protects against potential malicious overriding by creating a new instance of the non-final mutable input, using the expected class rather than the class of the potentially malicious provided object. The newly created instance can be forwarded to any code capable of modifying it.

// java.util.ArrayList is mutable and non-final
public void copyNonFinalInput(ArrayList list) {
  // Create new instance of declared input type 
  list = new ArrayList(list);
  doLogic(list);
}

Noncompliant Code Example

This noncompliant code example uses the Collection interface as an input parameter and directly passes it to doLogic().

// java.util.Collection is an interface
public void copyInterfaceInput(Collection<String> collection) {
  doLogic(collection);
}

Compliant Solution

This compliant solution instantiates a new ArrayList and forwards it to the doLogic() method.

public void copyInterfaceInput(Collection<String> collection) {
  // Convert input to trusted implementation
  collection = new ArrayList(collection);
  doLogic(collection);
}

Some objects appear to be immutable because they have no mutator methods. For example, the java.lang.CharacterSequence interface describes an immutable sequence of characters. Note, however, that a variable of type CharacterSequence is a reference to an underlying object of some other class that implements the CharacterSequence interface; that other class may be mutable. When the underlying object changes, the CharacterSequence changes. Essentially, the java.lang.CharacterSequence interface omits methods that would permit object mutation through that interface, but lacks any guarantee of true immutability. Such objects must still be defensively copied before use. For the case of the java.lang.CharacterSequence interface, one permissible approach is to obtain an immutable copy of the characters by using the toString() method. Mutable fields should not be stored in static variables. When there is no other alternative, create defensive copies of the fields to avoid exposing them to untrusted code.

...