Sunteți pe pagina 1din 5

International Journal of Computer Trends and Technology (IJCTT) - volume4Issue4 April 2013

SQLi Blocker
Aditi Navghane#1, Monika Suryawanshi#2
Student of Department of Information Technology, Pune University Pimpri Chinchwad College of Engineering. Sector-26, Pradhikaran Nigdi, Pune-44 #2 Student of Department of Information Technology, Pune University Pimpri Chinchwad College of Engineering. Sector-26, Pradhikaran Nigdi, Pune-44
#1

Abstract This paper SQLi Blocker(SQL Injection Blocker) presents the idea of blocking an SQL injection attack by using different agents at different layers each one works to block the SQL injection. For avoiding this SQL injection ANN is also used thus provides a higher accuracy and lower false alarms of attack. The Client who sends the query with an intent to inject the database is can also trapped by getting the IP of the machine through which Query was send Keywords SQL Injection, Case Based Reasoning, Intrusion Detection, Neural Network.

I. INTRODUCTION SQL Injection is one of the most serious attack to the security of the backend i.e the Database where the very vital data of all the organization be small or large are stored if leaked or injected can cause a serious problem. In SQL Injection the Intruder sends a query which is injected thus even if the user is not having a authority to execute the query it is executed at the server side. Thus to avoid this type of injection this paper we introduce a strategy to avoid this sql injection and check each query passed before execution. Application of this project is Protection from IT Sabotage, Server control in college, Business Confidentiality. A. Types of SQLi Basically there are 4 Queries through which SQL injection can be perfomed: Tautology Union Queries: Piggy Backed Queries Illegal/Logically Incorrect Queries 1) Tautology: Purpose: 1. bypass authentication 2. identify injectable parameters 3. extract data Goal The basic aim of a tautology based query attack is to inject code in one or more conditional statements so that they always result to a value as true. The impact of this Tautology based attack largely depend on how the results of the query are used

in the application. The very common use of this tautology based attack is to bypass authentication pages so that the password and the username is not required and extract data that is required. In tautology type of injection attack, an intruder infects an vulnerable field that is used in a querys WHERE clause. Tautology causes all of the rows in the database table targeted by the injected query to be returned as the result. In general, for a tautology based query attack to work, an intruder must consider not only the injectable or vulnerable parameters of the table, but also the coding constructs that execute the query results. Basically, the Tautology attack result is successful when the code either displays all of the returned records or performs some action if at least one record is returned. Example SELECT 1234 accounts FROM1234 users WHERE 1234 login= OR 1=1 - - AND1234 pass= AND 1234 pin= ; The execution of Query is carried out when output the given condition is true. In this example, an attacker has injected a conditional (OR 1=1) that transforms the entire WHERE clause into a tautology and so every row in the users table will be returned. Regular Expression formed Tautology regular expression [12] (sELECT|select) [a-zAZ]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]* [=] '' or 1=1 -- (AND|and) [a-zA-Z]* [=] '' (AND|and) [a-zA-Z]* [=] '' 2)Union: Purpose: 1. 2.
Goal

Bypassing Authentication, extracting data.

In union query Injection attacks, an intruder injects a vulnerable parameter in the query to change the data set returned for a given query. In this Union Query technique, an intruder can hamper the application into returning data from a table different from the one that was expected by the developer. Intruders do this by injecting a statement or a clause of the form: UNION SELECT <rest of injected query>. As the intruder has a complete control of the second or the injected query, intruder can use that second query to get information from a table that is specified in the query. The result set of this Union based query attack is that the union of the 2 queries given where whatever be the result of the 1st

ISSN: 2231-2803

http://www.ijcttjournal.org

Page 589

