Page History

...

A TOCTOU inconsistency exists in this noncompliant code example. As cookie is a mutable input, an attacker may cause the cookie to expire between the initial check and the actual use.

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

    // Check if 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 resulting in
    // an exception
    doLogic(cookie);
  }
}

Compliant Solution

The problem is alleviated by creating a copy of the mutable input and using it to perform operations so that the original object is left unscathed. This can be realized by implementing the java.lang.Cloneable interface and declaring a public clone method when if the class is final or by using a copy constructor. Performing a manual copy of object state within the caller becomes necessary if the mutable class is declared final (that is, it cannot provide an accessible copy method). See the guideline OBJ10-J. Provide mutable classes with a clone method to allow passing instances to untrusted code safely for more information. Note that any input validation must be performed on the copy and not the original object.

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

    // Create copy
    cookie = (HttpCookie)cookie.clone();

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

    doLogic(cookie);
  }
}

Compliant Solution

...

Noncompliant Code Example

When the class of the mutable input type is non-final, a malicious subclass may maliciously override the its clone() method. This is a serious issue unless the non-final input defends against it. This noncompliant code example demonstrates this weakness.

...

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. It should be noted that if the underlying implementation on which the CharacterSequence is based changes, the value of the CharacterSequence also changes. Such objects must be defensively copied before use. It is also permissible to use the toString() method to make them immutable before passing them as parameters. Mutable fields must always never should not be stored in static variables. To When this is not possible, to avoid exposing mutable fields by storing them in static variables, creating defensive copies of the fields is highly recommended.

...