Unsafe use of Reflection - Revision history

Imifos: Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

2017-11-10T21:51:24Z

Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.

JanWolff: removed dead references to ASDR pages, added some explanations to the Description section. moved content to the Risk section where appropriate, added external references

2016-06-29T09:24:06Z

removed dead references to ASDR pages, added some explanations to the Description section. moved content to the Risk section where appropriate, added external references

JanWolff: JanWolff moved page Unsafe Reflection to Unsafe use of Reflection: clarify the meaning of the title, disambiguation from other attacks like reflected XSS

2016-06-29T08:55:49Z

JanWolff moved page Unsafe Reflection to Unsafe use of Reflection: clarify the meaning of the title, disambiguation from other attacks like reflected XSS

Imifos: fixed classification

2015-12-01T11:49:31Z

fixed classification

Achim: typo in category corrected

2014-11-04T20:16:30Z

typo in category corrected

KirstenS at 02:03, 21 February 2009

2009-02-21T02:03:23Z

KirstenS at 14:21, 19 February 2009

2009-02-19T14:21:46Z

KirstenS at 14:27, 9 November 2008

2008-11-09T14:27:12Z

KirstenS at 13:55, 3 October 2008

2008-10-03T13:55:21Z

Weilin Zhong: Contents provided by Fortify.

2006-07-24T18:44:18Z

Contents provided by Fortify.

@@ Line 104: / Line 104: @@
 [[Category:Input Validation Vulnerability]]
 [[Category:Use of Dangerous API]]
-[[Category:OWASP_Java_Project]]
+[[Category:Java]]
 [[Category:Code Snippet]]
 [[Category:Implementation]]
 [[Category:Vulnerability]]

@@ Line 2: / Line 2: @@
 <!-- advertising removed:  {{Template:Fortify}}  -->
-Last revision (mm/dd/yy): '''02/20/2009''' <small>(please ''view source'')</small>
+Last revision (mm/dd/yy): '''2016-06-29''' <small>(please ''view source'')</small>
 <!--
      Last revision hardcoded to 02/20/2009 on 04/Nov/2014 because:
-     page source formaly changed (category) but no content changed, which is still the same
+     page source formally changed (category) but no content changed, which is still the same
      Please remove this comment and enable below "Last revision" when page content changes.
@@ Line 12: / Line 12: @@
 -->
-[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
+==Description==
 If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
 This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker can use reflection to introduce new, presumably malicious, behavior into the application.
 ==Examples==
@@ Line 95: / Line 95: @@
 ==References==
+# CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') https://cwe.mitre.org/data/definitions/470.html
-TBD
+# Wikipedia: Reflection https://en.wikipedia.org/wiki/Reflection_%28computer_programming%29
@@ Line 102: / Line 102: @@
 [[Category:Input Validation Vulnerability]]
 [[Category:Use of Dangerous API]]

@@ Line 105: / Line 105: @@
 [[Category:Input Validation Vulnerability]]
 [[Category:Use of Dangerous API]]
-[[Category:Java]]
+[[Category:OWASP_Java_Project]]
 [[Category:Code Snippet]]
 [[Category:Implementation]]
 [[Category:Vulnerability]]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
-{{Template:Fortify}}
+<!-- advertising removed:  {{Template:Fortify}}  -->
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
@@ Line 95: / Line 104: @@
 [[Category:OWASP ASDR Project]]
 [[Category:Input Validation Vulnerability]]
-[[Category:Use of Dangerious API]]
+[[Category:Use of Dangerous API]]
 [[Category:Java]]
 [[Category:Code Snippet]]
 [[Category:Implementation]]
 [[Category:Vulnerability]]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==

← Older revision	Revision as of 08:55, 29 June 2016
(No difference)

@@ Line 2: / Line 2: @@
 {{Template:Fortify}}
-==Abstract==
+[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 ==Description==
 If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner.
@@ Line 12: / Line 20: @@
 This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker can use reflection to introduce new, presumably malicious, behavior into the application.
 ==Examples ==
 A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
@@ Line 56: / Line 69: @@
 This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable that an attacker could find a constructor to leverage as part of an attack.
-==Related Attacks==
+==Related [[Attacks]]==
-==Related Vulnerabilities==
+TBD
-[[:Category:Input Validation]]
+__NOTOC__
 [[Category:Input Validation Vulnerability]]
 [[Category:Use of Dangerious API]]