Audit - Rules - Clone Usage

Description
This group contains audit rules that check for problems with the use of the cloning mechanism (the interface Cloneable and the clone method).

Rules:

Details

Clone Without Cloneable

Summary
Invoking Object's clone() method on an instance that does not implement the Cloneable interface results in the exception CloneNotSupportedException being thrown.

Description
The programmer probably intended the class to be cloneable when implementing the clone() method. Invoking Object's clone() method on an instance that does not implement the Cloneable interface results in the exception CloneNotSupportedException being thrown.

Security Implications
This means the code will not work as intended, resulting in errors and possibly unpredictable behavior thus compromising security.

Example
The following code would be flagged as a violation because it does not implement Cloneable while implementing clone method:

    public class SomeBean {
        public Object clone() throws CloneNotSupportedException {
            ...
        }
    }

Cloneable Without Clone

Summary
Classes that implement the Cloneable interface should define a clone() method.

Description
This audit rule looks classes that implement the Cloneable interface and do not define clone() method.

Security Implications
It is most essential for library vendors or for mobile code. The clone method is mechanism that allows the creation of objects, and it might be undesirable for users to be able to inherit this class and tamper with the behavior of this method.

Example
The following class would be flagged as a violation because it does not define a clone() method

    class MyClass implements Cloneable
    {
            ...
    }

    

Enforce Cloneable Usage

Summary
When an Object is cloned, Object data is copied and returned, because of this secure classes must be conscious of Cloneable.

Description
This audit rule aims to prevent adversaries from accessing data by extending classes and creating clone methods. Specifically, this rule flags non-anonymous classes that:
(1) do not implement Cloneable (so that the rule doesn't flag appropriate uses of Cloneable utilities),
(2) are non-final (final classes can't be extended),
(3) do not inherit a clone method (since inserting a clone method would be unnecessarily repetitive),
(4) and do not override clone():

public Object clone() throws CloneNotSupportedException;

and may enforce the following as the body of the clone method:

{
    throws java.lang.CloneNotSupportedException("Type not cloneable");
}

without, or with, a String input description.

Note: Even though classes that do not implement the Cloneable interface throw CloneNotSupportedException, adversaries are not prevented from extending a class, implementing the Cloneable interface, and then calling clone() to retrieve a copy of an instance of the class.

For more audit rule options concerning clone(), see Clone Method Usage and Override Clone Judiciously under Semantic Errors.

Security Implications
Classes that do not override clone() risk allowing a malicious user to subclass and override the clone method allowing them to gain access to data not intended by the application.

Example
The classes A, B and C below will not be flagged, but D will be.

    class A {
        public Object clone() {
            throw new java.lang.CloneNotSupportedException();
        }
    }

    class B extends A {}

    final class C{}

    class D {}