Difference between revisions of "Comparing classes by name"

Jump to: navigation, search
Line 1: Line 1:
| type=inactiveDraft
| comment=This vulnerability needs to be completed.

Latest revision as of 21:58, 9 July 2014

This page contains draft content that has never been finished. Please help OWASP update this content! See FixME.
Comment: This vulnerability needs to be completed.

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

Last revision (mm/dd/yy): 07/9/2014

Vulnerabilities Table of Contents


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.


  • 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.


  • Languages: Java
  • Operating platforms: Any

Required resources




Likelihood of exploit


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.

Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


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

Related Attacks

Related Vulnerabilities

Related Controls

  • Control 1
  • Control 2
  • 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.

Related Technical Impacts