What Is Code Injection?
Code injection refers to attacks that involve injecting malicious code into an application. The application then interprets or executes the code, affecting the performance and function of the application. Code injection attacks typically exploit existing data vulnerabilities, such as insecure handling of data from untrusted sources.
Code injection attacks are different from command injection attacks, because in code injection attackers are limited only by the functionality of the language they inject. For example, attackers who can inject and execute PHP can accomplish anything that PHP allows. Command injection involves exploiting an application’s existing code to carry out malicious commands, typically using a remote shell.
Code injection often takes advantage of improper validation of input and output data—for instance, data format, expected data volume, and permitted characters.
In this article:
- How Code Injection Attacks Work
- Types of Code Injection Attacks
- Code Injection Attack Examples
- Best Practices for Preventing Code Injection Attacks
- Code Injection with Bright
How Code Injection Attacks Work
Code injection vulnerabilities usually affect applications with improper input validation and risky dynamic evaluation of user-submitted input. This input includes all data that a user can submit or manipulate and the application processes. In addition to directly submitted input (i.e., file uploads, fields in a form), attackers can leverage data sources outside the developer’s control (i.e., cookies, parameters in query strings).
Applications typically expect specific input types, which the developer might not validate or sanitize. The risk is especially high if the production application contains debugging or testing code.
Applications with code injection vulnerabilities use the unsanitized data directly in their program code. Depending on the language used, an application might use functions such as eval(). Directly concatenating strings supplied by users is not considered a safe processing practice. Attackers may exploit this type of vulnerability and input malicious code strings in the application’s language.
Successful code injection attacks may grant full access to attackers via the interpreter on the server side. Attackers can then execute code on the server and use applications with system access to escalate the attack. For example, vulnerable applications with system call access may allow an attacker to execute system commands—known as a command injection attack.
Types of Code Injection Attacks
Here are some of the main types of code injection attacks.
A cross site scripting (XSS) attack involves injecting malicious scripts into web apps and websites, which the user’s device then executes. XSS allows attackers to impersonate legitimate users and bypass security controls. They can use an initially benign website or application as an attack vector, delivering malicious scripts to the user’s web browsers without arousing suspicion.
Attackers use XXS to steal session cookies and identifiers, user names, or passwords.
These attacks use the Lightweight Directory Access Protocol (LDAP) to search network resources, including users, devices, and files. An LDAP injection attack may result in unvalidated LDAP statements directing the server to execute malicious commands.
These attacks exploit the Structured Query Language (SQL), a standard language for database communication. Attackers can use SQL injection to target almost all databases in all programming languages, including XML.
Attackers can inject malicious commands using the SQL syntax. They can compromise queries to view or modify databases. Some developers design fields where users can submit expanded results in SQL to access sensitive information like passwords.
A command injection attack is a subject of code injection where the attacker executes arbitrary (malicious) commands on the host operating system. Command injection might involve directly executing shell commands or injecting files into the runtime environment of a server.
Attackers typically exploit an existing application vulnerability to inject the commands—for example, the application might poorly transmit user data like forms and cookies, facilitating command injection into the web server’s system shell.
Code Injection Attack Examples
The following examples are based on code provided by the OWASP project.
Passing Malicious Script via GET Request
Consider a website that switches pages using a URL parameter:
Inside the code, the PHP
include() function is used to parse the page contents with no input validation. In this case, an attacker can replace contact.php with a malicious script hosted on another domain. For example, the attacker can access the website using this URL:
The website will then pull the malicious.php script via the
include() function and execute it—this constitutes a command injection attack.
Running System Commands via URL Parameter
Consider a website that extracts a value from a URL parameter and applies the
function to examine its content:
$var = "some_string";
$a = $_GET['arg'];
eval("$var = $a;");
If there is no input validation on URL parameters, the attacker can inject a command into the parameter:
The page will then evaluate the expression
arg=1; phpinfo() and run the system command planted by the attacker. This is another form of code injection attack.
Learn more in these guides:
- Code injection examples
- Code injection PHP (coming soon)
Best Practices for Preventing Code Injection Attacks
Here are some best practices to help organizations protect their applications from code injection attacks:
- Validate user input with allow lists—allow listing provides tight security control over the types of data or input processed by an application. It is easy to set up and helps minimize the risk of malicious code execution, limiting an attacker’s ability to inject untrusted code.
- Escape outputs—escaping involves encoding contextual HTML outputs to translate malicious input into safe representatives. Applications can safely display escaped scripts without the risk of executing malicious code.
- Enforce language separation with static type systems—a static type system allows the security team to establish declarative control checks without minimal runtime overhead.
- Interpret user input with criteria-based APIs and parameterized queries—this method prevents APIs from accepting any unspecified user string values. Parameterized queries treat malicious command inputs as data strings rather than SQL commands.
- Keep the source code free of insecure functions—developers should avoid including any vulnerable code constructs in source code. They should only use dedicated, secure features for processing user-submitted inputs, restricting the code permitted to specific languages.
- Disable script interaction from the client side—placing the HttpOnly flag on a cookie indicates it should be inaccessible from the client side. The server should use this flag on all cookies it creates to prevent their exposure to a third party and protect against HTML injection vulnerabilities.
- Identify and remediate issues with SCA tools—software composition analysis (SCA) tools let teams automatically check static to identify and eliminate potential injection vectors in the source code.
Code Injection with Bright
Bright Security automatically crawls your applications to test for code injection vulnerabilities including XSS, SQLi, LDAP injection and Command injection, giving you maximum coverage, seamlessly integrated across development pipelines.
Engineering and security teams can trust Bright’s results, with automatic validation of every code injection finding carried out, with no false positives. Bright’s reports come with comprehensive developer friendly remediation advice to fix the issue quickly and early.