Difference between revisions of "Comparing classes by name"

From OWASP
Jump to: navigation, search
 
(Examples)
Line 43: Line 43:
 
==Examples ==
 
==Examples ==
  
 +
<pre>
 
if (inputClass.getClass().getName().equals("TrustedClassName")) {
 
if (inputClass.getClass().getName().equals("TrustedClassName")) {
 
   // Do something assuming you trust inputClass
 
   // Do something assuming you trust inputClass
   //
+
   // ...
 
}
 
}
 +
</pre>
 +
 
==Related problems ==
 
==Related problems ==
  

Revision as of 12:18, 16 April 2006



Overview

The practice of determining an object's type, based on its name, is dangerous since malicious code may purposely reuse class names in order to appear trusted.

Consequences

  • Authorization: If a program trusts, based on the name of the object, to assume that it is the correct object, it may execute the wrong program.

Exposure period

  • Implementation: This flaw is a simple logic issue, introduced entirely at implementation time.

Platform

  • Languages: Java
  • Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

High

Avoidance and mitigation

  • Implementation: Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.

Discussion

If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.

Examples

if (inputClass.getClass().getName().equals("TrustedClassName")) {
  // Do something assuming you trust inputClass
  // ...
}

Related problems

Not available.

Categories