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 application implements a basic calculator that allows the user to specify commands for execution.
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation
parameter is a benign value, such as "8 + 7 * 2", in which case the result
variable is assigned a value of 22. However, if an attacker specifies languages 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, Javascript allows invocation of Java objects; if an attacker were to specify " java.System.RunTime.exec("shutdown -h now")" 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 2004 - (OWASP 2004) A1 Unvalidated Input
[3] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws
[4] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A3 Malicious File Execution
[5] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws
[6] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[7] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 94
[8] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 95
[9] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116
[10] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116, Risky Resource Management - CWE ID 094
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.3
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6
[17] Standards Mapping - FIPS200 - (FISMA) SI