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.)
CWE-470 Base Draft
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
This vulnerability occurs when an application uses unvalidated external input, like a URL parameter or form field, to dynamically decide which class to load or which method to execute via…
Definition
What is CWE-470?
This vulnerability occurs when an application uses unvalidated external input, like a URL parameter or form field, to dynamically decide which class to load or which method to execute via reflection. An attacker can manipulate this input to force the application to load unexpected, potentially malicious code.
When an application lets user input dictate its control flow through reflection, it hands partial control of its logic to an attacker. By supplying crafted values, an attacker can bypass security checks, access unauthorized features, or trigger unexpected behaviors. The risk becomes critical if an attacker can also place malicious files on the application's classpath, allowing them to directly inject and execute their own code through this same reflection mechanism.
Preventing unsafe reflection requires strict allow-listing of permitted classes or methods and rigorous validation of all dynamic input. While SAST tools can identify the vulnerable pattern, Plexicus uses AI to analyze the context and suggest precise code fixes—such as implementing a secure allow-list—transforming a complex security finding into an actionable remediation that saves development time.
Auswirkungen in der Praxis
Real-world CVEs caused by CWE-470
-
Cryptography API uses unsafe reflection when deserializing a private key
-
Database system allows attackers to bypass sandbox restrictions by using the Reflection API.
Wie Angreifer es ausnutzen
Angreiferpfad Schritt für Schritt
- 1
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:
- 2
A programmer might refactor this code to use reflection as follows:
- 3
The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher. However, the refactoring allows an attacker to instantiate any object that implements the 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 do not modify the access control code, then some Worker classes will not have any access control.
- 4
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:
- 5
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.
Verwundbares Codebeispiel
Vulnerable Java
A programmer might refactor this code to use reflection as follows:
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request); Sicheres Codebeispiel
Secure Java
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); What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Präventions-Checkliste
How to prevent CWE-470
- 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.
Erkennungssignale
How to detect CWE-470
CWE-470
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Häufig gestellte Fragen Was ist CWE-470?
Wie gravierend ist CWE-470?
Welche Sprachen oder Plattformen sind von CWE-470 betroffen?
Wie kann ich CWE-470 verhindern?
Wie erkennt und behebt Plexicus CWE-470?
Wo erfahre ich mehr über CWE-470?
Frequently asked questions
Was ist CWE-470?
This vulnerability occurs when an application uses unvalidated external input, like a URL parameter or form field, to dynamically decide which class to load or which method to execute via reflection. An attacker can manipulate this input to force the application to load unexpected, potentially malicious code.
Wie gravierend ist CWE-470?
MITRE hat für diese Schwachstelle keine Exploit-Wahrscheinlichkeit veröffentlicht. Behandle sie als mittlere Auswirkung, bis dein Threat Model anderes belegt.
Welche Sprachen oder Plattformen sind von CWE-470 betroffen?
MITRE lists the following affected platforms: Java, PHP, Interpreted.
Wie kann ich CWE-470 verhindern?
Refactor your code to avoid using reflection. Do not use user-controlled inputs to select and load classes or code.
Wie erkennt und behebt Plexicus CWE-470?
Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-470 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.
Wo erfahre ich mehr über CWE-470?
MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/470.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.
Verwandte Schwachstellen
Weaknesses related to CWE-470
CWE-913 Parent
Improper Control of Dynamically-Managed Code Resources
This vulnerability occurs when an application fails to properly secure access to code resources that can be created or altered at runtime,…
CWE-1321 Sibling
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Prototype pollution occurs when an application takes user-supplied input and uses it to improperly modify the properties of a JavaScript…
CWE-502 Sibling
Deserialization of Untrusted Data
This vulnerability occurs when an application accepts and processes serialized data from an untrusted source without proper validation,…
CWE-914 Sibling
Improper Control of Dynamically-Identified Variables
This vulnerability occurs when an application fails to properly secure access to variables whose names are determined at runtime, allowing…
CWE-915 Sibling
Improperly Controlled Modification of Dynamically-Determined Object Attributes
This vulnerability occurs when an application accepts user input that specifies which object attributes or fields to create or update, but…
CWE-94 Sibling
Improper Control of Generation of Code ('Code Injection')
This vulnerability occurs when an application builds executable code using unvalidated external input, such as user data. Because the…
Ressourcen
Further reading
- MITRE — offizielle CWE-470 https://cwe.mitre.org/data/definitions/470.html
- Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf
Bereit, das Wesentliche zu validieren?
Bereit zu validieren, was zählt.
Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.