In a Java Virtual Machine (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.
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 when they are 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 fully qualified name as the target class. If access to a critical resource is granted based on comparison of class names alone, the malicious class may end up with more privileges than is warranted.
Conversely, the assumption that two classes deriving from the same codebase 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 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 (Auth
) of object auth
to the string DefaultAuthenticationHandler
and proceeds depending on the result of the comparison.
// Determine whether object auth has required/expected class name if (auth.getClass().getName().equals("com.application.auth.DefaultAuthenticationHandler")) { // ... }
Multiple classes may exist with the same name in the JVM; consequently this is not a valid comparison.
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 having the specified name in the current namespace (consisting of the class name and the defining 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. 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 using their names may allow a malicious class to gain elevated privileges.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
OBJ06-J |
high |
unlikely |
low |
P9 |
L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
[[Christudas 2005]]
[[JVMSpec 1999]] §2.8.1 Class Names
[[Mcgraw 1998]]
[[MITRE 2009]] CWE ID 486 "Comparison of Classes by Name"
[[Wheeler 2003]] Java
OBJ05-J. Limit extensibility of classes and methods with invariants to trusted subclasses only 04. Object Orientation (OBJ) OBJ07-J. Understand how a superclass can affect a subclass