International Journal of Computer Trends and Technology (IJCTT) - volume4Issue4 April 2013
query it does not matter the execution of the second and even if 1st returns as NULL still second will be executed Example: SELECT accounts FROM users WHERE login = UNION SELECT cardno FROM creditcards WHERE accountno=5050 - - AND pass = AND pin=; The first Query returns NULL result and followed Query returns data from creditcards table if the given account no. exists. The outcome of this attack is that database returns a dataset that is union of results of original query with the results of injected query. Regular Expression formed Union query regular expression [12] (sELECT|select) [azA-Z]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]* [=] '' (UNION|union) [SELECT|select] [a-zA-Z]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]* [=] [09]* -- (and|AND) [a-zA-Z]* [=] '' (and|AND) [a-zA-Z]* [=] '' 3) Piggy Backed Queries: Purpose: 1. extract data 2. add or modify data 3. perform denial of service 4. execute remote commands Goal: In Piggy Backed Queries attack type, an Intruder tries to inject some additional queries into the early query. The Piggy Backed Query is differentiated from the other type of injection attacks because, in this case of injection attack, intruder here does not modify the original non injected query on the contrary he tries to include a new query that is piggy backed on the early or the original query. Thus this result as the database receives many SQL Queries. The first or the original query executes normally whereas the subsequent or the rest of the queries that are injected they are also injected along with the first one. Piggy Backed type of query attack can be extensively harmful. And if in case this attack is successful, intruder can add virtually any type of SQL command or clauses added to the original one, including stored procedures, one into the additional query and have them executed along with the early query. Vulnerability to Piggy backed type of attack is often dependent on having a database configuration that allows multiple SQL query statements to be contained all in a single string. Example The example is as follows: SELECT products FROM customers WHERE login=ria AND pass = ; DROP TABLE customers ; - - AND pin = 1991; The database sees the above query and treats it as 2 separate queries as there is a delimiter ; present between the both. The first query will execute normally whereas the second is malicious one where a drop command is present and thus result a table from the database to be dropped. Thus this piggy backed query i.e. drop is added to the original select query Regular Expression Formed: Piggy backed query regular expression [12] (SELECT|select) [a-zA-Z]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]* [=] [a-zA-Z]* (and|AND) [a-zAZ]* [=] '' 4) Illegal/Logically Incorrect Queries: Purpose: 1. 2. 3. Goal: The Illegal or Logically Incorrect Query attack allows an intruder collect important information regarding the data type or the structure of the database of an application. The Illegal or Logically Incorrect queries attack is considered a first stage, of information collection step for other type attacks. The vulnerability that is posed by this attack is that the query when executed results to an error page which result to some error that gives the intruder an hint regarding some intact details of the database or the table in it. The error information that is returned from the query this intend to help the intruder thus helps him or her to get the information from the database its schema and so on. When the intruder is performing this attack he tries to inject the statement or the clause that causes a syntax error, a type conversion error where the intruder gets an idea what could be the type of the required field, and logical error also can be returned this could reveal the important tables, columns or other that is present in the error Example This example of Illegal/Logically Incorrect attacks main aim is to cause a type conversion error that can reveal relevant data thus can give an hint to the intruder regarding what the type of the required field would be. Thus to perform this type of attack, the intruder injects the following text into input field pin: convert(int,(select top 1 name from sysobjects where xtype=u)). The result of the query that should return an error is: SELECT accounts FROM usertable WHERE loginname= AND password= AND pinnumber= convert (int,(select top 1 name from sysobjects where xtype=u)) In the Illegal/Logically Incorrect attack string, the injected select query attempts to extract the first user table (xtype=u) from the databases metadata table (Let us assume that the application is using Microsoft SQL Server, for which the metadata table is named as sysobjects). As this query tries to convert the table name to integer type and this is not a valid way to this thus this will obviously return an error. This error would be as: Microsoft OLEDB Provider for SQL Server (0x80040E07) Error converting nvarchar value CreditCardsTable to a column of data type int. Thus this error message shows 2 hints to an intruder first are as the Identifying injectable parameters performing database finger-printing extracting data.

ISSN: 2231-2803

http://www.ijcttjournal.org

Page 590

International Journal of Computer Trends and Technology (IJCTT) - volume4Issue4 April 2013
database is an SQL Server Database and the Second shows the typed conversion error. Here it also shows the database name as CreditCardsTable Thus Intruder can use the similar strategy t get the names of the fields from the table in the database. Regular Expression formed: Illegal or Logically Incorrect Query regular expression[12] (SELECT|select) [a-zA-Z]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]* [=] '' (and|AND) [a-zA-Z]* [=] '' (and|AND) [a-zA-Z]* [=] [a-zA-Z]* [(][a-zAZ]*[,][(](SELECT|select) [a-zA-Z]* [a-zA-Z]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]*[=]'u'[)][)] 6. b. c. If query is found to be legal it is executed and result is send to the client. Else if the query is found to be illegal or unknown then the query is send for further verification

