Detection Block Model for SQL Injection Attacks

Published Online October 2014 in MECS

SQL Injection Attacks are command-injection attacks where the attacker injects a malicious SQL query into back-end database through web application interface. The back-end database executes the injected SQL statement and sends the corresponding execution results back to the attacker. The attacker could submit malicious SQL commands directly to the back-end database to extract confidential information or even obtain the root privilege of database.

SQL Injection (SQLI) is a wide spread vulnerability commonly found in web-based programs. Exploitations of SQL injection vulnerabilities lead to harmful consequences such as authentication bypassing and leakage of sensitive personal information. It is probably the most common Website vulnerability found today. According to web Cohort report almost 92% of web applications are subjected to some type of attack, among them 60% are SQLIA. Tools such as firewalls and Intrusion Detection Systems (IDSs) are ineffective against SQLIAs, because ports which are open in firewalls for regular web traffic in the application level are used to perform SQLIAs.

Many techniques have been proposed to detect SQLI attacks [15]. These include input character filtering or input validation [2], hybrid encryption [3], randomization of SQL keywords [4], translation and validation [5], statement sequence digest [6], semantic comparison [7], removal of attributes and comparison[8] etc. However, all these approaches do not cover up all known SQL injection attacks and also cannot be implemented across all platforms [17].

Above mentioned approaches do not detect SQLI attacks by measuring complexity of the query. As a result, most of the approaches work well for known malicious inputs and may not detect unknown attacks [14]. Our proposed solution is based on the fact that query with malicious input will change the complexity of the query. Thus, measuring a query complexity statically and observing any deviation at runtime should provide us an indication of the occurrence of an SQLI attack.

This motivation leads us to a technique to detect SQLI based on complexity of query. Information theory is a widely used concept to measure the complexity of real world phenomenon and has been applied to tackle many network security related problems.

In this paper, we present an information-theoretic approach to detect SQLI attacks. Proposed system works both on client and server side. Client side implements a filter program that checks the length and data type of the submitted variables, and detect the injection-sensitive characters and keywords. Client side plays preliminary examination and gives warning. Server side works in two phases – training and detection. Entropy of each query which represents complexity of the query in the application is calculated statically in training phase and again dynamically when query is submitted. Message

Authentication Code (MAC) algorithm is applied on both static and dynamic entropy. A dynamic query with an attack alters its intended structure and hence the entropy level changes significantly which will change the corresponding MAC value. In contrast, a dynamic query with benign inputs does not result in any changes of the MAC value. Attack is detected by comparing MAC values generated statically and dynamically. Change in values signals SQL injection. Existing system works mainly on server side only by including client side we can save on network traffic and can avoid round trips to the server. Simple attacks or a typing mistake by user would be stopped then and there at client side. Proposed system provides additional security by adding MAC in the system which provides integrity and authentication [9]. If an application stores entropy directly then entropy database becomes vulnerable to attack. Our application stores MAC of entropy instead of storing entropy directly which secures the entropy value. Even if the attack is on MAC database, the entropy value cannot be retrieved since the MAC encryption key is not known to the attacker.

The paper is organized as follows: Section II covers background information on SQLIA. In section III related work is discussed. In section IV model’s framework is discussed in detail along with algorithm and its advantages. Section V covers implementation and evaluation. In section VI results are discussed. Section VII draws the conclusions and discusses limitations and future work.

• II.    Background Of SQL Injection Attack

Web-based programs store and retrieve sensitive information from databases by executing SQL queries, which include user supplied inputs that are not sanitized properly before being included in dynamically generated queries. As a result, the intended structures of dynamic queries get altered and provides a loophole for SQL Injection (SQLI) attacks. The consequence of SQLI attacks could be devastating. Altered queries due to SQLI attacks might (i) add, delete or modify data (ii) run additional queries, (iii) insert, update, or delete new tables, and (vi) create or delete arbitrary tables.

• A.    Injection Mechanisms and Intention

An attacker can insert SQL command in to user input field in many different ways like injection through user input, Injection through cookies, Injection through server variables, Second-order injection.

