Prevention of SQL Injection Attack

Using Query Transformation and Hashing

Debabrata Kar
Department of Computer Science and Engineering
Silicon Institute of Technology
Bhubaneswar, India
debabrata.kar@silicon.ac.in
Suvasini Panigrahi
School of Computer Engineering
KIIT University
Bhubaneswar, India
spanigrahifcs@kiit.ac.in


Abstract In this Internet age, web applications have become
an integral part of our lives, but security and privacy of our
sensitive data has become a big concern. Over last several years,
SQL Injection has been the most prevalent form of attack on web
databases. Much research has been done in this area, but most of
the approaches in the literature have high computational
overhead or difficult to deploy in practical scenarios. In this
paper we have proposed a lightweight approach to prevent SQL
Injection attacks by a novel query transformation scheme and
hashing. We implemented it on a prototype e-commerce
application and the results of our experiments show that it can
successfully and efficiently block a variety of SQL Injection
attempts. This approach can also be easily implemented on any
language or database platform with little modification.
KeywordsSQL Injection, SQLIA Prevention, Query
Transformation, Query Structure, Hashing
I. INTRODUCTION
In todays Internet driven world, we have become
dependent on web applications like email, e-commerce, social
networking, online banking, blogs, forums, online gaming and
so on. The web applications on the Internet are usually
dynamic and driven by one or more databases in the backend.
While the Internet and web applications have made our
lives much simpler, security & privacy of the sensitive data in
the backend databases has become a big concern. Web
applications, being accessible to everyone, are exposed to
various forms of security threats like Denial of Service (DoS),
Structured Query Language (SQL) injection, Cross-site
Scripting (XSS), Remote File Inclusion attacks etc. Out of
various threats, SQL injection has been the most prevalent
form of attack on websites. In fact it has been on the top among
the top-10 security threats listed by OWASP [1] since last
several years. According to TrustWave 2012 Global Security
Report [2], among all web-based attacks, SQL injection
remained the number one attack method for the fourth year in a
row. The problem has become more serious after 2008,
because attackers have started using sophisticated botnets [3] to
automatically discover vulnerable websites from search
engines and launch mass SQL injection attacks on them.
Defensive coding practices by sanitizing and filtering user
input data provides some degree of protection from SQL
injection attacks, but many programmers are not aware of this
serious security threat. Some organizations use Network
Intrusion Detection System (NIDS) or generic Database
Intrusion Detection System (DIDS) to block attack attempts by
matching with a set of previously known attack signature
patterns. However, signature-based detection can be bypassed
[4]-[6] by experienced attackers with a little effort. Much
research has been done in this area but many of the methods
proposed in the literature are either computationally heavy or
difficult to deploy in production environments.
In this paper, we have proposed a lightweight approach to
prevent SQL Injection attacks by using a novel query
transformation scheme followed by hashing. We ascertain that
this method is effective to prevent a variety of SQL injection
attempts. For this work we have considered PHP and MySQL,
however our approach can be easily ported to other platforms
with minimal modifications. Our experimental results show
that this approach can protect web applications without
noticeable difference in their performance.
The rest of the paper is organized in the following manner.
Section 2 discusses the background and explains the basics of
SQL injection attacks. Section 3 outlines the related research in
this area. In Section 4 we introduce the key idea behind the
proposed query transformation scheme. We detail our approach
in Section 5 and show the experimental evaluation in Section 6.
Finally we note the limitations in Section 7 and conclude the
paper with direction for future work.
II. BACKGROUND
over SQL injection was originally published in a black-hat
community website called Phrack Magazine [7] in December
1998 by rain.forest.puppy (rfp). Under the section titled
ODBC and MS SQL Server 6.5, rfp described the methods
of injecting SQL keywords into web pages through query
string parameters and form field values thereby being able to
extract information from the backend database. It was later
named as SQL Injection by Chip Andrews in October 2000.
SQL injection problem has been around for a decade since its
discovery. There have been many instances of SQL injection
attacks on numerous websites in the history causing huge loss
to the organizations due to leakage of sensitive information. It
is estimated that over 180,000 web pages are compromised
daily due to SQL injection attacks alone.
1317 978-1-4673-4529-3/12/$31.00 c 2012 IEEE
A. SQL Injection Attack
An SQL Injection Attack (SQLIA) is a subset of the
unverified/unsanitized input vulnerability and occurs when an
attacker attempts to change the logic, semantics or syntax, and
behavior of a dynamically generated SQL statement by
inserting additional SQL keywords and/or operators into the
statement through URL query string or HTML form values,
usually with a malicious intent. SQL injection vulnerability on
a web page exists if user inputs or query string parameters are
used to construct dynamic SQL queries without properly
validating them. According to OWASP, this is the most
common flaw found in web applications.
To explain the basic mechanism of SQL injection, we take
the classic example of a login form, commonly seen on many
websites. A typical PHP code snippet that validates login
credentials against the values stored in databases is as below:
<?php
$sql = "SELECT * FROM tbl_users WHERE username
= '".$_POST['user_name']."' AND password =
'".$_POST['user_pass']."'";
$result = mysql_query($query, $connection);
?>
If the user enters john as the user name and
mypass as the password, the resulting SQL query that will be
executed against the database is:
SELECT * FROM tbl_users WHERE username = 'john'
AND password = 'mypass'
However, if an attacker enters abcd' OR 1 = 1 -
- as the user name and xyz as the password, then the
resulting query after substituting these values would be:
SELECT * FROM tbl_users WHERE username =
'abcd' OR 1 = 1 -- ' AND password = 'xyz'
It may be noted that the single quote after abcd in
the input serves as the string terminator for the username value
while the added clause OR 1 = 1 always evaluates to TRUE.
The double-dash at the end of the inputted username, which is
the comment character in Transact-SQL, effectively comments
out the rest of the query. When executed, the query returns all
records from the tbl_users table with the record pointer at the
first row of the result set. The attacker therefore successfully
logs in as the first user in the table. The fundamental fact with
SQL injection is the ability of an attacker to change the syntax
and semantics of a dynamically generated query by carefully
inserting special characters and SQL keywords into the input
fields which drastically alters the behavior of the query
originally intended by the programmer, resulting in an
unauthorized access into the protected area of the website.
B. Types of SQL Injection
Depending on the way and intent of injecting special
characters and SQL keywords into form input fields or URL
parameter values, SQL injection has been classified by Halfond
et al. [8] into the following categories:
1) Tautologies
2) Illegal or logically incorrect queries
3) UNION based queries
4) Piggy-backed queries
5) Stored procedure attacks
6) Inference based attacks
7) Alternate encodings

