SQL Injection is Still Alive:A Study on SQL Injection Signature Evasion Techniques

Amirmohammad Sadeghian, Mazdak Zamani, Suhaimi Ibrahim Advanced Informatics School Universiti Teknologi Malaysia

Kuala Lumpur, Malaysia i@root25.com , mazdak@utm.my , suhaimiibrahim@utm.my

Abstract— SQL injection is one of the biggest challenges for the web application security. Based on the studies by OWASP, SQL injection has the highest rank in the web based vulnerabilities. In case of a successful SQL injection attack, the attacker can have access to the web application database. With the rapid rise of SQL injection based attacks, researchers start to provide different security solutions to protect web application against them. One of the most common solutions is the using of web application firewalls. Usually these firewalls use signature based technique as the main core for the detection. In this technique the firewall checks each packet against a list of predefined SQL injection attacks known as signatures. The problem with this technique is that, an attacker with a good knowledge of SQL language can change the look of the SQL queries in a way that firewall cannot detect them but still they lead to the same malicious results. In this paper first we described the nature of SQL injection attack, then we analyzed current SQL injection detection evasion techniques and how they can bypass the detection filters, afterward we proposed a combination of solutions which helps to mitigate the risk of SQL injection attack.

Keywords- SQL injection; Signature Evasion; IDS; IPS; Firewall; Web Application Security;

I. INTRODUCTION SQL injection is a common type of web application

vulnerability, which exists in applications that suffer from adequate input variable filtering. For exploiting this vulnerability the attacker tries to insert a portion of malicious SQL commands through the variables into the application. Consequently in result the web application will sends these commands to the database server and execute them in additional to the legitimate query [2]. A successful attack can give this ability to the attacker to read, update, delete, insert and execute other SQL commands on the database. The attacker might go further and runs operating system commands and launches other types of attacks on the server.

This attack can directly breach main cores of information security such as confidentiality. In the simplest case, attacker by launching a SQL injection attack and executing a SELECT command on an online shop can read all the credit card information belongs to the customers. The impact of losses to the companies and online business due to the SQL injection attack is very high. This made researches to study

and propose different types of detection and protection techniques for SQL injection. However SQL injection is still alive and still giant online companies becomes the victim of this vulnerability. This is due to the high flexibility of SQL language. Relational database management systems which are powered by SQL give too much power to the developer. However it will also give more opportunity to the attacker to change the appearance of attack to bypass common detection systems. One of these detection techniques is using web based IDS/IPS systems for detecting and dropping requests that contain SQL injection attack. This solution investigates in the HTTP packets and look for the signatures of known attacks. Due to the static nature of these signatures, attacker can evade them by changing the face of the attack [3].

The rest of this paper is organized as follows. Section 2 provides background information about SQL injection following by a motivating example. Section 3 analyze the working process of signature based detection and classify evasion techniques following by examples. Section 4 describes our proposed solution to improve the current detection system. Finally in section 5 further works and conclusion are presented.

II. SQL INJECTION ATTACKS It’s compulsory to know how SQL injection attacks work

to start defeating it. According to Lwin Khin Shar this attack occurs when developer didn’t apply enough restriction on the input parameters in the web application and in result the attacker can insert and run his/her desire query [4]. To put it another way, sometimes because of the lack of training and development experience, the developer might do a mistake in the using of SQL and this will lead to make the web application vulnerable. In the coding phase of dynamic web application, usually developers make dynamic queries by concatenating the SQL statement with variables. These variables are coming from outside of the program and allow the program to make queries dynamically based on the user conditions in runtime.

To exploit SQL Injection vulnerability, attacker must have access to a parameter that web application passes through to the database. By appending the malicious SQL commands into the parameter, the attacker will make the web application to send the malicious query to the database server and execute it. In the Absence of input sanitization the query will be vulnerable to SQL injection attack. These

2013 International Conference on Informatics and Creative Multimedia

