Page History

Wiki MarkupIn 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 with 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|AA. Java References#JVMSpec 99]\] ), "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]. Two classes with the same name but different package names are distinct, as are two classes with the same fully qualified name loaded by different class loaders.

It could be necessary 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, while when implementing the equals() method. If the comparison is performed incorrectly, the code might could assume that the two objects are of the same class whilst they're notwhen they are not. As a result, class names must not be compared.

Depending on the function that this the insecure code performs, it may could be vulnerable to a mix-and-match attack. An attacker can could supply a malicious class with the same fully qualified name as the target class. If only the class names are compared to grant access to a critical resourceprotected resource is granted based on the comparison of class names alone, the malicious class may end up with more privileges than it requiresunprivileged class could gain unwarranted access to the resource.

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

Noncompliant Code Example

In this This noncompliant code example , the code compares the name of the class of object h auth to the string "com.application.auth.DefaultAuthenticationHandler and proceeds according to whether this comparison succeeds or not." and branches on the result of the comparison:

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

The problem with this example is that another class may exist with the same name in the 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 h to object auth to the class object of the class that the current class loader loads instead of comparing just the class names.for the canonical default authentication handler:

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

The call to loadClass() returns the class having the specified name in the current namespace (of the classloader), and right-hand side of the comparison directly names the class of the canonical authentication handler. In the event that the canonical authentication handler had not yet been loaded, the Java runtime manages the process of loading the class. Finally, 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 and behaves accordingly. Again, it is possible that x and y are distinct classes with the same name if they come from different class loaders.

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

Compliant Solution

This compliant solution correctly compares the two objects' classes.:

// determineDetermine whether objects x and y have the same class
if (x.getClass() == y.getClass()) {
  // code determines whether the objects Objects have the same class
}

Risk Assessment

Comparison of Comparing classes solely using their names may give an attacker supplied class undesirable privilegescan allow a malicious class to bypass security checks and gain access to protected resources.

Related Vulnerabilities

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

References

\[[JVMSpec 99|AA. Java References#JVMSpec 99]\] [§2.8.1 Class Names|http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html]
\[[Christudas 05|AA. Java References#Christudas 05]\]
\[[Mcgraw 98|AA. Java References#Mcgraw 98]\]
\[[Wheeler 03|AA. Java References#Wheeler 03]\] [Java|http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html]
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 486|http://cwe.mitre.org/data/definitions/486.html] "Comparison of Classes by Name"

Automated Detection

Related Guidelines

Bibliography

...

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