Project Report

SQL Rand
Nikhil Gupta (2010CS50289) Shantanu Chaudhary (2010CS50295)
Introduction:
This project report has been written as part of final evaluation project for the course on
Systems and Network Security (SIL765). The report covers the various aspects of SQL Rand
which we will be implementing as a proof of concept. The report is divided into various
sections which describe the problem of SQL injection, various methods of SQL injection, SQL
Rand, implementation design, the test cases to evaluate the implementation and finally the
data obtained for interpretation.

SQL Injection:
SQL Injection is a code injection based technique by exploiting vulnerability in input
validation. The basic objective is to fool the database into running code (execute SQL
statements) that will reveal sensitive information or otherwise compromise the server. The
attack is carried out by inserting appropriate SQL statement(s) in an SQL query to change the
structure of the query and achieve desired result. There are two types of SQL attacks:
Tautology
Union
Let us take an example of SQL Injection. Consider the following SQL Query:
select * from mysql.user where username= or 1=1; -- and
password=password(_any_text_);
The above SQL statement is an example of type tautology. The single quotes in the
statement after username= and - -balance the quotes in the query and the double
hyphen comments out the remaining of the query. The result is that the password value of
the field becomes irrelevant and may be sent to any string. As a result, the above statement
executes as a SQL query (tautology) on the database exposing all the information about all
the users in the database table.

SQLRand:
Our project is based on the paper SQLrand: Preventing SQL Injection Attacks, by Stephen
W. Boyd and Angelos D. Keromytis. The idea they introduce is largely based on Instruction
Set randomization as mentioned in Countering Code Injection Attacks with Instruction Set
Randomization, Gaurav, Angelos, and Vassilis. In instruction set randomisation the idea is
to create process specific randomized instruction sets (e.g. machine instructions) of the
system executing potentially vulnerable code. This helps us as the attacker who does not
know the key to the randomization algorithm will inject code that is invalid for that
randomized processor, causing a runtime exception. The architecture of SQLRand extends
the application of randomized instruction set randomization to SQL. So in this approach the
SQL standard keywords are tweaked by appending a random integer (which acts as a key) to
them, one that the attacker cannot easily guess. Now if a malicious user tries to inject his
code into the randomized query, then his injected code that transforms the SQL statement
would actually result in an invalid expression. This is because his inserted syntax would not
be randomized as part of randomizing the standard keywords. As a result when an attempt is
performed at de-randomizing the input query, it is declared invalid and hence, the attack is
thwarted.

SQLRand Architecture:

The above diagram shows how different modules are arranged in the architecture employing
SQLRand. DB Middleware and Proxy form the main modules of SQLRand. The SQL statement
randomisation, de-randomisation and syntax checking takes place in the above mentioned
modules. At the web server side, when the user input arrives, the server sends the SQL query
along with the user input to the database server which passes through the DB Middleware
first. Here the SQL query is randomised (appended with a random key) and is passed to the
proxy along with the user input string. At the proxy, the randomized query is de-randomised
and evaluated by substituting the value of the user input. This complete query is then
checked for validity. If the query is found to be invalid, the proxy flags it and sends the
signal to the server to covey that the query is invalid. If the de-randomised query is valid,
then it is forwarded to the database where it is executed. The result set from the database
is taken and sent to the server for processing of request.
The proxy also handles exceptions from the database server which result from valid queries
that are executed on the database. The functioning of proxy can also be extended to perform
other auxiliary functions. The authors of the paper used Flex and Yacc to implement this
scheme and a sample CGI application was used for the evaluation. It was also required to
maintain a secure communication channel between the proxy and DB middleware as well as
the proxy and Database server in order to prevent potential leaking of information.

Implementation Design:
To give a proof of concept of the idea conveyed by SQLRand, we built modules of SQLRand
(randomiser, de-randomiser, proxy) as part of this project. These modules demonstrate the
operational aspects of SQLRand which is helpful in preventing SQL injection attacks. The aim
of our project is to give a proof of concept and not measure the quantitative of aspects of
SQLRand. The quantitative aspects have already been analysed in the research paper.
Randomiser Module:
Input: List of SQL Reserved Words, Input Query
Output: Randomised Query
The job of the randomiser module is to append a random key (integer) to the reserved SQL
keywords in the input query (list of input queries). The catch here is that the randomisation
of the query is done before substituting the value of user input. Now the value of the user
input from server is substituted in the query (list of queries). Now this query (list of
randomised queries) is (are) then passed to the proxy module for de-randomization and
query evaluation.
De-Randomiser Module:
Input: List of Randomised Queries
Output: Valid queries
The de-randomiser module takes the randomised query (list of queries) from the randomiser
module and performs the following steps for each query:
Let X denote a word from the SQL query, Y denote a word from the set of reserved
keywords of SQL, Z denotes a non-reserved keyword and NK be the randomization key.
For all X in SQL query,
If (X <- Y NK) then separate Y and NK and use Y in the construction of valid query.
Else If (X <- Z) then use Z in the construction of valid query.
Else If (X<- Y) then DECLARE invalid SQL statement
In the algorithm, there are three types of checks that are needed to be performed. If the
selected word from the SQL statement is SQL reserved word appended with an integer then
it is a legitimate word in the randomised query and we use it to construct and complete the
de-randomized query. If the selected word is a general use word (such as some numerical
value, name of method) then we use that word for constructing and completing the valid
query too. Now if we find a word that is a reserved word in SQL and doesnt have a number
appended to it then it means that this word has not been randomised (by the randomiser)
and has been supplied by the user. In such case, the whole SQL query will be marked as
invalid. The query will be dropped and will not be forwarded to the database server. Instead,
the proxy will flag that query and tell the DB Middleware about the invalid SQL query so that
the DB Middleware can forward it further to the user who entered data in the query.

Further Feature Additions:

There can be many extensions to our current implementation. Some of these are as follows:
Establishing reliable protocol of communication between DB Middleware and server
(source of query), DB Middleware and Proxy, and finally Proxy and Database server.
Handle de-randomisation from multiple DB Middlewares and servers.
Handling of exceptions generated by database as a result of some valid query.

Test Cases:
We have supplied three test cases with the project source code in order to test the
implementation. The test can be viewed by running the implementation.