Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.
Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.
Example: In this classic code injection example, the report implements a basic calculator that allows the user to specify commands for execution.
...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE calculator_code_begin user_ops calculator_code_end INTO code0.
SPLIT code0 AT '|' INTO TABLE code.
INSERT REPORT zcalculator FROM code.
SUBMIT (zcalculator).
...
operation
parameter is a benign value, such as "result = 8 + 7 * 2.", in which case the report calculates the value of the expression to be 22. However, if an attacker specifies language operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify "MOVE 'shutdown -h now' to cmd. CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." as the value of operation
, a shutdown command would be executed on the host system.
[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws
[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws
[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 95
[6] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6
[10] Standards Mapping - FIPS200 - (FISMA) SI