Code Injection is a critical web application vulnerability that occurs when an attacker is able to inject arbitrary source code into an application, which is then interpreted or executed by the runtime environment. This typically happens when untrusted input is evaluated or compiled as code without proper validation or sanitization. Code Injection allows attackers to execute arbitrary instructions within the application’s execution context, often resulting in full system compromise.

Unlike Command Injection, which targets the host operating system via shell commands, Code Injection manipulates the application’s internal language interpreter — for example, injecting PHP, Python, ASP.NET, Ruby, or JavaScript code that is executed server-side. The scope of this attack is limited only by the capabilities of the targeted language and the permissions under which the application runs.

Common attack scenarios:

• Dynamic evaluation functions such as eval(), exec(), assert(), or CodeDom.CompileAssemblyFromSource() that process unsanitized user input.
• Template engines (e.g., Twig, Jinja2, Razor) that allow direct execution of embedded expressions or code fragments.
• Deserialization flaws where user-controlled data can introduce new code objects or logic.
• Server-side script interpreters that dynamically build and execute code constructs at runtime.

Typical impacts include:

• Execution of arbitrary code on the server, leading to data theft, privilege escalation, or remote takeover.
• Complete compromise of the web server or application environment.
• Defacement or manipulation of application logic and data.
• Installation of persistent backdoors or web shells.
• Disclosure of sensitive data, credentials, and cryptographic secrets.

Conditions enabling Code Injection:

• Applications that process user-supplied input as executable code.
• Absence of input validation, whitelisting, or context-based encoding.
• Use of runtime evaluation or compilation features with dynamic input.
• Overly permissive configurations or development/debugging functions left enabled in production.

Mitigation of Code Injection vulnerabilities focuses on eliminating dynamic code evaluation, enforcing strict input validation, and adopting secure coding patterns.

1. Avoid Dynamic Evaluation
   Refrain from using functions such as eval(), exec(), assert(), or similar mechanisms that interpret input as code. Replace them with safer alternatives or static logic.

2. Input Validation (Whitelisting)
   Enforce strict whitelisting for inputs. Validate based on expected data type, format, and length. Reject or sanitize inputs that contain unexpected tokens such as quotes, parentheses, or script delimiters.

3. Context-Aware Escaping and Encoding
   Properly encode data before passing it into interpreters, compilers, or templating engines. Ensure that variables are treated as data, not executable content.

4. Use Sandboxed Execution
   If dynamic evaluation is absolutely required (e.g., scripting within limited contexts), use isolated sandboxes or restricted interpreters to limit access to system resources.

5. Disable Unnecessary Features
   Turn off debugging features, code generation APIs, and dynamic evaluation modules in production. Restrict access to administrative consoles or developer tools.

6. Apply Least Privilege
   Run applications and interpreters with the minimum permissions necessary. Ensure that application service accounts cannot modify source files or execute OS-level commands.

7. Secure Deserialization and Template Engines
   When using deserialization or server-side templating, ensure that only trusted, signed data is accepted. Disable or restrict expression evaluation features that allow arbitrary code execution.

8. Error Handling and Logging
   Do not expose stack traces, source code, or interpreter errors to users. Log such errors securely and monitor for suspicious inputs indicative of probing attempts.

9. Security Testing and Review
   Include static code analysis and manual code review focused on the use of dynamic evaluation functions. Use dynamic testing to simulate malicious payloads and validate that inputs cannot alter application logic.

10. Defense-in-Depth
    Use Web Application Firewalls (WAFs) to detect and block payloads containing code injection patterns. However, WAFs should be viewed as a secondary control, not a replacement for secure coding.

• Injection Prevention Cheat Sheet
• CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H