Difference between revisions of "Comparing classes by name"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to www.textacelc4tt.com)
(9 intermediate revisions by 3 users not shown)
Line 2: Line 2:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|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.
 
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 ==
+
'''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.
+
* 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 ==
+
'''Exposure period'''
  
 
* Implementation: This flaw is a simple logic issue, introduced entirely at implementation time.
 
* Implementation: This flaw is a simple logic issue, introduced entirely at implementation time.
  
==Platform ==
+
'''Platform'''
  
 
* Languages: Java
 
* Languages: Java
Line 20: Line 24:
 
* Operating platforms: Any
 
* Operating platforms: Any
  
==Required resources ==
+
'''Required resources'''
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood  of exploit ==
+
'''Likelihood  of exploit'''
  
 
High
 
High
  
==Avoidance and mitigation ==
+
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.
  
* 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.
+
==Risk Factors==
  
==Discussion ==
+
* Talk about the [[OWASP Risk Rating Methodology|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 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 ==
 
  
 +
==Examples==
 
<pre>
 
<pre>
 
if (inputClass.getClass().getName().equals("TrustedClassName")) {
 
if (inputClass.getClass().getName().equals("TrustedClassName")) {
Line 49: Line 53:
 
</pre>
 
</pre>
  
==Related problems ==
+
==Related [[Attacks]]==
 +
 
 +
* [[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.
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
TBD
 +
 
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
 +
 
 +
Encoding Vulnerability
 +
 
 +
Error Handling Vulnerability
 +
 
 +
Input Validation Vulnerability
 +
 
 +
Logging and Auditing Vulnerability
 +
 
 +
Session Management Vulnerability]]
  
Not available.
+
__NOTOC__
  
  
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
[[Category:Synchronization and Timing Vulnerability]]
+
[[Category:Range and Type Error Vulnerability]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 
[[Category:Java]]
 
[[Category:Java]]
 
[[Category:.NET]]
 
[[Category:.NET]]

Revision as of 13:27, 27 May 2009

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



Last revision (mm/dd/yy): 05/27/2009

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.

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

  • 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


Examples

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


References

TBD