A mutable input has the characteristic that its value may change between different accesses. Sometimes a method does not operate directly on the input parameter. This opens a window of opportunities for exploiting race conditions. A "time-of-check, time-of-use" (TOCTOU) inconsistency results when a field contains a value that passes the initial security manager checks but mutates to a different value during actual usage.
Non-Compliant Code Example
A TOCTOU inconsistency exists in this code sample. Since cookie is a mutable input, a malicious 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
}
doLogic(cookie); //cookie may have expired since time of check resulting in an exception
}
}
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 or by using a copy constructor. Performing a manual copy of object state within the caller becomes necessary if the mutable class is declared as final (that is, it cannot provide an accessible copy method)xyz. Note that the input validation must follow after the creation of the copy.
public final class MutableDemo {
// java.net.HttpCookie is mutable
public void copyMutableInput(HttpCookie cookie) {
if (cookie == null) {
throw new NullPointerException();
}
// create copy
cookie = cookie.clone();
//check if cookie has expired
if(cookie.hasExpired())
{
//cookie is no longer valid, handle condition
}
doLogic(cookie);
}
}
References
Secure Coding in Java http://java.sun.com/security/seccodeguide.html