Security checks based on untrusted sources can be bypassed. Any untrusted object or argument must be defensively copied before a 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 OBJ06-J. Defensively copy mutable inputs and mutable internal components for more information).
Noncompliant Code Example
This noncompliant code example describes a security vulnerability from the Java 1.5
java.io package. In this release,
java.io.File is nonfinal, allowing an attacker to supply an untrusted 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 an example of a time-of-check, time-of-use (TOCTOU) vulnerability.
The attacker could extend
java.io.File as follows:
Compliant Solution (Final)
This vulnerability can be mitigated by declaring
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 technique ensures that any methods invoked on the
File object are the standard library methods and not overriding methods that have been provided by the attacker.
Note that using the
clone() method instead of the
openFile() method would copy the attacker's class, which is not desirable (see OBJ06-J. Defensively copy mutable inputs and mutable internal components).
Basing security checks on untrusted sources can result in the check being bypassed.
Authentication Logic Error [XZO]
Android Implementation Details
The code examples using the
java.security package are not applicable to Android, but the principle of the rule is applicable to Android apps.