Difference between revisions of "Comparing classes by name"

From OWASP
Jump to: navigation, search
m
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{taggedDocument
 +
| type=pls_review
 +
}}
 +
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
Line 9: Line 13:
  
 
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.
 
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.
 +
It is based on the fact that two different classes with same fully qualified class name can be loaded with distinct class loaders.
 +
So two classes are considered to be same only when they are loaded by the same class loader and they have the same fully qualified name.
 +
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
  
 
'''Consequences'''
 
'''Consequences'''
Line 40: Line 47:
 
==Risk Factors==
 
==Risk Factors==
  
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
+
An attacker could supply a malicious class with the same fully qualified name as 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.
* Discuss the technical impact of a successful exploit of this vulnerability
+
* Consider the likely [business impacts] of a successful attack
+
 
+
  
 
==Examples==
 
==Examples==
 +
In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names
 
<pre>
 
<pre>
if (inputClass.getClass().getName().equals("TrustedClassName")) {
+
if (inputClass.getClass().getName().equals("trusted.package.TrustedClassName")) {
 
   // Do something assuming you trust inputClass
 
   // Do something assuming you trust inputClass
 
   // ...
 
   // ...
Line 53: Line 58:
 
</pre>
 
</pre>
  
==Related [[Attacks]]==
+
==Compliant Solution==
  
* [[Attack 1]]
 
* [[Attack 2]]
 
 
 
==Related [[Vulnerabilities]]==
 
 
* [[Vulnerability 1]]
 
* [[Vulnerabiltiy 2]]
 
 
==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.  
 
* 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.  
 
+
<pre>
 
+
if (inputClass.getClass() == trusted.package.TrustedClass.class) {
==Related [[Technical Impacts]]==
+
// Do something assuming you trust inputClass
 
+
// ...
* [[Technical Impact 1]]
+
}
* [[Technical Impact 2]]
+
</pre>
 
+
  
 
==References==
 
==References==
TBD
+
https://cwe.mitre.org/data/definitions/486.html<br>
 +
https://www.securecoding.cert.org/confluence/display/java/OBJ09-J.+Compare+classes+and+not+class+names
  
 
[[Category:FIXME|add links
 
[[Category:FIXME|add links

Latest revision as of 05:57, 20 January 2016

This Page has been flagged for review. Please help OWASP and review this Page to FixME.

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


Last revision (mm/dd/yy): 01/20/2016

Vulnerabilities Table of Contents

Description

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. It is based on the fact that two different classes with same fully qualified class name can be loaded with distinct class loaders. So two classes are considered to be same only when they are loaded by the same class loader and they have the same fully qualified name. 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

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

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

An attacker could supply a malicious class with the same fully qualified name as 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.

Examples

In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names

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

Compliant Solution

  • 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.
if (inputClass.getClass() == trusted.package.TrustedClass.class) {
// Do something assuming you trust inputClass
// ...
}

References

https://cwe.mitre.org/data/definitions/486.html
https://www.securecoding.cert.org/confluence/display/java/OBJ09-J.+Compare+classes+and+not+class+names