CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Official CWE-470 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.
Glexia's Take
CWE-470: Reflection Injection
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Integrity,Confidentiality,Availability,Other: Execute Unauthorized Code or Commands,Alter Execution Logic: The attacker might be able to execute code that is not directly accessible to the attacker. Alternately, the attacker could call unexpected code in the wrong place or the wrong time, possibly modifying critical system state.
- Availability,Other: DoS: Crash, Exit, or Restart,Other: The attacker might be able to use reflection to call the wrong code, possibly with unexpected arguments that violate the API (CWE-227). This could cause the product to exit or hang.
- Confidentiality: Read Application Data: By causing the wrong code to be invoked, the attacker might be able to trigger a runtime error that leaks sensitive information in the error message, such as CWE-536.
Developer Pattern
CWE-470 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Confidence
high confidence from CWE-470, 4.20.
Official CWE Definition
CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
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.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- 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: A programmer might refactor this code to use reflection as follows:,[object Object],One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows:,Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.,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 products, in larger products where complexity grows exponentially, it is not unreasonable that an attacker could find a constructor to leverage as part of an attack.
Remediation
- Architecture and Design: Refactor your code to avoid using reflection.
- Architecture and Design: Do not use user-controlled inputs to select and load classes or code.
- Implementation: Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.
Detection
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.