The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.
If the product uses external inputs to determine which class to instantiate or which method to invoke, then an attacker could supply values to select unexpected classes or methods. If this occurs, then the attacker could create control flow paths that were not intended by the developer. These paths could bypass authentication or access control checks, or otherwise cause the product 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 product's classpath (CWE-427) or add new entries to the product's classpath (CWE-426). Under either of these conditions, the attacker can use reflection to introduce new, malicious behavior into the product.
Threat Mapped score: 0.0
Industry: Finiancial
Threat priority: Unclassified
CVE: CVE-2018-1000613
Cryptography API uses unsafe reflection when deserializing a private key
CVE: CVE-2004-2331
Database system allows attackers to bypass sandbox restrictions by using the Reflection API.
N/A
| Phase | Note |
|---|---|
| Architecture and Design | N/A |
| Implementation | N/A |
Intro: 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:
Body: A programmer might refactor this code to use reflection as follows:
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);