Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2021.1

Mutable classes are those which when instantiated, provide a reference such that the contents of the class can be altered at anytime. It is important to provide means for creating copies of mutable class instances as it allows safe passing in and returning of class objects when they are used within method argumentsallow code external to the class to alter their instance or class fields. Provide means for creating copies of mutable classes so that disposable instances of such classes can be passed to untrusted code. This functionality is useful when methods in other classes must create copies of the particular class instance (see OBJ06-J. Defensively copy mutable inputs and mutable internal components and OBJ05-J. Do not return references to private mutable class members for additional details).

Mutable classes must provide either a copy constructor or a public static factory method that returns a copy of an instance. Alternatively, final classes may advertise their copy functionality by overriding the clone() method of java.lang.Object. Use of the clone() method is secure only for final classes; nonfinal classes must not take this approach.

Trusted callers can be trusted to use the provided copy functionality to make defensive copies before passing object instances to untrusted code. Untrusted callers cannot be trusted to make such defensive copies. Consequently, providing copy functionality does not obviate the need for making defensive copies of inputs received from untrusted code or outputs returned to untrusted code.

Noncompliant Code Example

In this noncompliant code example, MutableClass uses a mutable Date object. If the caller changes the instance of the Date object (like incrementing the month), the class implementation no longer remains consistent with its old state. Both, the constructor as well as the getDate method are susceptible to abuse. This also defies attempts to implement thread safety. field date of type Date. Class Date is also a mutable class. The example is noncompliant because the MutableClass objects lack copy functionality.

Code Block
bgColor#FFcccc
public final class MutableClass {
  private Date date;

  public MutableClass(Date d) {
    this.date = d;
  }

  public void setDate(Date d) {
    this.date = d;
  }

  public Date getDate() {
    return date;
  }
}

When a trusted caller passes an instance of MutableClass to untrusted code, and the untrusted code modifies that instance (perhaps by incrementing the month or changing the timezone), the object's state can be made inconsistent with respect to its previous state. Similar problems can arise in the presence of multiple threads, even in the absence of untrusted code.

Compliant Solution (Copy Constructor)

This compliant solution uses a copy constructor that initializes a MutableClass instance when an argument of the same type (or subtype) is passed to it:

Code Block
bgColor#ccccff
Code Block
bgColor#FFcccc

public final class MutableClass { // Copy constructor
  private final Date ddate;
	
  public mutableClassMutableClass(DateMutableClass dmc)  {
    SecurityManagerthis.date sm= = System.getSecurityManagernew Date(mc.date.getTime());
  }

  ifpublic (sm != nullMutableClass(Date d) {
    this.date = new Date(d.getTime());  // Make defensive copy
  }

  public Date getDate() {
    return  //check permissions
    }(Date) date.clone(); // Copy and return
  }
}

This approach is useful when the instance fields are declared final. Callers request a copy by invoking the copy constructor with an existing MutableClass instance as its argument.

Compliant Solution (Public Static Factory Method)

This compliant solution exports a public static factory method getInstance() that creates and returns a copy of a given MutableClass object instance:

Code Block
bgColor#ccccff
class MutableClass {
  private final Date date;

  private MutableClass(Date d) { // Noninstantiable and nonsubclassable
    this.ddate = new Date(d.getTime());  // Make defensive copy
  }
	
  public Date getDate() {
    return this.d;	(Date) date.clone(); // Copy and return
  }

  public static MutableClass getInstance(MutableClass mc)  {
    return new MutableClass(mc.getDate());
  }
}

This approach is useful when the instance fields are declared final.

Compliant Solution

...

(clone())

This compliant solution provides the needed copy functionality by declaring MutableClass to be final, implementing the Cloneable interface, and providing an Object.clone() method that performs Always provide mechanisms to create copies of the instances of a mutable class. This compliant solution implements the Cloneable interface and overrides the clone method to create a deep copy of both the object and the mutable Date object. Since using clone() independently only produces a shallow copy and still leaves the class mutable, it is advised to also copy all the referenced mutable objects that are passed in or returned from any method. the object:

Code Block
bgColor#ccccff

public final class CloneClassMutableClass implements Cloneable {
  private Date ddate;
	
  public cloneClassMutableClass(Date d) {
    SecurityManagerthis.date sm= =new SystemDate(d.getSecurityManagergetTime());
  }

