You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

Never use the clone method for defensive copying of untrusted method parameters. 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

This noncompliant code example defines a validateValue() method that validates a time value.

private Boolean validateValue(long time) {
  // Perform validation
  return true; // If the time is valid	
}

private void storeDateinDB(java.util.Date date) throws SQLException {
  final java.util.Date copy = (java.util.Date)date.clone();
  if (validateValue(copy.getTime())) {
    Connection con = DriverManager.getConnection("jdbc:microsoft:sqlserver://<HOST>:1433","<UID>","<PWD>");
    PreparedStatement pstmt = con.prepareStatement("UPDATE ACCESSDB SET TIME = ?");
    pstmt.setLong(1, copy.getTime());
    // ...
  } 
}	

The storeDateinDB() method accepts an untrusted date argument and 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.

public class MaliciousDate extends java.util.Date {
  private static int count = 0;

  @Override
  public long getTime() {
    java.util.Date d = new java.util.Date();
    return (count++ == 1) ? d.getTime() : d.getTime() - 1000;
  }
  
}

Compliant Solution

This compliant solution avoids using the clone method. Instead, it creates a new java.util.Date object that is subsequently used for access control checks and for insertion into the database.

private void storeDateinDB(java.util.Date date) throws SQLException {
  final java.util.Date copy = new java.util.Date(date.getTime());
  if (validateValue(copy.getTime())) {
    Connection con = DriverManager.getConnection("jdbc:microsoft:sqlserver://<HOST>:1433","<UID>","<PWD>");
    PreparedStatement pstmt = con.prepareStatement("UPDATE ACCESSDB SET TIME = ?");
    pstmt.setLong(1, copy.getTime());
    // ...
  }
}	

Risk Assessment

Using the clone() method to copy untrusted arguments 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

Related Vulnerabilities

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

Bibliography

[[Sterbenz 2006]]


MET07-J. Do not invoke overridable methods on the clone under construction      05. Methods (MET)      MET09-J. Always provide feedback about the resulting value of a method

  • No labels