As classified by Halfond et al [11] attacks can be characterized based on the goal, or intent of the attack -Identifying injectable parameters, performing database finger-printing, determining database schema, extracting data, adding or modifying data, performing denial of service, evading detection, bypassing authentication, executing remote commands, and performing privilege escalation.

• B.    Types of SQL injection Attack

This section presents type of SQLIAs known till date. Different types of attacks are not preformed in isolation. To completely attack the system attackers perform attack in sequence depending on the goal of the attack. Attacker can first perform interference or logically incorrect attack for database fingerprinting followed by tautology for bypassing authentication and then piggy backed or any other depending on the attack target.

Attack Intent : Bypassing authentication, identifying injectable parameters, extracting data.

Description : The general goal of a tautology-based attack is to inject code in one or more conditional statements so that they always evaluate to true. The consequences of this attack depend on how the results of the query are used within the application. The most common usages are to bypass authentication pages and extract data. In this type of injection, an attacker exploits an injectable field that is used in a query’s WHERE condition. Transforming the conditional into a tautology causes all of the rows in the database table targeted by the query to be returned.

Attack Intent : Bypassing Authentication, extracting data.

Description : In union-query attacks, an attacker exploits a vulnerable parameter to change the data set returned for a given query. With this technique, an attacker can trick the application into returning data from a table different from the one that was intended by the developer. Attackers do this by injecting a statement of the form: UNION SELECT . Because the attackers completely control the second/injected query, they can use that query to retrieve information from a specified table. The result of this attack is that the database returns a dataset that is the union of the results of the original first query and the results of the injected second query.

Attack Intent : Extracting data, adding or modifying data, performing denial of service, executing remote commands.

Description: In this attack type, an attacker tries to inject additional queries into the original query. We distinguish this type from others because, in this case, attackers are not trying to modify the original intended query; instead, they are trying to include new and distinct queries that “piggy-back” on the original query. As a result, the database receives multiple SQL queries. The first is the intended query which is executed as normal; the subsequent ones are the injected queries, which are executed in addition to the first. This type of attack can be extremely harmful. If successful, attackers can insert virtually any type of SQL command, including stored procedures, into the additional queries and have them executed along with the original query. Vulnerability to this type of attack is often dependent on having a database configuration that allows multiple statements to be contained in a single string.

Attack Intent : Performing privilege escalation, performing denial of service, executing remote commands.

Description : SQLIAs of this type try to execute stored procedures present in the database. Today, most database vendors ship databases with a standard set of stored procedures that extend the functionality of the database and allow for interaction with the operating system. Therefore, once an attacker determines which backend database is in use, SQLIAs can be crafted to execute stored procedures provided by that specific database, including procedures that interact with the operating system. It is a common misconception that using stored procedures to write Web applications renders them invulnerable to SQLIAs. Developers are often surprised to find that their stored procedures can be just as vulnerable to attacks as their normal applications. Additionally, because stored procedures are often written in special scripting languages, they can contain other types of vulnerabilities, such as buffer overflows, that allow attackers to run arbitrary code on the server or escalate their privileges.

Attack Intent : Identifying injectable parameters, extracting data, determining database schema.

Description : In this attack, the query is modified to recast it in the form of an action that is executed based on the answer to a true/- false question about data values in the database. In this type of injection, attackers are generally trying to attack a site that has been secured enough so that, when an injection has succeeded, there is no usable feedback via database error messages [16]. Since database error messages are unavailable to provide the attacker with feedback, attackers must use a different method of obtaining a response from the database. In this situation, the attacker injects commands into the site and then observes how the function/response of the website changes. By carefully noting when the site behaves the same and when its behavior changes, the attacker can deduce not only whether certain parameters are vulnerable, but also additional information about the values in the database. There are two well known attack techniques that are based on inference. They allow an attacker to extract data from a database and detect vulnerable parameters.

Blind Injection: In this technique, the information must be inferred from the behavior of the page by asking the server true/- false questions. If the injected statement evaluates to true, the site continues to function normally. If the statement evaluates to false, although there is no descriptive error message, the page differs significantly from the normally-functioning page.