978-0-7695-5133-3/13 $26.00 © 2013 IEEE

DOI 10.1109/ICICM.2013.52

260

2013 International Conference on Informatics and Creative Multimedia

978-0-7695-5133-3/13 $26.00 © 2013 IEEE

DOI 10.1109/ICICM.2013.52

266

2013 International Conference on Informatics and Creative Multimedia

978-0-7695-5133-3/13 $26.00 © 2013 IEEE

DOI 10.1109/ICICM.2013.52

266

2013 International Conference on Informatics and Creative Multimedia

978-0-7695-5133-3/13 $26.00 © 2013 IEEE

DOI 10.1109/ICICM.2013.52

266

2013 International Conference on Informatics and Creative Multimedia

978-0-7695-5133-3/13 $26.00 © 2013 IEEE

DOI 10.1109/ICICM.2013.52

260

2013 International Conference on Informatics and Creative Multimedia

978-0-7695-5133-3/13 $26.00 © 2013 IEEE

DOI 10.1109/ICICM.2013.52

265

variables might come inform of a GET request, a POST request, HTTP Cookies or HTTP Headers.

SQL injection attacks can be divided into the three main categories of inband, out-of-band and inferential.

• Inband: The information will be extracted from the same channel that used for the attack which is the simplest method. For example the list of users will appear in the current page.

• Out-of-band: the extracted information is send back to the attacker using another channel such as email.

• Inferential: Also known as Blind injection, which no data send back directly to the attacker. However attacker can reconstruct the data by trying different attack and observe the behavior of the web application [5].

A typical SQL statement looks like this: Select id, name, email from users This statement will select and retrieves the 'id', 'name' and

'email' columns from the 'users' table and return all the rows in the table. The result can be limited to a specific record by using a condition likes below:

Select id, name, email from users where

name = 'Alice' The important fact here is that 'Alice' is located between

two single quotes. We suppose that the variable name is being collected from the user input through a form. Therefore the attacker is able to insert some SQL into the main query by inputting a value like below:

Name: Wen'dy In result the query string becomes like this: Select id, name, email from users where

name = 'Wen'dy' When the database server attempts to execute this query,

it will return the following error and this is due to the fact that the single quote character will break the single quote delimited data in the main query.

Server: Msg 170, Level 15, State 1, Line 1 Line 1: Incorrect syntax near 'dy'. Attacker by observing this information can understand

that the web application is vulnerable to the SQL injection and then he/she will launch the main attack by inputting the following.

Name: Wen'; drop table users— In result of execution of above statement, the single

quote after the 'wen' will close the opened quote in the original query and “drop table” will remove the users table from the database. The two dashes at the end of input will escape any remaining part of query by commenting them.

III. SIGNATURE BASED IDS Signature based Intrusion Detection Systems (IDS)

analyze packets in the network and compares them against a pre-defined list of attack patterns known as signatures [6]. The following example is a sample of an IDS rule. This rule is telling the IDS whenever a packet contains “' or 1=1 --” string, recognize it as a SQL injection attack.

Alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg: “SQL Injection attempt”;

Flow: to_server, established; content: “' or 1=1 --”; nocase; sid: 1; rev:1;)

But still it’s possible to bypass this kind of detection by

using similar terms that are not exist in the pattern list of the IDS and still they have the same true logic.

These are some possible evade for the above example: • http://[site]/news.php?nid=2 or 3=3-- • http://[site]/news.php?nid=2 or 1<3-- • http://[site]/news.php?nid=2 or 7 like 7-- • http://[site]/news.php?nid=2/**/or/**/9/**/=/**/9-- The aim of using evasion techniques is to avoid detection

by changing the appearance of the attacks. SQL injection evasion techniques can be divided into five main following techniques:

A. Encoding Techniques This technique is very straight forward and easy to