If the query is found to be illegal or unknown it is checked for the injected queries this is done by checking the severity of attack in the query. This is checked in few steps: a. b. The 11 fields of the input query is calculated to get the severity of the query. The already present 12 fields in the table are compared with the currently calculated 11 fields of the input query. Thus forming 2 vectors new case vector of the current input query and the Similar case vector of the all cases found to have fields similar with that of the input query. Later these 2 vectors are given to ANN for getting more precise value to identify whether it is an attack or non attack Once the query category is found as attack or non attack it is updated in c12th field of the input query and updated in the database table. Thus this can also avoid the 0 day attack problem

II. PROPOSED SYSTEM In this paper the proposed system is not only block injected query but also detect zero day attack. For detecting zero day attack we are using MLP(A multilayer perceptron). As in the architecture given below, after providing the input query it is checked for valid syntax.if syntax is valid query is compared with existing attacks if similar type of SQL query found the query is blocked.Else it is given to CBR(Case Based Reasoning).CBR uses MLP function to detect attack in unknown queries. If query is found to be injected ,query is blocked else result is shown to user. B. Proposed Algorithm 1. 2. 3. 4. The Input SQL Query is send by the client to the Server. At the Server Side the Query is first received by the SQLi Blocker The Query is send by SQLi Blocker to Syntax Checker The SQLi Blockers Syntax Checker checks the Syntax of the query send by the client a. If the Syntax is Valid i. The Query is send for further verification. b. If the Syntax is Invalid i. The Query is Blocked there itself and is not executed. 5. After the syntax Checker performs its task and the syntax is found to be valid it is checked in the database table for similar queries. a. The Query if found in the database table it can be i. Legal ii. Illegal 7.

c.

d.

e.

Finally we can identify the illegal and suspicious query and correspondingly block them.

III. IMPLEMENTATION DETAILS Strategy used by SQLi Blocker is 1. Check the syntax of the query 2. Checking Database for the Similar Queries 3. Case based Reasoning

ISSN: 2231-2803

http://www.ijcttjournal.org

Page 591

International Journal of Computer Trends and Technology (IJCTT) - volume4Issue4 April 2013
C. Case Based Reasoning This can be used to avoid 0 day attack problem in SQLi Blocker. Case Based Reasoning can be done in 4 simple steps: In case Based Reasoning we maintain a case table where there are fields which are used to identify severity of the query. The fields are like: How many fields are affected, how many tables are affected, number of group by clauses, number of having clauses etc these are 12 fields
TABLE I C1-C12 FIELDS AND THEIR RETURN TYPE

Fields Affected_table Affected_field Command_type Word_GroupBy


Fig1: SQLi Blocker Strategy

Return Type Integer Integer Integer Boolean Boolean Integer Integer Integer Integer Time Time Integer

Word_Having Word_OrderBy

A. Syntax Checking The Basic aim of Syntax Checking is to check the SQL query syntax if syntax is correct allow the query and send it to next module else block it. One can use an inbuilt parser to do so e.g. TGSqlParser which provides the facility to check the SQL query syntax line by line and if the syntax is not correct it returns a non zero value else it returns a value equal to zero thus one can identify whether the send sql syntax is correct and should it be passed for execution or not. B. Checking Database for similar Queries Title If the query is found to be syntactically correct at the syntax checking phase it further checked with the previously identified attacks. This can be done by keeping a set of identified attacks in the database in form of regular expression thus be any form if the regular expression of the input sql query matches with the one in the identified attack regular expression then it can be a form of attack this can be known or illegal type To check the input SQL query with the one in the regular expression in the database the we can use the pattern matching technique by using the java.util.regex.Matcher and java.util.regex.Pattern Sample regular expressions: 1. (select|SELECT) [*] (from|FROM) [a-zA-Z]* for legal query here in this case related to select query 2. A sample regular expression for an illegal query[12](SELECT|select) [a-zA-Z]* (FROM|from) [a-zA-Z]* (WHERE|where) [a-zA-Z]* [=] '' or 1=1 -(AND|and) [a-zA-Z]* [=] '' (AND|and) [a-zA-Z]* [=] ''