Timing Attacks : A timing attack allows an attacker to gain information from a database by observing timing delays in the response of the database. This attack is very similar to blind injection, but uses a different method of inference. To perform a timing attack, attackers structure their injected query in the form of an if/then statement, whose branch predicate corresponds to an unknown about the contents of the database. Along one of the branches, the attacker uses a SQL construct that takes a known amount of time to execute, (e.g. the WAITFOR keyword, which causes the database to delay its response by a specified time). By measuring the increase or decrease in response time of the database, the attacker can infer which branch was taken in his injection and therefore the answer to the injected question.

Attack Intent : Evading detection.

Description : In this attack, the injected text is modified so as to avoid detection by defensive coding practices and also many automated prevention techniques. This attack type is used in conjunction with other attacks. In other words, alternate encodings do not provide any unique way to attack an application; they are simply an enabling technique that allows attackers to evade detection and prevention techniques and exploit vulnerabilities that might not otherwise be exploitable. These evasion techniques are often necessary because a common defensive coding practice is to scan for certain known “bad characters,” such as single quotes and comment operators.

To evade this defense, attackers have employed alternate methods of encoding their attack strings (e.g., using hexadecimal, ASCII, and Unicode character encoding). Common scanning and detection techniques do not try to evaluate all specially encoded strings, thus allowing these attacks to go undetected. Contributing to the problem is that different layers in an application have different ways of handling alternate encodings. The application may scan for certain types of escape characters that represent alternate encodings in its language domain. Another layer (e.g., the database) may use different escape characters or even completely different ways of encoding. For example, a database could use the expression char (120) to represent an alternately-encoded character “x”, but char(120) has no special meaning in the application language’s context. An effective code-based defense against alternate encodings is difficult to implement in practice because it requires developers to consider of all of the possible encodings that could affect a given query string as it passes through the different application layers. Therefore, attackers have been very successful in using alternate encodings to conceal their attack strings.

• III.    Related Work

The authors in [1] propose a system based on information theory. It measures query’s entropy statically using token probability distribution of a query. During execution compute the complexity to identify any changes in entropy measured earlier. Dynamic query with attack inputs alters its intended structure and hence the entropy level changes. Based on a summing up report authors in [2] check for special characters in the submitted query. If a restricted character is found query is blocked else query is executed. Proposed method in [3] is an authentication scheme using hybrid encryption. Query generated by using encrypted user name and password is encrypted by applying RSA. In verification query is decrypted using server’s private key and username and password are verified. Finally decrypted user name and password are checked. Proposed scheme in [4] is based on randomization and is used to convert the input into a cipher text. Each input character is given one of four random values from a sample lookup table. Based on the next input character, one of these four values is substituted for a given character. Encrypted values are checked with database. The method proposed by the authors in [5] is based on translation and validation. It retrieves information from SQL database to produce a corresponding LDAP database. Authors in [6] implement a technique which is based on statement sequence digest (SSD). SSD is a profile of SQL statement which can be calculated using MD5, SHA etc. algorithms.

SQL injection attack is detected by comparing SSD calculated statically and dynamically. Proposed scheme in [7] is based on semantic comparison. The semantic comparison is done by comparing the syntax tree structure of a query. If the syntax trees at training and run time are equivalent then the queries are inducing equivalent semantic actions and query is a safe query else attack is detected. Authors in [8] propose a simple method that removes attributes from SQL query. Author then takes XOR of static and dynamic queries. If result of XORing is zero there is no attack otherwise attack is detected.

• IV.    Information Theory Based Framework For SQL Injection Attack Detection

We have implemented a Detection Block model for SQL injection attack detection. Our model conducts two checks both on the Client Side and Server Side.

• A.    Client

