Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  

CWE-914: Improper Control of Dynamically-Identified Variables

Weakness ID: 914
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software does not properly restrict reading from or writing to dynamically-identified variables.
+ Extended Description
Many languages offer powerful features that allow the programmer to access arbitrary variables that are specified by an input string. While these features can offer significant flexibility and reduce development time, they can be extremely dangerous if attackers can modify unintended variables that have security implications.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Architecture and Design
+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.


Technical Impact: Modify Application Data

An attacker could modify sensitive data or program variables.

Technical Impact: Execute Unauthorized Code or Commands


Technical Impact: Varies by Context; Alter Execution Logic

+ Demonstrative Examples

Example 1

This code uses the credentials sent in a POST request to login a user.

(bad code)
Example Language: PHP 
//Log user in, and set $isAdmin to true if user is an administrator
function login($user,$pass){
$query = buildQuery($user,$pass);
if(getUserRole($user) == "Admin"){
$isAdmin = true;



$isAdmin = false;

The call to extract() will overwrite the existing values of any variables defined previously, in this case $isAdmin. An attacker can send a POST request with an unexpected third value "isAdmin" equal to "true", thus gaining Admin privileges.

+ Observed Examples
extract issue enables file inclusion
extract used for register_globals compatibility layer, enables path traversal
extract() buried in include files makes post-disclosure analysis confusing; original report had seemed incorrect.
extract() enables static code injection
import_request_variables() buried in include files makes post-disclosure analysis confusing
Chain: Dynamic variable evaluation allows resultant remote file inclusion and path traversal.
Chain: dynamic variable evaluation in PHP program used to modify critical, unexpected $_SERVER variable for resultant XSS.
Chain: dynamic variable evaluation in PHP program used to conduct remote file inclusion.
Dynamic variable evaluation in mail program allows reading and modifying attachments and preferences of other users.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

For any externally-influenced input, check the input against a white list of internal program variables that are allowed to be modified.

Phases: Implementation; Architecture and Design

Strategy: Refactoring

Refactor the code so that internal program variables do not need to be dynamically identified.
+ Weakness Ordinalities
(where the weakness exists independent of other weaknesses)
+ Content History
Submission DateSubmitterOrganization
2013-01-26CWE Content TeamMITRE
Modification DateModifierOrganization
2017-01-19CWE Content TeamMITRE
updated Relationships

More information is available — Please select a different filter.
Page Last Updated: January 18, 2018