In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.
Extended Description
The resultant vulnerabilities depend on the behavior of the application, both at the crossover point and in any control/data flow that is reachable by the related variables or functions.
Dynamic variable evaluation in mail program allows reading and modifying attachments and preferences of other users.
Related Attack Patterns (CAPEC)
N/A
Attack TTPs
N/A
Modes of Introduction
Phase
Note
Implementation
N/A
Common Consequences
Impact: Modify Application Data, Execute Unauthorized Code or Commands — Notes: An attacker could gain unauthorized access to internal program variables and execute arbitrary code.
Potential Mitigations
Implementation: Refactor the code to avoid dynamic variable evaluation whenever possible. (N/A)
Implementation: Use only allowlists of acceptable variable or function names. (N/A)
Implementation: For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments. (N/A)
Applicable Platforms
PHP (N/A, Undetermined)
Perl (N/A, Undetermined)
Demonstrative Examples
N/A
Notes
Research Gap: Under-studied, probably under-reported. Few researchers look for this issue; most public reports are for PHP, although other languages are affected. This issue is likely to grow in PHP as developers begin to implement functionality in place of register_globals.