When software permits the input of user to contain code syntax, it may be possible for a hacker to craft the code in such a way that it will change the proposed control flow of the software. Such a modification possibly will show the way to arbitrary code execution.

An injection problem covers a wide range of issues in different ways. The most significant problem to note is that each and every injection problems share one thing in common -- i.e., they permit for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be misused by transferring the code through genuine data channels, using no other mechanism. While buffer overflows, and many other flaws, engage the use of some further issue to gain execution, injection problems require only for the data to be parsed. SQL injection and format string vulnerabilities are the most typical instantiations of this kind of weakness.

This illustration try to write user messages to a message file and let users to view them.

PHP Example:

$InfoFile = "seo/codeinject.out";
If ($_GET ["action"] == "Message to write")
{
$name = $_GET ["name"];
$message = $_GET ["message"];
$handle = fopen ($InfoFile, "a+");
fwrite($handle, "$name says '$message'\n");
Fclose ($handle);
Echo "Message Saved Successfully! \n";
}

Else if ($_GET ["action"] == "ViewMessages")

{

Include ($InfoFile);

}
While the programmer proposes for the InfoFile to only include data, an attacker can supply a message such as:
name=h4x0rmessage=%3C?php%20system(%22/bin/ls%20-l%22);?%3E

which will decode as given below:

within php tag type the command given below

system("/bin/ls -l");

he programmer thought they were just including the contents of a regular data file, but PHP parsed it and executed the code. Now, this code is executed any time people view messages.

How to overcome

Your code should run in a "jail" or similar sandbox atmospheres that impose firm limitations between the process and the operating system. This may efficiently put a ceiling on code executed by your software.(Ex) Unix chroot jail and AppArmor. On the whole, managed code must be in some protected area.

Imagine all input is malicious. Use good input validation strategy. Decline any input that does not strictly conform to specifications, or transform it into something that does. Use a blacklist to reject any unexpected inputs and detect potential attacks.

To diminish the chances of code injection, use strict whitelists that set boundary which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker can reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().