According to a summing-up report [2], the sensitive characters/keywords of the SQL injection attack include: "exec", "xp_", "sp_", "declare", "Union ","+","//",".."," ;","'","-- ","%"," 0x ", which are not expected in the general structure query statement. A filter function is set to filter these characters before the parameters are uploaded in the query. Client side implements a filter program that checks the length and data type of the submitted variables and detect the injection-sensitive characters and keywords. Figure 1 illustrates the client side framework. Client side plays preliminary examination and gives warning since all the people who have submitted the illegal characters could be SQL injection attackers. However, considering that the illegal characters may be submitted by user due to typing mistake, for which the check on the Client Side only gives a friendly error message and suspends submission. When user submits a request first it is checked for size if size is less than the specified maximum size then it is checked for any forbidden special characters.

Fig. 1. Client side framework

If it passes both the tests request is submitted to server, else an error message is displayed and request is not submitted to server .

Client side does not provide solution to all the attacks, but provides basic security to prevent simple attacks. It is also helpful in decreasing network traffic. Advantage of client side is that it reduces CPU cycles since it avoids a number of round trips to the server. Limitations of client side are firstly limiting the size of input and restricting the use of special characters cannot be imposed on user in all applications. Secondly the protection provided by client side scripts can be easily bypassed, hence server side is required for complete security.

• B.    Server

On server side we implement entropy computational model which measures the complexity of a given query. Entropy is defined as the expected value of the information contained in a message. It is an indicator of the complexity of the query written by a programmer.

Server side works in two phases training and detection phase. In training phase we identify static SQL queries present in the program. Entropy of each query is calculated which is based on complexity of the query. Entropy is derived from probability distribution of tokens present in the query [1]. Next we apply MAC on entropy calculated from first step. Application of MAC enhances the security by safeguarding the entropy value. Value of MAC calculated here is stored in a database.

Detection phase begins with a database query invocation. When a request is submitted a dynamic SQL query is invoked. The generated dynamic query is analysed to compute the entropy and MAC is applied on calculated entropy. The approach then relies on the principle that dynamic queries with attack alter its intended structure and hence the entropy level changes significantly which will change the corresponding MAC. In contrast, a dynamic query with benign inputs does not result in any change of entropy value and thus MAC remains unchanged. Thus by comparing MAC calculated before program deployment and MAC calculated after query invocation will detect attack. Conversely, a change in value of MAC signals that entropy has changed. Entropy will change only if tokens probability distribution has changed, which implies that a SQL injection attack has taken place. The advantage of this approach is that it can detect unknown vulnerabilities because it is not based on any particular attack input.

Figure 2 illustrates server side framework. Functionality of each module in server side framework is explained below:

Fig. 2. Server Side Framework

Program Source code and Server Script Analyzer

During training phase first program source code is analyzed to find all static queries in the application.

Static Entropy Calculator

After all the queries are revealed entropy of each query is calculated which is based on probability distribution of tokens present in the query. Entropy is the average amount of information required to represent queries in the application and represents a query’s complexity. This entropy should remain intact and any alteration indicates the presence of malicious inputs.

The entropy (denoted as H) [2] of all the queries present in the program can be computed as follows:

Q= {q1 ,q2 ,q3……………qn}be set of queries in the application

P(x) probability of a token x in query q

Entropy of the query[13] is represented by:

n

H(q) = H(x, x2, x3,..........................,x„) = £ P(x) * log P(x)

= i

Entropy calculated here in training phase is represented as Static entropy.

MAC

A message authentication code (MAC) is a cryptographic checksum on data that uses a session key to detect modifications of the data. It is a small fixed-size block of data that is generated based on a message M of variable length using secret key K[9] as follows:

MAC = C (K, M)

Applying MAC on entropy provides us authentication and integrity. MAC is applied on entropy calculated from previous step. If entropy is stored in database there is a possibility of attack on entropy database, which if attacked can compromise the entire security. By applying MAC on entropy we are enhancing the security. If attacker attacks MAC database then also entropy can’t be revealed from it because key is not known to attacker.

Proposed model implements MAC as follows:

• 1.    Retrieve static entropy (E) from entropy calculator.

• 2.    Retrieve key (K) form key database.

• 3.    Take hash of entropy and key, we get static MAC.

