Code Injection and Mitigation with Example

Code injection is the malicious injection or introduction of code into an application. The code introduced or injected is capable of compromising database integrity and/or compromising privacy properties, security and even data correctness. It can also steal data and/or bypass access and authentication control. Code injection attacks can plague applications that depend on user input for execution.

Code Injection differs from Command Injection. Here an attacker is only limited by the functionality of the injected language itself. For example, if an attacker is able to inject PHP code into an application and have it executed, he is only limited by what PHP is capable of.

Code injection vulnerabilities range from easy to difficult-to-find ones. Many solutions have been developed for thwarting these types of code injection attacks, for both application and architecture domain. Some examples include input validation, parameterization, privilege setting for different actions, addition of extra layer of protection and others.

Example:
When a developer uses the PHP eval() function and passes it untrusted data that an attacker can modify, code injection could be possible.

The example below shows a dangerous way to use the eval() function:

As there is no input validation, the code above is vulnerable to a Code Injection attack.

For example:

/index.php?arg=1; phpinfo()

Above will show all the info of php.

While exploiting bugs like these, an attacker may want to execute system commands. In this case, a code injection bug can also be used for command injection, for example:

/index.php?arg=1; system('id')

This will tell the ids of the process.
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Mitigation
Ideally, a developer should use existing API for their language. For example (Java): Rather than use Runtime.exec() to issue a ‘mail’ command, use the available Java API located at javax.mail.*
If no such available API exists, the developer should scrub all input for malicious characters. Implementing a positive security model would be most efficient. Typically, it is much easier to define the legal characters than the illegal characters.