The above SQL injection methods mostly rely on the
information revealed through error messages displayed on the
vulnerable web page which the attacker uses to make an
inference and craft the next injection attempt. Where error
messages have been suppressed, the attacker can still use Blind
or Time-based attack methods. In blind method, the attacker
resorts to blind guessing of information character by character,
using the output in form of true/false depending on the point at
which the behavior of the web page changes. In time-based
attacks, the attacker introduces a delay by injecting an
additional SLEEP(n) call into the query and then observing if
the web page was actually delayed by n seconds. If so, then the
attacker can make the inference from the amount of delay
injected versus the time-gap after which the web page loads.
III. RELATED WORK
Being a decade old problem that is persisting till date, there
has been extensive work on detection and prevention of SQLIA
by a number of researchers. Based on the approaches used by
the authors in the literature, we discuss the related work under
the following categories.
A. Defensive Coding Practices
Defensive coding practices have been always advised as a
first-hand protection against SQL injection attacks. Livshits et
al. [9] proposed a Web Application Construction Framework to
protect against code injection attacks. Enforcing security by
strong variable typing system was proposed by Robertson et al.
[10]. Use of C++ templates has been proposed by Gil et al. [11]
to produce safe SQL queries from applications.
B. Code Analysis
Livshits et al. [12] used static code analysis to determine
potential vulnerabilities in Java Applications. Jovanovic et al.
[13] devised Pixy, a static analysis tool for PHP 4 applications.
Static analysis to model strings using a context-free grammar
was used by Wassermann et al. [14] to detect vulnerable
hotspots. Huang et al. [15] proposed WebSSARI using static
analysis to determine vulnerable parts of code and use that
information to create runtime guards for protection. Halfond et
al. [16] presented AMNESIA that used static analysis to build
query models and monitoring the runtime queries according to
the model. CANDID, presented by Bandhakavi et al. [17], was
based on augmenting the source code by additional queries
with candidate variables and then matching the runtime queries
with structure of the candidate queries. Code analysis however
is error-prone and requires access to the source code.
C. SQL Query Randomization
Boyd et al. [18] presented SQLRand which appends a
random key to every SQL keyword in the queries used in the
1318 2013 3
rd
IEEE International Advance Computing Conference (IACC)
application code. SQLRand however used statically generated
keys which can be determined by brute-force. Later, a dynamic
key management scheme was proposed by Mokhov et al. [19].
D. Penetration Testing
Since SQL injection vulnerability exists primarily due to
weakness in input validation, lot of work has been done on
penetration testing to find out vulnerabilities so that they can be
fixed. Benedikt et al. [20] developed VeriWeb to automatically
discover and test dynamic websites. Kals et al. [21] presented
SecuBat web vulnerability scanner to find SQL injection and
XSS vulnerabilities. Wasserman et al. [22] presented a
technique to automatically generate test inputs for testing of
dynamic PHP applications with specific focus to generate test
oracles for SQL injection.
E. Taint-based Approaches
Variable tainting based approaches have been used to track
information flow during execution of a program. Positive
tainting with syntax aware evaluation was proposed by Halfond
et al. [23] to counter SQL injection attacks. Nguyen-Tuong et
al. [24] claimed that web applications can be sufficiently
hardened by using precise tainting. PHP Aspis, developed by
Papagiannis et al. [25], used partial taint checking approach to
protect PHP applications from injection attacks.
F. SQL Syntax Tree and Graph Based Methods
Buehrer et al. [26] used a simple Java based parse-tree
validation approach to prevent injection attacks. Their
approach however requires rewriting the portion of code
containing SQL queries to invoke the parse-tree validator.
Zhang et al. [27] proposed using variable tracking along with
tree validation to detect injection vulnerabilities. Logical trees
for the WHERE clause part of queries with semantic analysis
was used in [28] to prevent injection attacks.
G. HTTP Packet Inspection
Since all SQL injection attacks are through the web
interface over HTTP, researchers have tried to detect injection
attempts by finding anomalies in the HTTP traffic. Kiani et al.
[29] proposed that HTTP request length based models of a web
application can be effectively used to detect SQL injection
attempts. Kirchner et al. [30] created a self-learning anomaly
detection framework for HTTP traffic without signatures of
previously known attacks. Similarly, HMMPayl [31] inspected
HTTP traffic to detect anomalies and attack attempts.
However, matching multiple patterns on-the-fly on large HTTP
payloads adds lot of overhead processing on the server.
H. Fingerprinting and Learning based Methods
Lee et al. [32] proposed DIDAFIT, a framework to create
fingerprints of legitimate transactions using compact regular
expressions which can be matched at runtime to detect
anomalies. A learning based method using a mixture of string
models was proposed in [33]. Choi et al. [34] proposed use of
N-Gram analysis for feature selection and further classification
with Support Vector Machines (SVM) for detecting attack
attempts. Learning normal query behaviors has been proposed
by Kadirvelu et al. [35] using Gene Expression Programming.
All learning based methods involve training a model using data
collected during normal use and then use the trained model to
detect any abnormal behavior at run-time.
IV. PRELIMINARIES
The idea of collecting legitimate queries during normal use
in a secured environment and then matching runtime queries
with that repository is not very new, however there are two
major practical challenges to overcome.
1) Reducing the size of the legitimate query
repository
2) Performing fast and efficient matching at
runtime

