Page History

Wiki MarkupIn a JVM a class is identified by its fully-qualified class name AND its classloader. A class with the same name but different package name is different, and a class with the same fully-qualified name but which has been loaded with a different classloader is also different. According to \[1\] §2.8.1, "Two classes are the _same class_ (and therefore the _same type_) if they are loaded by the same class loader and they have the same fully qualified name".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]. 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 to check You may frequently want to know whether a given object has a specific class , type or whether 2 two objects have the same class type associated with them, for example, in when implementing the equals() method. If the comparison is performed incorrectly, your the code might could assume that 2 the two objects are of the same class when they 're notare not. As a result, class names must not be compared.

Depending on the function that this the insecure code performs, this might introduce a vulnerability it could be vulnerable to a mix-and-match attack. An attacker can supply code that is could supply a malicious class with the same fully qualified name as your class; if you rely on comparing the classname as a string, you might end up believing it is privileged code and granting it undue privileges.

Non-Compliant Solution

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 codebase are the same is error prone. 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 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 codebase.

Noncompliant Code Example

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

 // Determine whether object auth

 // determine whether object h has required/expected class nameobject
 if (hauth.getClass().getName().equals(
      "com.application.auth.DefaultAuthenticationHandler")) {
      // code assumes it's an authorized class...
}

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 auth to the class object for the canonical default authentication handler:

 
 // determineDetermine whether object hauth has required/expected class name
 if (hauth.getClass() == this.getClassLoader().loadClass("DefaultAuthenticationHandler")com.application.auth.DefaultAuthenticationHandler.class) {
      // code determines authorized class loaded by same classloader...
}

 Non-Compliant Solution

The 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 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

 // determine whether objects x and y have the same class name
if (x.getClass().getName().equals( y.getClass().getName() )) {
     // codeObjects assumeshave objectsthe have 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()) {
     // codeObjects determineshave objects havethe same class
}

Conversely, a source of error is assuming that the same codebase will result in the same class in a JVM. While it is usually true in common user applications, it is not the case with J2EE servers like servlet containers, which could use different instances of classloaders to be able to deploy and undeploy applications at runtime without restarting the JVM. In this situation, 2 objects whose classes come from the same codebase could be different classes to the JVM and it could be confusing to get false from the equals() method on their respective classes.

References

...

[http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules.html?page=4] \[Mcgraw and Felten\]

...

Risk Assessment

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

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

...