Page History

...

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 protected resource is granted based on comparison of class names alone, the malicious unprivileged class may end up with more privileges than is warrantedgain unwarranted access to the resource.

Conversely, the assumption that two classes deriving from the same code base 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 code base 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 code base.

...

This noncompliant code example compares the name of the class (Auth) of object auth to the string "com.application.auth.DefaultAuthenticationHandler" and proceeds depending branches on the result of the comparison.

...

The call to loadClass() returns the class having the specified name in the current name space (consisting of the class name and the defining classloaderclass loader), and the comparison is correctly performed on the two class objects.

...

Risk Assessment

Comparing classes solely using their names may allow a malicious class to gain elevated privilegesbypass security checks and gain access to protected resources.

...