An attacker might be able to create unexpected control flow paths through the application, potentially bypassing security checks.
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. Even the ability to control the arguments passed to a given method or constructor may give a wily attacker the edge necessary to mount a successful attack.
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.
Example: 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:
String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
ao = new AddCommand();
} else if (ctl.equals("Modify")) {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
ao.doAction(request);
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request);
if/else
blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher.Worker
interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker
interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker
classes will not have any access control.Worker
object responsible for performing the access control check. An example of the re-refactored code follows:
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);
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. [1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A1 Unvalidated Input
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A4 Insecure Direct Object Reference
[3] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A4 Insecure Direct Object References
[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 470
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.4
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8
[9] Standards Mapping - FIPS200 - (FISMA) SI