A web application can issue thousands of SQL queries to
the database server for execution. A small scale e-commerce
website, written with PHP and MySQL database at the
backend, could contain about 80-100 PHP pages. If each page
issues 20-30 SQL queries during its execution, about 1600-
3000 different SQL queries will be generated by the entire
website. Assuming that 100 concurrent users browse the
website every minute, a SQLIA detector will require to find a
match for about 3-5 queries every millisecond searching
through a pool of 1600-3000 normal queries. This can impose a
huge processing overhead on the database server causing
degradation of performance. For a large website with larger
number of concurrent users, this method becomes infeasible
even with a high-capacity dedicated server. Therefore the size
of the legitimate query repository must be minimized. In
addition, since the repository can still contain a large number of
records, a fast and efficient searching method is required for
matching of queries generated during runtime.
A common approach that has been used in the literature in
this regard is to remove the query attribute values (the variable
part) and store only the skeleton (the constant part) of the
queries. For example, consider the following two SQL queries:
1) SELECT * FROM products WHERE
category_id = 105 AND brand_id = 2
2) SELECT * FROM products WHERE
category_id = 5 AND brand_id = 102

By removing the attribute values for category_id and
brand_id columns and replacing them with a ?, both queries
reduce to the same skeletal form as:
SELECT * FROM products WHERE category_id = ?
AND brand_id = ?
Thus by storing only the skeleton of the queries, the search
space can be reduced by a good extent. This is same as storing
the parametrized or prepared statement form of each query
generated during normal use. At runtime, the attribute values
can be removed and the skeleton query can be matched with
the legitimate query repository. However, consider the
following two queries in skeletal form:
1) SELECT * FROM products WHERE
category_id = ? AND brand_id = ?
2013 3
rd
IEEE International Advance Computing Conference (IACC) 1319
2) SELECT * FROM products WHERE
supplier_id = ? AND brand_id = ?

