CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Description

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.

Potential Impact

Integrity, Confidentiality, Availability, Other

Execute Unauthorized Code or Commands, Alter Execution Logic

Availability, Other

DoS: Crash, Exit, or Restart, Other

Confidentiality

Read Application Data

Demonstrative 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:

Good

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);

A programmer might refactor this code to use reflection as follows:

Bad

String ctl = request.getParameter("ctl");
					Class cmdClass = Class.forName(ctl + "Command");
					Worker ao = (Worker) cmdClass.newInstance();
					ao.doAction(request);

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:

Bad

String ctl = request.getParameter("ctl");
				   Class cmdClass = Class.forName(ctl + "Command");
				   Worker ao = (Worker) cmdClass.newInstance();
				   ao.checkAccessControl(request);
				   ao.doAction(request);

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.

Mitigations & Prevention

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 Methods

Automated Static Analysis High — 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 sea

Real-World CVE Examples

CVE ID	Description
CVE-2018-1000613	Cryptography API uses unsafe reflection when deserializing a private key
CVE-2004-2331	Database system allows attackers to bypass sandbox restrictions by using the Reflection API.

Taxonomy Mappings

7 Pernicious Kingdoms: — Unsafe Reflection
The CERT Oracle Secure Coding Standard for Java (2011): SEC06-J — Do not use reflection to increase accessibility of classes, methods, or fields

Frequently Asked Questions

What is CWE-470?

CWE-470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. 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.

How can CWE-470 be exploited?

Attackers can exploit CWE-470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')) to execute unauthorized code or commands, alter execution logic. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.

How do I prevent CWE-470?

Key mitigations include: Refactor your code to avoid using reflection.

What is the severity of CWE-470?

CWE-470 is classified as a Base-level weakness (Medium abstraction). It has been observed in 2 real-world CVEs.