bypass the detection with signatures. This is due to the nature of encoding which change the statement in a cryptic way, that it remains hidden to the IDS [7]. Some of the most common encoding techniques that are usually used to bypass the SQL injection detection filter are: URL-Encoding, UTF-8, Hexadecimal Encoding and by use of char() function.

• URL encoding: Also known as percent-encoding is a technique for encoding sequence of octets used in internet protocols [8]. Each octet is encoded by a % sign following by two hexadecimal digits. For example the encoding of “ 5' OR '5'='5 ” will be: %35%27%20%4F%52%20%27%35%27%3D%27%35

• Unicode / UTF-8: Due to the Multilanguage nature of web, it should support different languages and character sets. And SQL is not an exception.

• Hexadecimal encoding: This technique uses base16 numbering system for encoding. For example the encoding for “ 5' OR '5'='5 ” will be: &#x35;&#x27;&#x20;&#x4F;&#x52;&#x20;&#x27;&#x35;&#x27;&#x3D;&#x27;&#x35;

• Char() function: This function get an integer number and return the equal character for the given number. For example Select * from users where name='admin' Can be equal to following statement: Select * from users where name=char(97,100,109,105,110)

B. Whitespacing Techniques Flexibility of SQL with white space is another challenge

for signature based IDSs which let the attacker to manipulate spacing between SQL codes. SQL language let the user to

261267267267261266

omit the spaces between operands and operators. In addition to that user also can use other types of spacing such as carriage return, line feed and tab which are considered as space in most of database management systems [9]. In other word SQL engine ignore spacing.

• Using Different type of spacing: following example is showing that using TAB character will have the same result as a space between commands, however it helps to bypass the IDS filter: 'OR '5'='5' is equal to ' OR '5'='5'

• Omitting spaces: In this technique attacker remove the spaces between SQL commands. For example: 'OR'5'='5' is equal to ' OR '5'='5'

C. Comment Technique Commenting is also another challenge for signature

based IDSs in detecting SQL injection attacks. Commenting techniques almost make it impossible to detect injections. Attacker by using multi line comments which are derived from C language can evade the detection. This type of comment start with “/*” and end with “*/”. SQL will ignore everything in between of these two and in result all surrounding characters will be merged. This technique evades both keyword matching and signature matching [4]. All following statements will have the same result:

UNION/**/SELECT/**/ UN/**/ION/**/SELECT UNION/*Ignored*/SELECT

D. Capitalization Techniques Changing the letter case also can be effective to evade

the IDS detection. This can be done by using upper case or lower case of similar letters in a specific command. However being case sensitive is all depends on the database configuration.

Example: And is equal to aNd. It’s also equal to AND.

E. Variation Techniques Signatures can be evaded with variation on the

comparison logic [7]. In other words anything that can be interpreted in the same logic and has the same true or false result will cause to overall evaluation of the statement remains unchanged. Due to the fact that there are many possibilities for variation, this makes it hard to make signatures for detecting all the variations.

• Concatenation: This is also one of the SQL features that allow the user to have commands in split pieces and join them with concatenate operator. Attacker also can misuse this feature and evade the IDS detection by split and concatenate SQL commands. The syntax of concatenation depends on the database management system. Double pipe “||” will do the concatenation in MySQL. For example: 'SE' || 'LECT is equal to SELECT.

• Variables: Some of the database management engines let the user to declare variable. This feature allows the attacker to split his statement in few units and store them in a variable afterward execute the variable [10]. In following example the “DROP

USER” statement is spitted and putted in varno1 variable and executed: ; declare @varno1 nvarchar(60); set @varno1 = N’DR’ + N’OP US’ + N’ER’); EXEC(@varno1);

• Conversion: In this technique attacker by converting the native data types in the SQL query try to evade the detection system. For example if the % sign is a suspicious sign to the IDS then the attacker will use the char(37), Which return the % sign and can evade the signature detection.

IV. PROPOSED SOLUTION Signature based solution alone is not sufficient to defeat

