OBJ34-J. Compare classes and not class names

In a Java Virtual Machine (JVM), a class is identified by its fully qualified class name and its class loader. 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. "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 99]].

Sometimes it is desirable 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 might assume that the two objects are of the same class whilst they're not.

Depending on the function that the insecure code performs, it may be vulnerable to a mix-and-match attack. An attacker may supply a malicious class with the same name as the target class. If it is just the class names that are compared to grant access to a critical resource, the malicious class may end up with more privileges than it requires.

Conversely, the assumption that the same codebase will result in the same class in a JVM is error-prone. While the misleading assumption is commonly observed to be true in desktop applications, typically this is not the case with J2EE servlet containers. The containers may 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 codebase, may appear to the JVM to be two different classes. Also note that the equals() method may not return true when comparing objects originating from the same codebase.

Noncompliant Code Example

This noncompliant code example compares the name of the class of object h to the string DefaultAuthenticationHandler and proceeds depending on the result of the comparison.

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

The main issue is that another class may exist with the same name in the JVM.

Compliant Solution

This compliant solution compares the class object of class h 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 (h.getClass() == this.getClassLoader().loadClass("com.application.auth.DefaultAuthenticationHandler")) {
  // ...
}

The call to loadClass() returns the class having the specified name in the current namespace (of the classloader), 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.

// 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 using their names may give an attacker supplied class undesirable privileges.

Related Vulnerabilities

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

References

[[JVMSpec 99]] §2.8.1 Class Names
[[Christudas 05]]
[[Mcgraw 98]]
[[Wheeler 03]] Java
[[MITRE 09]] CWE ID 486 "Comparison of Classes by Name"

OBJ33-J. Limit the extensibility of non-final classes and methods to only trusted subclasses      08. Object Orientation (OBJ)      OBJ35-J. Use checked collections against external code