code injection
{{Short description|Computer bug exploit caused by invalid data}}
{{distinguish|Dependency injection|Arbitrary code execution}}
{{Use dmy dates|date=June 2020}}Code injection is a computer security exploit where a program fails to correctly process external data, such as user input, causing it to interpret the data as executable commands. An attacker using this method "injects" code into the program while it is running. Successful exploitation of a code injection vulnerability can result in data breaches, access to restricted or critical computer systems, and the spread of malware.
Code injection vulnerabilities occur when an application sends untrusted data to an interpreter, which then executes the injected text as code. Injection flaws are often found in services like Structured Query Language (SQL) databases, Extensible Markup Language (XML) parsers, operating system commands, Simple Mail Transfer Protocol (SMTP) headers, and other program arguments. Injection flaws can be identified through source code examination,{{Cite web |title=Top 10 Web Application Security Vulnerabilities |url=http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A6.php |archive-url=https://web.archive.org/web/20180224034000/http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A6.php |archive-date=24 February 2018 |access-date=10 December 2016 |website=Penn Computing |publisher=University of Pennsylvania}} Static analysis, or dynamic testing methods such as fuzzing.{{cite web|title=OWASP Top 10 2013 A1: Injection Flaws|url=https://www.owasp.org/index.php/Top_10_2013-A1-Injection|publisher=OWASP|access-date=19 December 2013|archive-date=28 January 2016|archive-url=https://web.archive.org/web/20160128030657/https://www.owasp.org/index.php/Top_10_2013-A1-Injection|url-status=live}}
There are numerous types of code injection vulnerabilities, but most are errors in interpretation—they treat benign user input as code or fail to distinguish input from system commands. Many examples of interpretation errors can exist outside of computer science, such as the comedy routine "Who's on First?". Code injection can be used maliciously for many purposes, including:
- Arbitrarily modifying values in a database through SQL injection; the impact of this can range from website defacement to serious compromise of sensitive data. For more information, see Arbitrary code execution.
- Installing malware or executing malevolent code on a server by injecting server scripting code (such as PHP).
- Privilege escalation to either superuser permissions on UNIX by exploiting shell injection vulnerabilities in a binary file or to Local System privileges on Microsoft Windows by exploiting a service within Windows.
- Attacking web users with Hyper Text Markup Language (HTML) or Cross-Site Scripting (XSS) injection.
Code injections that target the Internet of Things could also lead to severe consequences such as data breaches and service disruption.{{Cite journal |last1=Noman |first1=Haitham Ameen |last2=Abu-Sharkh |first2=Osama M. F. |date=January 2023 |title=Code Injection Attacks in Wireless-Based Internet of Things (IoT): A Comprehensive Review and Practical Implementations |journal=Sensors |language=en |volume=23 |issue=13 |page=6067 |doi=10.3390/s23136067 |pmid=37447915 |pmc=10346793 |bibcode=2023Senso..23.6067N |issn=1424-8220 |doi-access=free }}
Code injections can occur on any type of program running with an interpreter. Doing this is trivial to most, and one of the primary reasons why server software is kept away from users. An example of how you can see code injection first-hand is to use your [https://developer.mozilla.org/en-US/docs/Learn/Common_questions/Tools_and_setup/What_are_browser_developer_tools browser's developer tools].
Code injection vulnerabilities are recorded by the National Institute of Standards and Technology (NIST) in the National Vulnerability Database (NVD) as CWE-94. Code injection peaked in 2008 at 5.66% as a percentage of all recorded vulnerabilities.{{Cite web|url=http://web.nvd.nist.gov/view/vuln/statistics|title=NVD - Statistics Search|website=web.nvd.nist.gov|access-date=2016-12-09|archive-date=15 December 2023|archive-url=https://web.archive.org/web/20231215120148/https://web.nvd.nist.gov/view/vuln/statistics|url-status=live}}
Benign and unintentional use
Code injection may be done 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 malicious intent.{{Cite web|last=Srinivasan|first=Raghunathan|title=Towards More Effective Virus Detectors|url=http://www.public.asu.edu/~rsriniv8/Documents/srini-das.pdf|work=Arizona State University|access-date=18 September 2010|quote=Benevolent use of code injection occurs when a user changes the behaviour of a program to meet system requirements.|archive-url=https://web.archive.org/web/20100729023112/http://www.public.asu.edu/~rsriniv8/Documents/srini-das.pdf|archive-date=29 July 2010}}{{cite book | last1=Morales | first1=Jose Andre | last2=Kartaltepe | first2=Erhan | last3=Xu | first3=Shouhuai | last4=Sandhu | first4=Ravi | title=Computer Network Security | series=Lecture Notes in Computer Science | volume=6258 | pages=229–241 | chapter=Symptoms-Based Detection of Bot Processes | publisher=Springer | location=Berlin, Heidelberg | year=2010 | isbn=978-3-642-14705-0 | issn=0302-9743 | doi=10.1007/978-3-642-14706-7_18| citeseerx=10.1.1.185.2152 }} Code injection could, for example:
- Introduce a useful new column that did not appear in the original design of a search results page.
- Offer a new way to filter, order, or group data by using a field not exposed in the default functions of the original design.
- Add functionality like connecting to online resources in an offline program.
- Override a function, making calls redirect to another implementation. This can be done with the Dynamic linker in Linux.{{Cite web|url=https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/|title=Dynamic linker tricks: Using LD_PRELOAD to cheat, inject features and investigate programs|date=2013-04-02|website=Rafał Cieślak's blog|access-date=2016-12-10|archive-date=25 December 2021|archive-url=https://web.archive.org/web/20211225191742/https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/|url-status=live}}
Some users may unsuspectingly perform code injection because the input they provided to a program was not considered by those who originally developed the system. For example:
- What the user may consider as valid input may contain token characters or strings that have been reserved by the developer to have special meaning (such as the ampersand or quotation marks).
- The user may submit a malformed file as input that is handled properly in one application but is toxic to the receiving system.
Another benign use of code injection is the discovery of injection flaws to find and fix vulnerabilities. This is known as a penetration test.
Preventing Code Injection
To prevent code injection problems, the person could use secure input and output handling strategies, such as:
- Using an application programming interface (API) that, if used properly, is secure against all input characters. Parameterized queries allow the moving of user data out of a string to be interpreted. Additionally, Criteria API{{cite web|title=The Java EE 6 Tutorial: Chapter 35 Using the Criteria API to Create Queries|url=http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html|publisher=Oracle|access-date=19 December 2013|archive-date=11 November 2013|archive-url=https://web.archive.org/web/20131111182712/http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html|url-status=live}} and similar APIs move away from the concept of command strings to be created and interpreted.
- Enforcing language separation via a static type system.{{cite web | last=Moertel | first=Tom | title=A type-based solution to the "strings problem": a fitting end to XSS and SQL-injection holes? | website=Tom Moertel's Blog | date=2006-10-18 | url=http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html | access-date=2018-10-21 | archive-date=6 August 2013 | archive-url=https://web.archive.org/web/20130806145659/http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html | url-status=live }}
- Validating or "sanitizing" input, such as whitelisting known good values. This can be done on the client side, which is prone to modification by malicious users, or on the server side, which is more secure.
- Encoding input or escaping dangerous characters. For instance, in PHP, using the
htmlspecialchars()
function to escape special characters for safe output of text in HTML and themysqli::real_escape_string()
function to isolate data which will be included in an SQL request can protect against SQL injection. - Encoding output, which can be used to prevent XSS attacks against website visitors.
- Using the
HttpOnly
flag for HTTP cookies. When this flag is set, it does not allow client-side script interaction with cookies, thereby preventing certain XSS attacks.{{Cite web|url=https://www.owasp.org/index.php/HttpOnly|title=HttpOnly|date=12 November 2014|website=OWASP|access-date=10 December 2016|archive-date=26 December 2008|archive-url=https://web.archive.org/web/20081226095717/http://www.owasp.org/index.php/HTTPOnly|url-status=live}} - Modular shell disassociation from the kernel.
- Regarding SQL injection, one can use parameterized queries, stored procedures, whitelist input validation, and other approaches to help mitigate the risk of an attack.{{Cite web|url=https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet|title=SQL Injection Prevention Cheat Sheet|website=OWASP|access-date=10 December 2016|archive-date=20 January 2012|archive-url=https://web.archive.org/web/20120120064335/https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet|url-status=live}} Using object-relational mapping can further help prevent users from directly manipulating SQL queries.
The solutions described 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 injections of user code on a user-operated machine, which often results in privilege elevation attacks. Some approaches that are used to detect and isolate managed and unmanaged code injections are:
- Runtime image hash validation, which involves capturing the hash of a partial or complete image of the executable loaded into memory and comparing it with stored and expected hashes.
- NX bit: all user data is stored in special memory sections that are marked as non-executable. The processor is made aware that no code exists in that part of memory and refuses to execute anything found in there.
- Use canaries, which are randomly placed values in a stack. At runtime, a canary is checked when a function returns. If a canary has been modified, the program stops execution and exits. This occurs on a failed Stack Overflow Attack.
- Code Pointer Masking (CPM): after loading a (potentially changed) code pointer into a register, the user can apply a bitmask to the pointer. This effectively restricts the addresses to which the pointer can refer. This is used in the C programming language.{{cite journal | last1=Philippaerts | first1=Pieter | last2=Younan | first2=Yves | last3=Muylle | first3=Stijn | last4=Piessens | first4=Frank | last5=Lachmund | first5=Sven | last6=Walter | first6=Thomas | title=CPM: Masking Code Pointers to Prevent Code Injection Attacks | journal=ACM Transactions on Information and System Security | volume=16 | issue=1 | date=2013-06-01 | issn=1094-9224 | doi=10.1145/2487222.2487223 | pages=1–27 | s2cid=10947780 | url=http://fort-knox.org/files/tissec.pdf | display-authors=1 | access-date=21 October 2018 | archive-date=24 February 2021 | archive-url=https://web.archive.org/web/20210224082956/http://fort-knox.org/files/tissec.pdf | url-status=live }}
Examples
=SQL injection=
{{Main|SQL injection}}
An SQL injection takes advantage of SQL syntax to inject malicious commands that can read or modify a database or compromise the meaning of the original query.{{Cite journal |last1=Zhuo |first1=Z. |last2=Cai |first2=T. |last3=Zhang |first3=X. |last4=Lv |first4=F. |date=2021-03-12 |title=Long short-term memory on abstract syntax tree for SQL injection detection |url=https://onlinelibrary.wiley.com/doi/10.1049/sfw2.12018 |journal=IET Software |language=en |volume=15 |issue=2 |pages=188–197 |doi=10.1049/sfw2.12018 |s2cid=233582569 |issn=1751-8806|url-access=subscription }}
For example, consider a web page that has two text fields which allow users to enter a username and a password. The code behind the page will generate an 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 "('Password' OR '1'='1')
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. "'1'='1'
" 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:
UserID: ';DROP TABLE User; --'
Password: 'OR"='
then the query will be parsed as:
SELECT User.UserID
FROM User
WHERE User.UserID = ;DROP TABLE User; --'AND Pwd = OR"='
The resulting User
table 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.
= Cross-site scripting =
{{Main|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 enter a message such as:
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 are popular subjects, 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.{{cite book|last1=Hope|first1=Brian|last2=Hope|first2=Paco|last3=Walther|first3=Ben|title=Web Security Testing Cookbook|url=https://archive.org/details/websecuritytesti00hope|url-access=registration|date=15 May 2009|publisher=O'Reilly Media|location=Sebastopol, CA|isbn=978-0-596-51483-9|page=[https://archive.org/details/websecuritytesti00hope/page/254 254]|oclc=297573828}}
= Server Side Template Injection =
Template engines are often used in modern web applications to display dynamic data. However, trusting non-validated user data can frequently lead to critical vulnerabilities{{Cite web |date=2015-08-05 |title=Server-Side Template Injection |url=https://portswigger.net/research/server-side-template-injection |access-date=2022-05-22 |website=PortSwigger Research |archive-date=22 May 2022 |archive-url=https://web.archive.org/web/20220522214453/https://portswigger.net/research/server-side-template-injection |url-status=live }} such as server-side Side Template Injections. While this vulnerability is similar to cross-site scripting, template injection can be leveraged 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
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
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.
=Dynamic evaluation vulnerabilities=
An
$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 "/bin/echo
".
=Object injection=
PHP allows serialization and deserialization of whole objects. If an untrusted input is allowed into the deserialization function, it is possible to overwrite existing classes in the program and execute malicious attacks.{{cite web|title=Unserialize function warnings|url=http://uk3.php.net/manual/en/function.unserialize.php#refsect1-function.unserialize-notes|publisher=PHP.net|access-date=6 June 2014|archive-date=9 May 2015|archive-url=https://web.archive.org/web/20150509190058/http://uk3.php.net/manual/en/function.unserialize.php#refsect1-function.unserialize-notes|url-status=live}} Such an attack on Joomla was found in 2013.{{cite web|title=Analysis of the Joomla PHP Object Injection Vulnerability|url=http://karmainsecurity.com/analysis-of-the-joomla-php-object-injection-vulnerability|access-date=6 June 2014|archive-date=2 March 2013|archive-url=https://web.archive.org/web/20130302093029/http://karmainsecurity.com/analysis-of-the-joomla-php-object-injection-vulnerability|url-status=live}}
= Remote file injection =
{{Main|File inclusion vulnerability}}
Consider this PHP program (which includes a file specified by request):
$color = 'blue';
if (isset($_GET['color']))
$color = $_GET['color'];
require($color . '.php');
The example expects a color to be provided, while attackers might provide
causing PHP to load the remote file.
= Format specifier injection =
{{Main|Uncontrolled format string}}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 specifiers will access the address of password
, which is on the stack, and print Password1
to the screen.
=Shell injection=
Shell injection (or command injection{{cite web|title= Command Injection|url=https://www.owasp.org/index.php/Command_Injection |access-date= 19 December 2013|archive-date= 20 December 2013|archive-url= https://web.archive.org/web/20131220043257/https://www.owasp.org/index.php/Command_Injection}}{{rs|date=March 2025}}) is named after UNIX shells but applies to most systems that allow software to programmatically execute a command line. Here is an example vulnerable tcsh script:
!/bin/tcshcheck 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 to defend against an attack.Douglas W. Jones, CS:3620 Notes, [http://www.cs.uiowa.edu/~jones/opsys/notes/04.shtml Lecture 4—Shell Scripts]. {{Webarchive|url=https://web.archive.org/web/20240924022340/http://homepage.divms.uiowa.edu/~jones/opsys/notes/04.shtml|date=24 September 2024}}, Spring 2018.
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 [http://linux.die.net/man/3/system system()
], [https://pkg.go.dev/os#StartProcess StartProcess()
], and [http://msdn.microsoft.com/en-us/library/92699yzt.aspx 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.
passthru("/bin/funnytext " . $_GET['USER_INPUT']);
The passthru
function in the above program 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):{{Cite web |url=http://blackhat.life/Command_Injection |title=Command Injection - Black Hat Library |access-date=27 February 2015 |archive-url=https://archive.today/20150227081226/http://blackhat.life/Command_Injection |archive-date=27 February 2015 }}
class="wikitable" |
Shell feature
! ! Resulting shell command ! Explanation |
---|
Sequential execution
| | | Executes |
Pipelines
| | | Sends the output of |
Command substitution
| | | Sends the output of |
Command substitution
| | | Sends the output of |
AND list
| | | Executes |
OR list
| | | Executes |
Output redirection
| | | Overwrites the contents the |
Input redirection
| | | Sends the contents of the |
Some languages offer functions to properly escape or quote strings that are used to construct shell commands:
- PHP:
[http://www.php.net/manual/en/function.escapeshellarg.php escapeshellarg()]
and[http://www.php.net/manual/en/function.escapeshellcmd.php escapeshellcmd()]
- Python:
[https://docs.python.org/3/library/shlex.html#shlex.quote 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.
See also
References
{{Reflist}}
External links
- Tadeusz Pietraszek and Chris Vanden Berghe. "[https://web.archive.org/web/20060301133252/http://chris.vandenberghe.org/publications/csse_raid2005.pdf Defending against Injection Attacks through Context-Sensitive String Evaluation (CSSE)]"
- News article "[https://web.archive.org/web/20050924080540/http://www.emsisoft.com/en/kb/articles/news041104/ Flux] spreads wider—First Trojan horse to make use of code injection to prevent detection from a firewall
- [http://www.thedailywtf.com/ The Daily WTF] regularly reports real-world instances of susceptibility to code injection in software
{{Information security}}
{{DEFAULTSORT:Code Injection}}