An attacker can bypass security checks if defensive copies Never use the clone method for defensive copying of untrusted method parameters are made and security decisions are based on these copies. An example of an untrusted method argument is an object instance whose class provides a clone() method and the class itself is non-finalparameters. Making defensive copies of mutable parameters mitigates against a variety of security vulnerabilities; see FIO00-J. Defensively copy mutable inputs and mutable internal components for additional information. However, inappropriate use of the clone method can allow an attacker to exploit vulnerabilities by providing arguments that pass initial validation but subsequently return unexpected values. Such objects may consequently bypass validation and security checks. Never use the clone method to make defensive copies of objects that are instances of classes that both are non-final and also provide a clone() method.
Noncompliant Code Example
...
The storeDateinDB() method accepts an untrusted date argument and creates attempts to make a defensive copy using the clone() method. The attacker can override the getTime() method so that it passes validation when called for the first time, but provides an unexpected value when it is used a second time.
...
Compliant Solution
This compliant solution avoids using the clone method. Instead, it creates a new java.util.Date object which that is subsequently used for access control checks and for insertion into the database.
...
Using the clone() method to copy untrusted arguments can invalidate affords to attackers the opportunity to bypass validation and security checks.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MET08-J | high | likely | low | P27 | L1 |
Automated Detection
...
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
...