SQL injection attacks. This is due to the power of SQL and the flexibility that it gives to the user. We can say that there is no single solution which can fight against SQL injection alone. However we believe that a combination of two or more solution can improve the protection against this attack.

In our proposed solution we suggest that the two following methods to be used in parallel:

• Parameterized queries: Using of parameterized queries is a secure technique against SQL injection. This technique also known as prepared statements. Developer need to use this technique in the coding phase. In this technique there are some placeholders in SQL query for the variables. The SQL engine first will parse and compile the query without the variables and keep the result. Afterwards will add the variables and compile it again. In this case even if the attacker inserts a malicious query into the variable, the SQL engine will treat it like an ordinary string.

• Smart Configuration of DBMS: A smart configuration of the database management engine can mitigate the risk of some of these evasion techniques. Defining different users with different privileges and using them in the development process can be really helpful in mitigating the risk of SQL injection attack. In this model we defined four different users and limited their privileges. In Table 1 all the privileges for each user are demonstrated. For instance in this model the developer should use the “viewer_user” in the pages that user functionalities are limited to seeing data which is by using select command. In case an attacker can find vulnerability in this page he will be able to only run select commands and nothing more. However select command still can be a powerful command in hand of an attacker but it can eliminate the risk of deleting data by the attacker.

TABLE I. PROPOSED MODEL’S USER PRIVILAGES TABLE

Username Privileges viewer_user select editor_user Select, insert, update, delete Sturucture_user Create, alter, drop, execute Super_user Shutdown, grant , reload ,

create user

262268268268262267

V. CONCLUSION SQL injection is a serious threat against web

applications, which has a high impact on online business. Until now many different approaches are proposed to defeat SQL injection attack both in coding stage and execution time. Using Intrusion Detection Systems is one of these solutions. Among all types of IDSs, Signature based IDS are more mature and commonly used by network administrators. However due to static nature of signature based IDSs they are not able to detect new types of attack, and simply the attacker can evade the detection by changing the appearance of the attack. In this paper we proved that signature based IDSs are vulnerable to IDS evasion. Consequently we can conclude that using IDSs alone cannot be a sufficient solution to protect the web application against SQL injection. While IDSs are helpful in detecting different types of malicious activities in the network, a combination of good configuration of web server and using parameterized queries in the coding phase can increase the protection against SQL injection attacks.

REFERENCES [1] OWASP, “Open Web Application Security Project. Top ten web

application vulnerabilities”,

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project, (2013).

[2] Antunes, Nuno, and Marco Vieira. “Defending against web application vulnerabilities.” Computer (2012): 66-72.

[3] Brad Warneck, “Defeating SQL Injection IDS Evasion.” SANS Institute Information Security Reading Room (2007) .

[4] Shar, L.K.; Hee Beng Kuan Tan, “Defeating SQL Injection,” Computer , vol.46, no.3, pp.69,77, March 2013.

[5] Focardi, R.; Luccio, F.L.; Squarcina, M., “Fast SQL blind injections in high latency networks,” Satellite Telecommunications (ESTEL), 2012 IEEE First AESS European Conference on , vol., no., pp.1,6, 2-5 Oct. 2012

[6] Amin, S.O.; Siddiqui, M.S.; Choong-seon Hong; Jongwon Choe, "A novel coding scheme to implement signature based IDS in IP based Sensor Networks," Integrated Network Management-Workshops, 2009. IM '09. IFIP/IEEE International Symposium on , vol., no., pp.269,274, 1-5 June 2009 M. Young, The Technical Writer’s Handbook. Mill Valley, CA: University Science, 1989.

[7] Lori Mac Vittie, "SQL Injection Evasion Detection", White Paper-F5 Networks , September 2007 .

[8] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[9] Maor, Ofer, and Amichai Shulman. "SQL injection signatures evasion." Imperva, Inc., Apr (2004).

[10] Anley, Chris. "Advanced SQL injection in SQL server applications." White paper, Next Generation Security Software Ltd (2002).

263269269269263268