MAC (K, E) = H ((K ∥ E)

Static MAC (represented as SMAC) calculated here is stored in database to be compared later.

Query Invocat on

The detection phase begins when a query is fired for the application. At runtime when query is invoked necessary elements are calculated as stated below.

Dynam c Entropy Calculator

It works in the same manner as static entropy calculator. The entropy calculated here is represented as dynamic entropy.

MAC

It works in the same manner as MAC in training phase. MAC calculated over here is represented as dynamic MAC (DMAC).

Compar son

Ideally, the MAC of the dynamic query should match with the pre-recorded MAC in the database learned from the training phase i.e. SMAC. Static MAC and dynamic MAC are compared here. If SMAC is same as DMAC there is no injection and query is genuine. If DMAC is not equal to SMAC that means query is modified, SQL injection is detected.

Execute

If SMAC and DMAC are same submitted query is genuine and request is submitted to server. Query is allowed to execute and result is returned to the sender.

Block

If DMAC and SMAC are not same, SQL injection is detected. The query is blocked i.e. not executed and an entry is made in blocked ip’s table in database. For this danger signal, the server will record the IP address into a database for future reference, and will transfer the request to a error message page. Blocking of ip address will not allow any input from that ip address in future.

Key generation and storage

This module will generate a random key every time. Generated random key is stored in database. Key value will be fetched from here for MAC calculation.

• C.    Algorithm

Client side:

• •    Input text

• •    Check for length of input submitted

• •    Check for injection sensitive characters and

• •    If found sensitive character is found or size

greater than specified return error message.

• •    Else submit query to server.

Server side:

• •    Analyze program source code to find all queries.

• •    For all queries in application calculate entropy which is called static entropy.

• •    Apply MAC (Message authentication code) on static query we get static MAC (SMAC).

• •    SMAC is stored in db.

• •    At Runtime when query is invoked. Dynamic entropy is calculated.

• •    Apply MAC (Message authentication code) on dynamic entropy we get dynamic MAC (DMAC).

• •    Compare DMAC and SMAC.

• •    If they are equal query is genuine.

• •    Else attack is detected, query is not executed. ip address is blocked and recorded.

• D.    Advantages

Proposed scheme has various advantages as enlisted below.

• •    Client side reduces CPU cycles since it avoids a number of round trips to the server.

• •    Can detect all known SQLI attacks.

• •    Reveals several unknown vulnerabilities.

• •    Does not rely on the specific type of attack inputs.

• •    Does not require tainted data flow analysis or complex static analysis.

• •    Can be applied for a wide variety of scripting languages

• •    Application of MAC provide additional layer of security.

• V.    Implementataion And Evaluation

We implement a detection tool for testing SQLI. The tool accepts .net files and detects attack both on client and server side. Client side implements a java script file which filters all SQL injection sensitive characters based on a summing up report which specifying all SQL injection sensitive characters. Server side computes entropy for each queries present in a program. The entropy information is instrumented in program code and compared during actual program execution time. We use split function in .net for parsing and to count the tokens in a query.

We perform the evaluation in the following two steps.

Client side: Checks for all SQL injection sensitive characters.

Server side: First, we identify SQL queries in each web page. Then, we compute the entropy of the queries apply MAC on entropy and store the MAC in database. In the second stage, we run the programs by deploying them in a web server.

Then, we visit the corresponding pages and supply malicious inputs in the input field of web application. We notice the instrumented code with entropy information successfully stops the malicious query execution and logs a warning.

• VI.    Experimental Result

For testing our application we have considered all types of SQL injection attack. Response time for detection is very fast. Table 1 illustrates type of SQL injection attacks which are detected, blocked and ip address of attacker is logged in database. In our testing, we notice client side can detect various attacks. Attack input is not submitted to server and is stopped at client side itself.

Table 1. Result for All Type of Attacks

Attack Type	Detected	Blocked	Logged
Tautology	Yes	Yes	Yes
Piggybacked	Yes	Yes	Yes
Union	Yes	Yes	Yes
Alternate encoding	Yes	Yes	Yes
Illegal query	Yes	Yes	Yes
Blind	Yes	Yes	Yes
Timing	Yes	Yes	Yes

Table 2 illustrates result attained from client side for different attack input. All the malicious query inputs have been blocked by the framework. Thus, the false negative rate in our evaluation is zero. But we understand client side scripting can be easily bypassed. In our model if an attacker bypasses client side filter attack will be detected and blocked at server side.

Table 2. Results from client side

Attack	Input	Result	Detected
Piggy backed	Admin; select * from table	; is not valid	Detected
Tautolog y	‘ or 1=1--;	= is not valid.	Detected
Alternate encoding	exec(char(0x73687574646 f776e))--	exec is not valid	Detected
Union query	‘;union select usr from test--	select is not valid.	Detected
Illegal /incorrect	convert (int,(select usr from test where usr =’u’))	Convert is not valid	Detected
Blind	admin; or 1=1--; admin ; or 1=2--;	= is not valid.	Detected

At server side all types of SQL injection attacks are detected, blocked and their ip addresses are stored in database for future reference. Table 3 illustrates result from server side. When an attack takes place it is detected, that attack input is not executed and the ip address of attacker is stored in database and is blocked. Table 3 shows result from server side for different attack type. Blocking of ip address will not allow any input from that ip address in future.

Table 3. Result from Server Side (D-Detected, B-Blocked, L-Logged)

Attack Type	Input 1	Input2	Result
Piggy backed	Admin; select * from table --;	Drop database Diksha --;	D.B.L
Tautol ogy	‘ or 1=1--;	‘ or a=a--;	D.B.L
Alterna te encodi ng	exec(char(0x7368757 4646f776e))--	exec(char(0x579757 578889341e))--	D.B.L
Union query	‘;union select usr from test--	‘; union select entropy from blocked_entropy	D.B.L
Illegal /incorr ect	convert (int,(select usr from test where usr =’u’))	convert(int,(select usr from test))	D.B.L
Blind	admin; or 1=1--; admin ; or 1=2--;	‘ or 2=2--; ‘ or 2=3--;	D.B.L
Timing	‘ and ASCII (SUBSTRING ((select top 1 name from test),1,1)) > X WAITFOR 5 --	‘ and ASCII (SUBSTRING((sele ct top 1 name from bl_entropy),1,1)) > X WAITFOR 10 --	D.B.L

Results obtained are explained below:

Attack type: Piggy backed, Tautology, Alternate Encoding, Union query, Timing Attack

Since Piggy backed, Tautology, Union query, Alternate encoding all require addition of extra key words as shown in table 1, because of addition of new keywords probability distribution of token are changed. Hence entropy changes and corresponding MAC value also changes therefore attack is detected.

Attack type: Illegal /Logically Incorrect, Blind

In this category of attack attacker intentionally gives incorrect input to gain information from error message returned from the SQL server. In our approach if malicious input is found then the input is not submitted to the SQL server. In this case error message is retuned at detection phase not form SQL server , which is a simple error message and does not reveals any information of the database.

• VII.    Conclusion

SQL injection is defined as one of the most serious and common web security threat that needs attention to provide secure web applications. Exploitations of SQLI vulnerabilities result in compromise of database, which is a valuable asset of an organization. Thus, SQLI mitigation needs to be considered seriously. Our model applies concept of information theory for attack detection. Entropy is defined as information content of a query written by a programmer which should remain intact. When a malicious input alters the static nature of the query, the complexity value changes. We apply MAC on entropy; we compare the statically computed MAC with that of dynamically computed MAC. The deviation indicates the presence of SQLI in a query. The prevention and block model of SQL injection attack mentioned in this paper checks the legality based on the information submitted, conducts two checks both on the Client Side and Server Side, and as long as any of the two checks does not pass, the information submitted will not be executed at the server.

Future Scope

Currently, our approach does not address the SQLI in stored procedures as it requires our approach to be extended at the database script level. Our future work includes extending the model to stored procedures. We also plan to apply our developed model for detecting other web-based attacks such as cross-site scripting.

Acknowledgement

Our thanks to the experts who have contributed towards study of the SQL injection. We sincerely thank our colleagues and friends.