Number_And Number_Or Number_literals Start_Time_Execution End_Time_Execution Query_Category

The 12th Field is updated only at the last step after evaluation at the step1 to step3

Step 1:

Fig 2: Step1 Block Diagram

Here in this step the C1 to C11 fields are evaluated and the result is taken and stored to the database

ISSN: 2231-2803

http://www.ijcttjournal.org

Page 592

International Journal of Computer Trends and Technology (IJCTT) - volume4Issue4 April 2013
After the fields are evaluated a vector of it can be created named as New Case This can be compared with the cases already in the database and a new vector named similar case can be created. Step 2: V. FUTURE SCOPE We can use this S/W to protect data from attacks in a large organization, or Institutions which need security. The Cross Site Scripting and many such attacks can be blocked. We can use this S/W to support Web-Applications security. We can have more than one servers in a large organization depending on the network size to help to achieve better security. VI. CONCLUSIONS We have developed a SQL Injection Blocker which helps in blocking the Queries which inject the Database Server and also get the Entire Information regarding who is sending the Injected Queries. This is done by Tracking the IP Adress. The Attack Count till date can also be checked to get the analysis of Suspicious Queries. REFERENCES
[1] William G.J. Halfond, Jeremy, Viegas, and Alessandro Orso . A
Classification of SQL Injection Attacks and Countermeasures.

Fig 3: Step 2 Block Diagram

The 2 vectors created at step 1 is given as input to step 2 then the closest match of the new case with the similar case is calculated this can be done using Artificial Neural Network. The Input to the Artificial Neural Network are New Case and the Similar Case both of which are vectors this are taken and output is taken as 0.2 or 0.8[11]. Step 3:

[2] Cristian Pinzon,Yanira De Paz, and Rosa Cano. 2011. Classification


Fig 4: Step 3 Block Diagram Agent-Based Techniques for Detecting Intrusions in Databases

Here in this stage the Query Category of the SQL String is retrieved depending on the output of ANN which is Non Attack represented as 0.2 and Attack represented as 0.8. Accordingly the 12th field is updated. Step 4: All the 12 fields once obtained they are stored in the database so that they can be used later for further query checking. This also can be a solution to avoid 0 day attack D. Blocking suspicious queries The Last step is to block the Suspicious queries by query category obtained.

[3] Cristian Pinzon, Yanira de Paz, Rosa Cano, and Manuel P. Rubio. 2009.
An Attack Detection Mechanism Based on a Distributed Hierarchical Multi-agent Architecture for Protecting Databases

[4] Debasish Das, Utpal Sharma and D. K. Bhattacharyya. 2012. Rule based
Detection of SQL Injection Attack

[5] Romil Rawat, Chandrapal Singh Dangi and Jagdish Patil. 2011. Safe
Guard Anomalies against SQL Injection Attacks

[6] Devata Anekar. 2012. SIDP-SQL Injection Detector and Preventer [7] www.acunetix.com/websitesecurity/sql-injection/ [8] en.wikipedia.org/wiki/SQL_injection [9] https://www.owasp.org/index.php/SQL_Injection. [10] http://www.sqlinjectionwiki.com/Categories.aspx?catId=2 [11] Cristian I. Pinzn , Juan F. De Paz , lvaro Herrero , Emilio Corchado ,
Javier Bajo , Juan M. Corchado. 2011. idMAS-SQL: Intrusion Detection based on MAS to Detect and Block SQL injection through data mining.

IV. BENEFITS OF SQLI BLOCKER As we are keeping track of ip address administrator can get complete idea of who is trying to access the system. Quick action is tacken against illegal queries. It is possible to control unauthorized access from any location in an organistion within a LAN. This system provides security against zero day attack.

[12] http://www.regular-expressions.info/java.html

ISSN: 2231-2803

http://www.ijcttjournal.org

Page 593

S-ar putea să vă placă și