OBJ12-J. Compare classes and not class names

In a JVM, "Two classes are the same class (and consequently the same type) if they are loaded by the same class loader, and they have the same fully qualified name" [[JVMSpec 1999]]. A class with the same name but a different package name is different, and a class with the same fully qualified name but which has been loaded by a different class loader is also different.

It could be necessary to check whether a given object has a specific class type or whether two objects have the same class type associated with them, for example, when implementing the equals() method. If the comparison is performed incorrectly, the code could assume that the two objects are of the same class when they are not. As a result class names must not be compared.

Depending on the function that the insecure code performs, it could be vulnerable to a mix-and-match attack. An attacker could supply a malicious class with the same fully qualified name as the target class. If access to a protected resource is granted based on the comparison of class names alone, the unprivileged class could gain unwarranted access to the resource.

Conversely, the assumption that two classes deriving from the same code base are themselves the same is error-prone. While this assumption is commonly observed to be true in desktop applications, it is typically not the case with J2EE servlet containers. The containers can use different class loader instances to deploy and recall applications at runtime, without having to restart the JVM. In such situations, two objects whose classes come from the same code base could appear to the JVM to be two different classes. Also note that the equals() method might not return true when comparing objects originating from the same code base.

Noncompliant Code Example

This noncompliant code example compares the name of the class (Auth) of object auth to the string "com.application.auth.DefaultAuthenticationHandler" and branches on the result of the comparison.

 // Determine whether object auth has required/expected class name
if (auth.getClass().getName().equals("com.application.auth.DefaultAuthenticationHandler")) {
  // ...
}

Comparing fully qualified class names is insufficient because distinct class loaders can load differing classes with identical fully qualified names into a single JVM.

Compliant Solution

This compliant solution compares the class object of class Auth to the class object of the class that the current class loader loads, instead of comparing just the class names.

 // Determine whether object h has required/expected class name
if (auth.getClass() == this.getClassLoader().loadClass("com.application.auth.DefaultAuthenticationHandler")) {
  // ...
}

The call to loadClass() returns the class with the specified name in the current name space (consisting of the class name and the defining class loader), and the comparison is correctly performed on the two class objects.

Noncompliant Code Example

This noncompliant code example compares the names of the class objects of classes x and y using the equals() method. Again, it is possible that x and y are distinct classes with the same name, if they come from different class loaders.

// Determine whether objects x and y have the same class name
if (x.getClass().getName().equals(y.getClass().getName())) {
  // Code assumes that the objects have the same class
}

Compliant Solution

This compliant solution correctly compares the two objects' classes.

// Determine whether objects x and y have the same class
if (x.getClass() == y.getClass()) {
  // Code determines whether the objects have the same class
}

Risk Assessment

Comparing classes solely using their names can allow a malicious class to bypass security checks and gain access to protected resources.

Related Guidelines

Bibliography

OBJ11-J. Prevent access to partially initialized objects      04. Object Orientation (OBJ)