  public Date if (sm != nullgetDate() {
	//check permissions
    return (Date) date.clone();
  }

  public void setDate(Date d) {
    this.ddate = new(Date) Date(d.getTimeclone());  //copy-in 
  }

  public Object clone() throws CloneNotSupportedException {
    SecurityManagerfinal MutableClass smcloned = System.getSecurityManager(MutableClass) super.clone();
    cloned.date = if (sm != null) {(Date) date.clone();  // Manually copy mutable Date object
    return cloned;
 //check permissions
    }
    final cloneClass cloned = (cloneClass)super.clone();
    cloned.d }
}

Note that the clone() method must manually clone the Date object. This step is usually unnecessary when the object contains only primitive fields or fields that refer to immutable objects. However, when the fields contain data such as unique identifiers or object creation times, the clone() method must calculate and assign appropriate new values for such fields [Bloch 2008].

Mutable classes that define a clone() method must be declared final to ensure that untrusted code cannot declare a subclass that overrides the clone() method to create a spurious instance. The clone() method should copy all internal mutable state as necessary—in this compliant example, the Date object.

When untrusted code can call accessor methods passing mutable arguments, create defensive copies of the arguments before they are stored in any instance fields (see OBJ06-J. Defensively copy mutable inputs and mutable internal components for additional information). When retrieving internal mutable state, make a defensive copy of that state before returning it to untrusted code (see OBJ05-J. Do not return references to private mutable class members for additional information).

Defensive copies would be unnecessary if untrusted code always invoked an object's clone() method on mutable state received from mutable classes and operated only on the cloned copy. Unfortunately, untrusted code has little incentive to do so, and malicious code has every incentive to misbehave. This compliant solution provides a clone() method to trusted code and also guarantees that the state of the object cannot be compromised when the accessor methods are called directly from untrusted code.

Compliant Solution (clone() with Final Members)

When a mutable class's instance fields are declared final and lack accessible copy methods, provide a clone() method, as shown in this compliant solution:

Code Block
bgColor#ccccff
public final class MutableClass implements Cloneable {
  private final Date date; // final field

  public MutableClass(Date d) {
    this.date = new Date( d.getTime() );  //copy mutable Copy in
  }

  public Date objectgetDate() {
    return cloned;(Date) date.clone(); // Copy and return
  }
	
  public DateObject getDateclone() {
    Date returnd new= (Date(this.d.getTime()); //copy and return) date.clone();
    MutableClass cloned = new MutableClass(d);
    return cloned;
  }
}

At times, a class is labeled final with no accessible copy methods. Callers can then Callers can use the clone() method to obtain an instance of the class, such a mutable class. The clone() method must create a new instance with the original state and subsequently proceed to use it. Similarly, mutable objects obtained must also be copied when necessaryof the final member class and copy the original state to it. The new instance is necessary because there might not be an accessible copy method available in the member class. If the member class evolves in the future, it is critical to include the new state in the manual copy. Finally, the clone() method must create and return a new instance of the enclosing class (MutableClass) using the newly created member instance (d) [SCG 2009].

Mutable classes that define a clone() method must be declared final.

Compliant Solution (Unmodifiable Date Wrapper)

If cloning or copying a mutable object is infeasible or expensive, one alternative is to create an immutable view class. This class overrides mutable methods to throw an exception, protecting the mutable class.

Code Block
bgColor#ccccff
class UnmodifiableDateView extends Date {
  private Date date;

  public UnmodifiableDateView(Date date) {
    this.date = date;
  }

  public void setTime(long date) {
    throw new UnsupportedOperationException();
  }

  // Override all other mutator methods to throw UnsupportedOperationException
}

public final class MutableClass {
  private Date date;

  public MutableClass(Date d) {
    this.date = d;
  }

  public void setDate(Date d) {
    this.date = (Date) d.clone();
  }

  public UnmodifiableDateView getDate() {
    return new UnmodifiableDateView(date);
  }
}

Exceptions

OBJ04-J-EX0: Sensitive classes should not be cloneable, per OBJ07-J. Sensitive classes must not let themselves be copied.

Risk Assessment

Creating a mutable class without a clone method may providing copy functionality can result in the data of the class its instance becoming corrupted when the instance is passed to untrusted code.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC35

OBJ04-J

low

Low

unlikely

Likely

medium

Medium

P??

L??

P6

L2

Automated Detection

...

TODO

Related Vulnerabilities

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

References

Sound automated detection is infeasible in the general case. Heuristic approaches could be useful.

Tool
Version
Checker
Description
CodeSonar4.2

FB.MALICIOUS_CODE.EI_EXPOSE_REP

FB.MALICIOUS_CODE.EI_EXPOSE_REP2

May expose internal representation by returning reference to mutable object

May expose internal representation by incorporating reference to mutable object

Coverity7.5

FB.EI_EXPOSE_REP2
FB.EI_EXPOSE_REP

Implemented
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.OBJ04.CLONE
CERT.OBJ04.CPCL
CERT.OBJ04.MPT
CERT.OBJ04.SMO
CERT.OBJ04.MUCOP
Make your 'clone()' method "final" for security
Enforce returning a defensive copy in 'clone()' methods
Do not pass user-given mutable objects directly to certain types
Do not store user-given mutable objects directly into variables
Provide mutable classes with copy functionality

Related Guidelines

MITRE CWE

CWE-374, Passing Mutable Objects to an Untrusted Method
CWE-375, Returning a Mutable Object to an Untrusted Caller

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 6-4 / MUTABLE-4: Support copy functionality for a mutable class

Bibliography

[API 2014]

Method clone()

[Bloch 2008]

Item 39, "Make Defensive Copies When Needed"
Item 11, "Override Clone Judiciously"

[Security 2006]


...

Image Added Image Added Image Added Wiki Markup\[[Security 06|AA. Java References#Security 06]\] \[[API 06|AA. Java References#API 06]\] [clone()|http://java.sun.com/javase/6/docs/api/java/lang/Object.html#clone()]