These two skeleton queries have to be stored separately
because one of them uses the brand_id attribute while the other
uses the supplier_id attribute in the WHERE clause. Therefore
removing the query attribute values alone is not sufficient to
minimize the size of the legitimate query repository.
V. PROPOSED APPROACH
We propose a novel query transformation scheme that
transforms a query into its structural form instead of the
parametrized form. We assume that any query generated by the
website is equally vulnerable to some form of injection attack.
An attacker will try various means to alter the structure (and
hence the behavior) of dynamically generated queries by
inserting SQL keywords, special characters and alpha-numeric
values. Therefore, we defend that, except for the SQL
keywords and special characters, identifier tokens in the query
such as table and column names along with the parameter
values are irrelevant as far as the structural form of the query is
concerned. If we hide the table and column names from the two
parametrized queries cited above, we get:
1) SELECT * FROM <table> WHERE
<column> = ? AND <column> = ?
2) SELECT * FROM <table> WHERE
<column> = ? AND <column> = ?
It may be observed that both the queries now reduce to
exactly the same structural form. Therefore, in this example,
we need to store only one structural form instead of two
skeleton queries in the repository. To further illustrate the
concept, let us consider another query on a different table:
SELECT * FROM suppliers WHERE city_id = ?
AND zip_code = ?
Using the same principle of omitting table name and
column names, this query will also reduce to the same
structural form of the previous two queries as shown below:
SELECT * FROM <table> WHERE <column> = ? AND
<column> = ?
Thus by ignoring the identifier tokens, many different
queries will transform into the same structural form. If any of
these three example queries becomes a victim of some form of
SQL injection, for example a tautological attack, the structural
form of the injected query will be:
SELECT * FROM <table> WHERE <column> = ? AND
<column> = ? OR ? = ? --
As the structural form of the injected query is substantially
different from that of the legitimate queries it can be easily
determined as an SQL injection attempt. The major advantage
with our approach is that a number of different queries can
potentially reduce to the same structural form, minimizing the
size of the search space for run-time matching. Based on this
key idea, we now present our query transformation scheme.
A. The Query Transformation Scheme
As stated earlier, our goal is to convert the queries into their
structural form instead of parametrized form. To achieve that,
we formulate a transformation scheme as given in Table I. The
scheme has been designed to handle largely possible varieties
of queries, including any query that refers objects from the
system databases and/or tables.
All of these transformations can be easily done by substring
replacement with appropriate regular expressions using the
preg_replace() function available in PHP.
TABLE I. THE QUERY TRANSFORMATION SCHEME
Step Token Transformation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SQL Keywords, Functions
System Database
System Table
Column of System Table
User Database
User Table
Column of User Table
Single Quoted String
Double Quoted String
Integer Values
Decimal Values
Hexadecimal Values
Table Aliases
Column Aliases
Newline/Tab/Space(s)
Any other symbol
To Uppercase
SYSDB
SYSTBL
SYSCOL
USRDB
USRTBL
USRCOL
'&STR'
"&STR"
&INT
&DEC
&HEX
ALS
ACOL
Single Space
No Transformation

