Introduction

SQL Injection Attacks occur when malicious code is injected into a SQL query that is executed and allows unauthorized access to data or system resources. When a SQLIA is launched by exploiting a vulnerability in a Web application, the malicious data is inserted via Web page input and becomes part of some SQL query code in the application. The application with the newly injected code is sent to the Web server, and subsequently the query is executed on the back-end database that resides on the Web server or on a database server. The attack is successful if the input is not properly sanitized before being injected into a query or before being executed on the database.

Our approach includes a static server-side approach using testing to find First Order

SQLIVs. We first model the query then evaluate for conditions in which the WHERE

clause(s) of the query could contain a tautology. Thus, it is susceptible to an SQLIA. The first step in modeling the SQL query is breaking down its SQL keywords. A basic query form is

the following: SELECT fieldname-list FROM tablename WHERE (condition1 AND/OR

condition2). In the query’s WHERE clause, a condition contains the comparison describing

(a) desired value(s) of a field in a table within the database. Rows with fields that satisfy the WHERE clause are returned as result of the SQL query. We will consider a simple equality constraints in a condition to explain our method.

In the query SELECT Last Name, First Name FROM User WHERE (Status field = $status), the condition “Status Field = $value” contains $value that may be user sup- plied or dependent upon user-supplied data. If $value can contain a tautology due to user input, then the query is vulnerable to SQLI and the condition Status Field = $value is the vulnerable condition. Sanitization methods may help secure the query from some tautology- based attacks by blocking keywords and escaping special characters. There are some queries susceptible to tautology-based attacks from user input that does not contain keywords or special

characters, but legitimate values that can lead to SQLIA.

It is noted that fields to be returned that are listed after SELECT and tables listed after FROM are of no consequence in the creation of a tautology for the basic query. Only when the query is complex, containing sub-queries can the fieldname-list of the SELECT clause play a role in a tautology. An example is the following: SELECT Last Name, First Name

FROM User WHERE (Username = $username AND 1 < (SELECT COUNT (Lo-

gin Date) FROM Login Log WHERE Username = $username)). Here the query contains a nested sub-query. The result of that sub-query, the returned aggregate function value of the SELECT statement becomes the value of a condition in the WHERE in which it is nested. Thus the SELECT clause is of consequence in the model. Sanitization methods on user input influenced values (here $username) may not prevent a tautology in the condition containing the sub-query.

Our technique addresses the tautology-based attack that sanitization methods can fail to catch. Existing SQLID sanitization techniques are based on syntactic differences due to the insertion of SQL keywords and may check for valid data values. These methods that check for unexpected values and/or SQL keywords will fail to detect a tautology created by appropriate data values. Thus, they are susceptible to both false positives, identifying benign queries as attacks, and false negatives, identifying attacks as benign queries. Our method evaluates the dependencies between conditions in the SQL queries, especially when the query is nested.

Another advantage of our technique is that, we can automatically identify the conditions under which vulnerabilities in the query can be exploited to realize a SQLIA. We refer to these conditions as the causal set. The query inputs, at runtime, can be checked against the causal set; if the check is successful, then the query input is deemed malicious, otherwise, the input is benign.

The causal set gives the following advantages: (a) the conditions in the runtime execution of the SQL query can be verified against the conditions in the causal set and (b) the execution

can be identified to exploit a SQL vulnerability if the conditions in the causal set are satisfied.

The contributions of our approach are summarized as follows:

Contributions

1. We propose a new approach for SQLID that analyzes the semantic dependencies between SQL query conditions and does not rely solely on syntactic structure of the query. 2. Our approach is complementary to the existing techniques for SQLID and leads to an

effective detection mechanism for SQLIVs. Since our technique is based on the semantic dependencies, it does not have any false positive or false negative results.

3. We provide a novel technique to reduce various cases that can lead to SQL injection and automatically combine these cases into a succinct summary. The succinctness allows for easy understanding of the query vulnerability and facilitates efficient monitoring of the user inputs that can lead to exploitation of the vulnerability. We refer to the summary as the causal set.