What is (Code) Injection?

According to OWASP, code injection is the most common vulnerability of web applications [1]. As a term, a code injection is a general approach for describing the attack types which are exploited by feeding the applications with invalid data [2]. More specifically, in these type of attacks, the attacker inserts malicious code in the application instead of valid data. After the code injection occurs, the software will execute the malicious code and will perform functionalities that are not supposed to achieve [2]. In most of the cases, a successful code injection can result with disastrous events [2]. Technical impacts of code injection can result in data loss or corruption, lack of accountability or denial of access [3]. As a worst case scenario, code injection can cause complete control takeover of the victim [3]. While, as a business impact of this attack is considered to be theft, modification, and removal of data [3]. Code injection can be applied in many different formats like SQL, Client-Side code (HTML/CSS and JavaScript), Shell, LDAP, File, Object etc. SQL injection will be discussed in more detail in the following subsections. [1] [4]

SQL Injection

SQL Injection is a type of code injection attack that takes place in data-driven applications via SQL statements [5]. This is a case when applications carelessly fully trust the user input [6]. Consequently, the applications are exposed to this type of attack when the developer/s concatenate user input directly with SQL queries without parsing the input for escape characters [6]. Concatenating tainted user input with SQL statements lead to exploitation of this vulnerability since it allows the attacker to specifically craft his own malicious SQL statement [6]. After that, the malicious SQL statement can be used by the attacker to read sensitive data, tamper and destroy data, bypass authentication, execute remote commands and so forth [7].

The escape characters are specific characters which can be interpreted as code instead of simple text value [7]. Usually, attackers start by testing applications if they are vulnerable to SQL injection by giving an input of such escape characters [8]. The most common way of testing is by writing an input of an apostrophe (‘) character, considering that this can break the SQL statement after concatenation [8]. After that, the outcome it is expected to be some sort of error message, coming from the database that is complaining about the query syntax [8]. Besides the expected errors, injected SQL statements also reflect on the output data result [9]. The data output and/or errors can be used for further SQL injection attacks, by allowing the attacker to gather more information for the database each time and improve his injection input [8]. Information that can be extracted from error messages includes a variety of things, including getting the schemas names, table names, attributes, relations, data etc. Anyway, this may not be always the case since many times applications do not show database error messages in user views [8]. Moreover, sometimes the application of any specific business rule, will now show the data either. However, the vulnerability can be still there although the attacker will not get feedback from the database [8]. There are many forms of how an SQL injection may occur. But mainly, SQL Injections can be categorized in four major categories such as [10]:

  • Classic SQL Injections
  • Blind SQL Injections
  • Database Management System (DBMS) Specific SQL Injections
  • Compounded SQL Injections.

Classic SQL injection

A classic SQL injection is the simplest type of this attack. The attack takes place by composing a specific SQL query that will be interpreted as SQL statement instead of text value [9]. The injected SQL will usually cause the application to output database errors or some extracted data conditioned by the injected query. Occasionally, applications will display none of them. [10]

As an example of this attack, we will suppose an authentication form of a blog, with a username and password field, similar to the figure in the right. When this form will get submitted, the following SQL query will be used to validate if there is such a user with the specified username and password.

Authentication Form example

SELECT * FROM users WHERE username='” + usernameVar + “' AND password='” + passwordVar + “' LIMIT 0,1

The input variables “usernameVar” and “passwordVar” are concatenated with SQL query without being sanitized. Functionality wise, the query looks to be acceptable since it is selecting for one user with the specified username and password. But security wise, this query possess a big flaw. The issue is highlighted if the attacker will provide a value of ‘ OR ‘1’=’1 instead of a valid username and password. Therefore, the SQL query will become like the following:

SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR '1'='1' LIMIT 0,1

Now, the query is being tampered with the attackers input by changing the queries conditions. This query will select any user with a blank or whatever username since the OR ‘1’=’1′ part is always true. The same applies for the password condition as well. Basically, the query will return the first user in the Users table since it also contains the limit part at the end. Obviously, by using this query the attacker could bypass authentication and use another valid user identity as its own. Furthermore, the attacker can sophisticate the query by identifying somehow the administrator’s username. Many times, the administrator username is shown publicly, or can be easily guessed [11]. If the attacker has the administrator’s username, it can use it in the username field, and a value of ‘ OR ‘1’=’1 in the password field. Assuming that the administrator’s username is “admin@email.com”, the query would be like this:

SELECT * FROM users WHERE username='admin@email.com' AND password='' OR '1'='1' LIMIT 0,1

This query will select a user with the username of “admin@email.com”, and it will bypass the password condition same as in the earlier case. Hence, in this example except authentication bypass, the attacker also escalates its privileges to the administrator by using his account.

Blind SQL injection

This form of attack is very effective in cases when the applications are not displaying any output either database errors or data in user views. In these conditions, the attacker cannot gain knowledge of database directly. Therefore, the attacker can use this technique of doing SQL injection attacks by “blindly” testing the database with boolean logic (true or false) queries and observing the outcome. Hence, this is called Blind SQL injection. Generally, this type of injection is considered to be more difficult. [12] [13]
In the following example, it will be used a Blind SQL injection attack to check if the application is vulnerable to SQL injections or not [14]. Assuming that there is a blog that displays an article with the specified ID as a URL parameter. The URL to access this specific article would be something like:


And the SQL query to select the article would be like:

SELECT * FROM articles WHERE id=2

In this case, the attacker can inject a query with the intention of returning false, as:

http://myblog.com/article.php?id=2 AND 1=2

In SQL query would look like:

SELECT * FROM articles WHERE id=2 AND 1=2

If the application is vulnerable to SQL injections, it will display nothing. To make sure of that, the attacker can also inject another query that will return true and expect to display the article, as the following:

http://myblog.com/article.php?id=2 AND 1=1

Which would be reflected SQL query like:

SELECT * FROM articles WHERE id=2 AND 1=1

If in the second query the article is displayed, we can conclude that the application is vulnerable to SQL injection. This injection technique can be further refined to construct more sophisticated attacks. The following is another example of Blind SQL injection, which will return true if the MySQL version is 4. Otherwise, the last digit (four in this case) can be changed accordingly until we get the result of true. Whatever number that will cause the application to return true, that would be the exact version number of MySQL database. [14]

http://myblog.com/article.php?id=2 AND 1=1
SELECT * FROM articles WHERE id=2 AND SUBSTRING(@@version,1,1)=4

Database Management System (DBMS) Specific SQL injection

When an SQL injection query successfully exploits an application, does not mean that the same query can work in another vulnerable application. This is due to usages of different DBMSs by different applications. In many cases, DBMS’s implement the same functionality with different SQL statements or have very specific functionalities which can be missing to others. An example of this can note with the timeout functionality. Considering the previous example with Blind SQL injection, we can similarly check if the application is vulnerable to SQL injection by calling a timeout functionality. Then, the timeout should be reflected by making the application delay the result display for a specific amount of time. The following are examples for the timeout functionality injection in different DBMSs. [12] [15]


http://myblog.com/article.php?id=2 AND sleep(10)
SELECT * FROM articles WHERE id=2 AND sleep(10)


http://myblog.com/article.php?id=2 AND WAITFOR DELAY ‘0:0:10


http://myblog.com/article.php?id=2 AND pg_sleep(10)
SELECT * FROM articles WHERE id=2 AND pg_sleep(10)

Compounded SQL injection

This type of SQL injection is relatively new term which represents SQL injection attacks in combination with another type of web application attack [10]. The main combinations of such attacks are [10]:

  • SQL Injection + Insufficient authentication
  • SQL Injection + Distributed Denial of Service (DDoS) attacks
  • SQL Injection + Domain Name System (DNS) hijacking
  • SQL Injection + Cross-Site Scripting (XSS)

As an example of a Compounded SQL injection, we will show an SQL injection in combination with a DDoS attack [8]. All DBMS’s have a default value of maximum database connections they can support at the same time. This sometimes is also overwritten by the applications. If this number is exceeded, the database is expected to continuously respond with an error until the number is decreased within the limited range [10]. Now, assuming to have the same vulnerable blog from previous examples, we can inject a specific SQL query that will try to exceed this number by causing a Distributed Denial of Service (DDoS). Also, assuming that the application is built with ASP.NET technology, in which the default connection pool size will be limited to 100 parallel connections for 30 seconds [16]. In this case, the sleep functionality can be used to exceed the 30 seconds limit. Besides this, attackers can create automated tools to engage more than 100 parallel connections. The connections would be targeted to a URL with SQL like below:

http://myblog.com/article.php?id=2 AND WAITFOR DELAY ‘0:0:50

In this case, the attacker does a DoS attack that was caused by using an SQL injection technique, and therefore, this is called a Compounded SQL injection attack. While this attack takes place, the application will not be accessible to its legitimate users.


[1]OWASP, “Top Ten Most Critical Web Application Security Risks,” 2013. [Online].
Available: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf.
[2]OWASP, “Code Injection,” 31 December 2013. [Online]. Available: https://www.owasp.org/index.php/Code_Injection.
[3]OWASP, “Top 10 -A1 Injection,” 23 June 2013. [Online].
Available: https://www.owasp.org/index.php/Top_10_2013-A1-Injection.
[4]D. Ray and J. Ligatti, “Defining Code-injection Attacks,” Association for Computing Machinery, 2012.
[5]Microsoft, “SQL Injection,” [Online]. Available: https://technet.microsoft.com/en-us/library/ms161953%28v=SQL.105%29.aspx?f=255&MSPPError=-2147217396. [Accessed April 2016].
[6]SANS Institute, “Web Application Injection Vulnerabilities: A Web App’s Security Nemesis,” Information Security Reading Room, 2013.
[7]W. G. Halfond, J. Viegas and A. Orso, “A Classification of SQL Injection Attacks and Prevention Techniques,” IEEE International Symposium on Secure Software Engineering, pp. 12-23, 2006.
[8]OWASP, “Testing for SQL Injection,” 19 March 2016. [Online].
Available: https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005).
[9]OWASP, “SQL Injection,” [Online].
Available: https://www.owasp.org/index.php/SQL_Injection. [Accessed 10 April 2016].
[10]K. Deltchev, “New Web 2.0 Attacks,” May 2012. [Online].
Available: http://www.slideshare.net/test2v/new-web-20-attacks.
[11]D. Perito, C. Castelluccia, M. A. Kaafar and P. Manils, “How Unique and Traceable are Usernames?,” Cryptography and Security, 2011.
[12]OWASP, “Blind SQL Injection,” 26 August 2013. [Online]. Available: https://www.owasp.org/index.php/Blind_SQL_Injection.
[13]Common Attack Pattern Enumeration and Classification, “Blind SQL Injection,” [Online].
Available: https://capec.mitre.org/data/definitions/7.html. [Accessed April 2016].
[14]Exploit Database, “Full SQL Injection Tutorial,” 18 April 2008. [Online].
Available: https://www.exploit-db.com/papers/13045/.
[15]NetSparker, “SQL Injection Cheat Sheet,” 29 March 2016. [Online].
Available: https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/.
[16]Microsoft, “SQL Server Connection Pooling,” [Online]. Available: https://msdn.microsoft.com/en-us/library/8xx3tyca(v=vs.110).aspx. [Accessed April 2016].

Published on: July 12, 2016 10:30 am