Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: resurrected Dhruv's attack code + another attack example

...

Code Block
bgColor#FFcccc
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 its clone() method. This allows an attacker to take control of the program by creating a malicious date class that extends Date and whose clone() method perpetrates the attack by failing to provide proper copy functionality. The attacker creates an object of this type and passes it to storeDateInDB() so that the validation succeeds the first time and subsequently mutates the date to a value of his choice. . If the attacker's code runs with the same privileges as storeDateInDB(), the attacker merely embeds malicious code inside their clone() method:

Code Block
langjava
class MaliciousDate extends java.util.Date {
  @Override
  public MaliciousDate clone() {
    // malicious code goes here
  }
}

If, however, the attacker can only provide a malicious date with lessened privileges, the attacker can still produce a malicious date that bypasses validation, but still confounds the remainder of the program. Consider this example:

Code Block
langjava
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;
  }
}

This malicious date will appear to be a benign date class the first time that getTime() is invoked. This allows it to bypass validation in the storeDateInDB() method. However, the time that is actaully stored in the database will be incorrect.

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:

...