Page History

...

Classes that are not sensitive, but that maintain other invariants must be sensitive to the possibility of malicious subclasses accessing or manipulating their data, and possibly invalidating their invariants. See OBJ10-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely for more information.

Noncompliant Code Example

This noncompliant code example defines class SensitiveClass which contains a character array used to internally hold a file name, along with a Boolean shared variable, initialized to false. This data is not meant to be copied; consequently, SensitiveClass lacks a copy constructor.

...

The malicious class creates its own instance (ms1) and produces a second one (ms2), by cloning the first. It then obtains a new String filename object by invoking the get() method on the first instance. At this point, the shared flag is set to true. Because the second instance (ms2) does not have its shared flag set to true, it is possible to alter the first instance ms1 using the replace() method. This obviates any security efforts and severely violates the class's invariants.

Compliant Solution (final class)

The easiest way to prevent malicious subclasses is to declare SensitiveClass as final.

final class SensitiveClass {
  // ...
}

Compliant Solution (final clone())

Sensitive classes should not implement the Cloneable interface, nor provide a copy constructor. Sensitive classes that extend from a superclass that implements Cloneable (and is consequently cloneable) must provide a clone() method that throws a CloneNotSupportedException. This exception must be caught and handled by the client code. A sensitive class that does not implement Cloneable must also follow this advice because it inherits the clone() method from Object. The class can prevent subclasses from being cloneable by defining a final clone() method that fails.

...

This class fails to prevent malicious subclasses, but does protect the data in SensitiveClass. Its methods are protected by being declared final. For more information on how to handle malicious subclasses, see OBJ10-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely.

Risk Assessment

Failure to make sensitive classes non-copyable can permit violations of class invariants and provide malicious subclasses with the opportunity to exploit the code to create new instances of objects, even in the presence of the default security manager (in the absence of custom security checks).

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[Mcgraw 1998|AA. Bibliography#Mcgraw 98]\] 
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 498|http://cwe.mitre.org/data/definitions/498.html] "Information Leak through Class Cloning", [CWE ID 491|http://cwe.mitre.org/data/definitions/491.html] "Public cloneable() Method Without Final (aka 'Object Hijack')"
\[[Wheeler 2003|AA. Bibliography#Wheeler 03]\] 10.6. Java 

...