Consider the following example query (intentionally
written in bad case to illustrate the effect of transformation):
SeLECt * FroM customers WhERe first_name
LiKe '%John%' AnD (city_id = 23 oR zip_code =
'45345');
Applying the query transformation as per our scheme as
described above, the query is transformed into:
SELECT * FROM USRTBL WHERE USRCOL LIKE
'%&STR%' AND (USRCOL = &INT OR USRCOL =
'&INT');
It may be noted that the structural form of the query still
preserves the data types expected for the attribute values along
with how they are delimited in the original query.
B. Hashing of the Transformed Queries
In order to store the transformed queries and perform
efficient searching during run-time, we propose to apply a
suitable hashing function to generate unique hash keys for each
transformed query by using a suitable hash function.
Generating unique hash key for each transformed query
offers two advantages: (i) only the hash keys can be stored
instead of the transformed queries thereby saving lot of storage
space in the legitimate query repository, and (ii) a primary
index can be created on the hash keys, as they are unique, to
facilitate fast and efficient searching at run-time. It is however
required that the hash function is fast because it will be used
during run-time. Also it should have a very low collision rate.
1320 2013 3
rd
IEEE International Advance Computing Conference (IACC)

Fig.1 The BookStore E-Commerce Application Prototype
PHP (version 5 and above) has built-in support for over 40
hash algorithms through its hash() function which generates
hash keys ranging from 8 to 128 characters. Considering that a
smaller key is prone to collision, while a larger key requires
more storage space, a key size of 32 characters is ideal for our
purpose. To select a suitable hash algorithm, we performed a
benchmark test by applying the algorithms which generate keys
of 32 characters on arbitrary strings of length 500 to 2000
characters. Each algorithm was applied 1000 times on each
string and the average time taken to compute the hash key was
measured in milliseconds. A standard desktop computer with
Intel

Core i3 2.10GHz processor and 2GB RAM was used

for the benchmarking. The results of the bench marking test of
various hash functions are given in Table II.
TABLE II. BENCHMARK RESULT OF HASH ALGORITHMS
Hash Algorithm
String Length
500 1000 1500 2000
MD2
MD4
MD5
RIPEMED128
TIGER128,3
TIGER128,4
HAVAL128,3
HAVAL128,4
HAVAL128,5
0.39846
0.00402
0.00557
0.01169
0.01134
0.01580
0.01451
0.02293
0.02605
0.77839
0.00715
0.00979
0.02576
0.01939
0.02936
0.02674
0.03658
0.06626
1.16861
0.01336
0.01516
0.02190
0.03040
0.04007
0.04536
0.07565
0.08524
1.54123
0.01538
0.01915
0.03103
0.03912
0.05144
0.05120
0.07933
0.10396

