Difference between revisions of "Comparing classes by name"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
Line 54: Line 55:
  
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 
 
[[Category:Synchronization and Timing Vulnerability]]
 
[[Category:Synchronization and Timing Vulnerability]]
 
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]
 
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 
 
[[Category:Java]]
 
[[Category:Java]]
 
 
[[Category:.NET]]
 
[[Category:.NET]]

Revision as of 14:25, 7 August 2006

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



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.