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 performing a manual copy of object state within the caller, if the mutable class is declared as final (that is, it cannot provide an accessibly copy method). xyz
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