The results reveal that the MD4 algorithm has the best
performance. However the security of MD4 algorithm has been
severely compromised in the past. Though MD5 algorithm
turns out to be 13% to 39% slower than MD4, it has a high
collision resistance of 2
20.96
and uniform distribution of
generated hash keys. Therefore, we decide that MD5 hashing is
best suitable for generating hash keys of transformed queries.
Another advantage is that there is also a direct md5() function
available in PHP since version 4.
VI. EXPERIMENTAL EVALUATION
To evaluate our approach, we developed a Book Store e-
commerce web application prototype using PHP 5.4.5 and
MySQL 5.5.25a (Fig. 1) with standard features such as
browsing books by genre or author, book details, searching,
author details, book reviews, advertisements, shopping cart,
checkout system, contact form and back-end administration
interface etc. as seen on real online book stores. The code of
the web application was intentionally written with weak or no
input validation to ensure that every web page is vulnerable to
multiple types of SQL injection attacks.
With MySQL general query logging switched on, we
browsed all parts of the web application in a secured intranet
environment simultaneously from 5 client computers. Total
33,980 queries were logged in the MySQL general query log
out of which 1,354 unique queries were extracted. All of these
are legitimate queries. These queries were then converted to
structural form using our query transformation scheme which
produced only 93 unique query structures. These structural
forms of queries were then hashed with MD5 algorithm and the
hash keys generated were stored in a legal_queries table in the
applications MySQL database. We observed that the number
of unique skeleton queries with only parameter value removal
came out as 135. Therefore it is proved that our query
transformation scheme reduced the legitimate query repository
by an appreciable 31.11% in this experiment. For a larger web
application, the reduction will definitely be more.
We then modified the web applications database access
component to process every query generated at run-time
through the same transformation scheme, generate its MD5
hash key and look up the same in the legal query repository. If
the hash key is found in the legal_queries table, then the query
is executed; otherwise an E_USER_ERROR is triggered using
PHPs trigger_error() function with error message Possible
SQL Injection Attempt!.
The web application was installed on a desktop computer
having configuration mentioned above under Microsoft IIS 7.0.
The overhead due to this additional processing was measured
under various load conditions with 50 to 300 concurrent
requests per second. On an average we noticed a delay of 6.17
to 17.58 milliseconds per page request, which is negligible in
actual production environment.
The web application was then subjected to SQL injection
attacks using a mixture of automated & manual scanning &
hacking tools such as HP Scrawler (free version), NetSparker
(community edition), WebCruiser Pro, SQL Power Injector,
sqlmap, The Mole, IronWasp, and jSQL Injector. Since every
query generated by the application is transformed, hashed and
then the hash key is searched in the legitimate query repository
before execution, none of the SQL injection attempts were
successful. Therefore we conclude that this approach provides
100% protection against SQL injection attacks.
VII. LIMITATION
Though the proposed query transformation scheme and
hashing provides full protection from most varieties of SQL
injection, but it suffers from one limitation. This approach
cannot prevent second order SQL injection attempts since the
parameter values (especially the string values) are removed
during the transformation process. While prevention of SQL
injection attacks is our primary goal in this work, it is
worthwhile to mention that this approach can neither be
applied to prevent XSS attacks, because XSS attacks also
2013 3
rd
IEEE International Advance Computing Conference (IACC) 1321
happen by embedding executable code (usually in JavaScript)
inside string parameters entered through web forms.
VIII. CONCLUSION
In this paper we have presented a lightweight method to
prevent SQL injection attacks by a novel query transformation
scheme to convert SQL queries into their structural form and
then applying MD5 hashing to generate unique hash keys for
each legal query collected during normal use. At run-time, hash
key for every dynamic query is generated in the same manner
and matched against the previously stored hash keys to prevent
SQL injection attempts. This approach minimizes the size of
the legitimate query repository and facilitates fast and efficient
searching at run-time using a primary index. Our experimental
results show that this approach can effectively prevent all types
of SQL injection attempts except second order SQL injection.
This approach does not require major changes to application
code and has negligible effect on performance even at higher
load conditions due to its low processing overhead. It can also
be easily applied to any other language & database platform
without major changes. Further research on the query
transformation scheme is needed to make it suitable for
prevention of second order SQL injection attempts.
REFERENCES
[1] OWASP, Top 10 Security Threats 2010. https://www.owasp.org/
index.php/Top_10_2010-Main, 2010.
[2] TrustWave, Executive Summary: Trustwave 2012 Global Security
Report. https://www.trustwave.com/global-security-report, 2012.
[3] D. Maciejak and G. Lovet, Botnet-Powered Sql Injection Attacks: A
Deeper Look Within, in Virus Bulletin Conference, pp. 286288, 2009.
[4] O. Maor and A. Shulman, SQL Injection Signatures Evasion, White
Paper, Imperva, Inc., April 2004.
[5] S. Quartini and M. Rondini, Blind Sql Injection with Regular
Expressions Attack. http://www.ihteam.net/papers/blind-sqli-
regexpattack.pdf, December 2011.
[6] J. Dahse, Exploiting hard filtered SQL Injections. http://websec.
wordpress.com/2010/03/19/exploiting-hard-filtered-sql-injections/,
March 2010.
[7] RFP, NT Web Technology Vulnerabilities. http://phrack.org/
issues.html?issue=54&id=8#article, December 1998.
[8] W. Halfond, J. Viegas, and A. Orso, A Classification of SQL-injection
Attacks and Countermeasures, in International Symposium on Secure
Software Engineering (ISSSE), pp. 1223, 2006.
[9] B. Livshits and . Erlingsson, Using Web Application Construction
Frameworks to Protect Against Code Injection Attacks, in Proceedings
of the 2007 Workshop on Programming Languages and Analysis for
Security, pp. 95104, ACM, 2007.
[10] W. Robertson and G. Vigna, Static Enforcement of Web Application
Integrity through Strong Typing, in Proceedings of the 18th
conferenceon USENIX security symposium, pp. 283298, USENIX
Association, 2009.
[11] J. Gil and K. Lenz, Simple and Safe SQL Queries with C++
Templates, in Proceedings of the 6th International Conference on
Generative Programming and Component Engineering, pp. 1324,
ACM, 2007.
[12] V. Livshits and M. Lam, Finding Security Vulnerabilities in Java
Applications with Static Analysis, in Proceedings of the 14th
conference on USENIX Security Symposium, vol. 4, pp. 1818,
USENIX Association, 2005.
[13] N. Jovanovic, C. Kruegel, and E. Kirda, Pixy: A Static Analysis Tool
for Detecting Web Application Vulnerabilities, in Security and Privacy,
2006 IEEE Symposium on, pp. 257263, IEEE, May 2006.
[14] G. Wassermann and Z. Su, Sound and Precise Analysis of Web
Applications for Injection Vulnerabilities, ACM SIGPLAN Notices,
vol. 42, no. 6, pp. 3241, 2007. ACM.
[15] Y. Huang, F. Yu, C. Hang, C. Tsai, D. Lee, and S. Kuo, Securing Web
Application Code by Static Analysis and Runtime Protection, in
Proceedings of the 13th International Conference on World Wide Web,
pp. 4052, ACM, 2004.
[16] W. Halfond and A. Orso, AMNESIA: Analysis and Monitoringfor
NEutralizing SQL-Injection Attacks, in Proceedings of the 20th
IEEE/ACM International Conference on Automated Software
Engineering, pp. 174183, ACM, 2005.
[17] S. Bandhakavi, P. Bisht, P. Madhusudan, and V. Venkatakrishnan,
CANDID: Preventing SQL Injection Attacks Using Dynamic
Candidate Evaluations, in Proceedings of the 14th ACM conference on
Computer and communications security, pp. 1224, ACM, 2007.
[18] S. Boyd and A. Keromytis, SQLrand: Preventing SQL injection
attacks, in Applied Cryptography and Network Security, pp. 292302,
Springer, 2004.
[19] S. Mokhov, J. Li, and L. Wang, Simple Dynamic Key Management in
SQL Randomization, in New Technologies, Mobility and Security
(NTMS), 2009 3rd International Conference on, pp. 15, IEEE, 2009.
[20] M. Benedikt, J. Freire, and P. Godefroid, VeriWeb: Automatically
Testing Dynamic Web Sites, in In Proceedings of 11th International
World Wide Web Conference (WWW2002), Citeseer, 2002.
[21] S. Kals, E. Kirda, C. Kruegel, and N. Jovanovic, Secubat: A Web
Vulnerability Scanner, in Proceedings of the 15th International
Conference on World Wide Web, pp. 247256, ACM, 2006.
[22] G. Wassermann, D. Yu, A. Chander, D. Dhurjati, H. Inamura, and Z. Su,
Dynamic Test Input Generation for Web Applications, in Proceedings
of the 2008 International Symposium on Software Testing and Analysis,
pp. 249260, ACM, 2008.
[23] W. Halfond, A. Orso, and P. Manolios, Using Positive Tainting and
Syntax-Aware Evaluation to Counter SQL Injection Attacks, in
Proceedings of the 14th ACM SIGSOFT International Symposium on
Foundations of Software Engineering, pp. 175185, ACM, 2006.
[24] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans,
Automatically Hardening Web Applications Using Precise Tainting,
Security and Privacy in the Age of Ubiquitous Computing, pp. 295
307, 2005.
[25] I. Papagiannis, M. Migliavacca, and P. Pietzuch, PHP Aspis: Using
Partial Taint Tracking to Protect Against Injection Attacks, in 2nd
USENIX Conference on Web Application Development, pp. 1324,
2011.
[26] G. Buehrer, B. Weide, and P. Sivilotti, Using Parse Tree Validation to
Prevent SQL Injection Attacks, in Proceedings of the 5th International
Workshop on Software Engineering and Middleware, pp. 106113,
ACM, 2005.
[27] Z. Zhang, Q. Zheng, X. Guan, Q. Wang, and T. Wang, A Method for
Detecting Code Security Vulnerability Based on Variables Tracking
with Validated-Tree, Frontiers of Electrical and Electronic Engineering
in China, vol. 3, no. 2, pp. 162166, 2008. Springer.
[28] G. Lu and K. L, Logical Trees: An Essential Method of Parsing SQL
Statement with Semantic Analysis, 2011. Brunel University, UK.
[29] M. Kiani, A. Clark, and G. Mohay, Length based Modelling of HTTP
Traffic for Detecting SQL Injection Attacks, Proceedings of Recent
Advances in Security Technology (RNSA2007) Conference, p. 67,
2007.
[30] M. Kirchner, A Framework for Detecting Anomalies in HTTP Traffic
Using Instance-based Learning and k-Nearest Neighbor Classification,
in Security and Communication Networks (IWSCN), 2010 2nd
International Workshop on, pp. 18, IEEE, 2010.
[31] D. Ariu and G. Giacinto, HMMPayl: An Application of HMM to the
Analysis of the HTTP Payload, in Workshop On Applications Of
Pattern Analysis, Cumberland Lodge, pp. 8187, 2010.
[32] S. Lee, W. Low, and P. Wong, Learning Fingerprints for a Database
Intrusion Detection System, Computer Security - ESORICS 2002, pp.
264279, 2002. Springer.
1322 2013 3
rd
IEEE International Advance Computing Conference (IACC)
[33] F. Valeur, D. Mutz, and G. Vigna, A Learning-based Approach to the
Detection of SQL Attacks, Detection of Intrusions and Malware, and
Vulnerability Assessment, pp. 533546, 2005. Springer.
[34] J. Choi, H. Kim, C. Choi, and P. Kim, Efficient Malicious Code
Detection Using N-Gram Analysis and SVM, in Network-Based
Information Systems (NBiS), 2011 14th International Conference on, pp.
618621, IEEE, 2011.
[35] S. Kadirvelu and K. Arputharaj, Intelligent Agent Based Prevention
System for Web Applications from SQL Injection Attacks Using Gene
Expression Programming, European Journal of Scientific Research,
vol. 49, no. 2, pp. 286292, 2011.

2013 3
rd
IEEE International Advance Computing Conference (IACC) 1323