Page History

Security checks based on untrusted sources can be bypassed. The untrusted object or parameter should be defensively copied before the security check is performed. The copy operation must be a deep copy; the implementation of the clone() method may produce a shallow copy, which can still be compromised. In addition, the implementation of the clone() method can be provided by the attacker. See rule OBJ06-J. Defensively copy mutable inputs and mutable internal components for more information.

...

This noncompliant code example describes a security vulnerability from the JDK Java 1.5 .0 java.io package. In this release, java.io.File was non-finalnonfinal, allowing an attacker to supply an untrusted parameter argument constructed by extending the legitimate File class. In this manner, the getPath() method can be overridden so that the security check passes the first time it is called but the value changes the second time to refer to a sensitive file such as /etc/passwd. This is a form of time-of-check-, time-of-use (TOCTOU) vulnerability.

...

This vulnerability can be mitigated by making declaring java.io.File final.

Compliant Solution (Copy)

This compliant solution ensures that the java.io.File object can be trusted despite not being final. The solution creates a new File object using the standard constructor. This ensures that any methods invoked on the File object are the standard library methods rather than overriding methods potentially that may be provided by the attacker.

...

Bibliography

...