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|AA. Bibliography#JVMSpec 99]\]. 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 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. Wiki Markup
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.
...
Conversely, the assumption that two classes deriving from the same code base codebase are themselves the same is error - prone. While Although 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 codebase 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 basecodebase.
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.:
Code Block | ||
---|---|---|
| ||
// Determine whether object auth has required/expected class nameobject 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 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:
Code Block | ||
---|---|---|
| ||
// Determine whether object auth has required/expected class objectname if (auth.getClass() == this.getClass().getClassLoader().loadClass("com.application.auth.DefaultAuthenticationHandler").class) { // ... } |
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 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.
...
This noncompliant code example compares the names of the class objects of 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.
Code Block | ||
---|---|---|
| ||
// Determine 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.:
Code Block | ||
---|---|---|
| ||
// Determine whether objects x and y have the same class if (x.getClass() == y.getClass()) { // Code assumes that the objects 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.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
OBJ09-J |
High |
Unlikely |
Low | P9 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
The Checker Framework |
| Signature String Checker | Ensure that the string representation of a type is properly used for example in Class.forName (see Chapter 13) | ||||||
Parasoft Jtest |
| CERT.OBJ09.CMP | Do not compare Class objects by name | ||||||
PVS-Studio |
| V6054 | |||||||
SonarQube |
| S1872 | Classes should not be compared by name |
Related Guidelines
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e0f434d0-956b-40f3-b2c0-7868eead916b"><ac:plain-text-body><![CDATA[
] |
Internals of Java Class Loading |
]]></ac:plain-text-body></ac:structured-macro>
] |
http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html]
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="dcf0397c-9b57-4fbf-8790-b89ad605cbd2"><ac:plain-text-body><![CDATA[
[[McGraw 1998
AA. Bibliography#Mcgraw 98]]
Twelve rules for developing more secure Java code
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1dad2271-ee1e-40f3-b3a7-7d2efbf40e53"><ac:plain-text-body><![CDATA[
[[Wheeler 2003
AA. Bibliography#Wheeler 03]]
[Java
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html] Secure programming for Linux and Unix HOWTO
]]></ac:plain-text-body></ac:structured-macro>
"Twelve Rules for Developing More Secure Java Code" | |
...
04. Object Orientation (OBJ) OBJ10-J. Do not use public static nonfinal variables