WHAT IS CODE INJECTION AND HOW YOU CAN AVOID IT

Code Injection vulnerabilities is a general term that describes vulnerabilities that can be exploited by an attacker to inject and execute malicious code. This vulnerability occurs usually due to the lack of untrusted data validation. Applications which directly evaluate code without validating it first would be vulnerable
Code Injection

Code Injection vulnerabilities is a general term which describes vulnerabilities that can be exploited by an attacker to inject and execute malicious code.

This vulnerability occurs usually due to the lack of untrusted data validation. Applications which directly evaluate code without validating it first would be vulnerable to this type of attack.

Code Injection is sometimes confused with other vulnerabilities such as and Command Injection. It should be noted that Code Injection is a different type of vulnerability, whereby an attacker is injecting code instead of Operating System commands. This means that with regards to Code Injection vulnerabilities, the attacker is limited by the application’s language functionality.

Attacker Limitations

When exploiting such vulnerabilities, attackers are limited by the application’s language (such as PHP / Python) functionality. However, in most cases, the attacker might be able to leverage the interpreter’s functionality to transition from Code Injection to Command Injection.

For instance, if an attacker injects PHP code into a web application, the attacker would be limited by the functionality available by the PHP interpreter. When the injection attack occurs, the PHP interpreter would execute the injected code and depend on the interpreter’s functionality, an attacker could leverage program execution functions that are available in PHP such as system() or shell_exec in order to execute system commands.

Code Injection

The Impact of a Code Injection

The impact that a successful attack would have can vary depending on several factors such as the language used by the application, the functionality available by application, etc.

However, in most cases, a successful attack could completely compromise the confidentiality, integrity, and availability of the application and its data.

Example

Imagine a web application which passes untrusted data, such as the user’s input to a PHP eval() function. The eval() function simply evaluates a string as PHP code as long as it has valid PHP syntax and ends with a semicolon.

<?php

$backup = “”;

$input = $_GET[‘input’];

eval(“\$backup = \$input;”);

?>

Since the application passes the user’s input into the dangerous PHP eval() function and there is no validation being carried out, the application would be vulnerable to Code Injection attacks.

An attacker could exploit this weakness by supplying the input 1; phpinfo(); as shown below:

https://example.com/index.php?arg=1;https://example.com/index.php?arg=1; phpinfo();

Execute OS system commands

After verifying the vulnerability, an attacker could proceed with executing system commands by leveraging the interpreter’s functions that allow command execution. In this case, the system() function is used.

https://example.com/index.php?arg=1;https://example.com/index.php?arg=1; system(‘whoami’);

The whoami command prints the username of the current user when invoked. This means that when the application

passes the user’s input to the eval() function, the PHP interpreter would execute the whoami command on the

underlying OS.

Once the attacker can execute system commands, they could proceed with gaining an interactive shell on the vulnerable

system and carry out other attacks against other systems within the compromised system’s internal network.

Prevention

Regardless of the language being used, Code Injection vulnerabilities can be avoided by following the best practices

described below:

Avoid evaluating untrusted data

◦ Unless it’s strictly required, do not directly evaluate untrusted data using unsafe functions such as eval(). • Treat all data as untrusted

◦ Note that untrusted data does not refer only to the inputs provided via HTML forms. Information that is controlled by users such as cookies, HTTP request headers, and uploaded files should be treated as untrusted.

ValidateUntrusted Data

◦ Always validate user input on the server-side.

◦ If the user is supposed to submit input in a specific format such as date, postcode, numbers, email

address, etc, make sure that the user’s input matches the expected format.

◦ If the application expects a value within a limited set of options, follow a whitelist approach and ensure that

the input submitted is one of the allowed options.

Harden the interpreter

◦ For example, the PHP interpreter’s functionality should be limited to the bare minimum functionality that is required for the application to function. This could make it much more difficult for attackers to execute system commands. For instance, the PHP program execution functions could be disabled by modifying the php.ini file.

Static Analysis

◦ Perform static analysis activities to identify vulnerabilities related to unsafe evaluation.

VAPT

◦ Perform regular Vulnerability Assessment and Penetration Testing activities to identify and mitigate such weaknesses.

References

https://owasp.org/www-community/attacks/Code_Injection

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on reddit
Reddit
Share on telegram
Telegram
Share on whatsapp
WhatsApp
Share on email
Email

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top