SQLshield: Preventing SQL Injection Attacks

by Modifying User Input Data

Punit Mehta, Jigar Sharda, and Manik Lal Das(B)

DA-IICT, Gandhinagar, India

{punit9462,jigar.shar24}@gmail.com, maniklal das@daiict.ac.in

Abstract. SQL injection attacks, a class of code injection attacks, pose

a serious threat to web applications. A web server allows users to perform
a query in order to get the intended service where the SQL queries con-
taining user inputs are executed by the database server. An attacker can
take advantage of this query-response mechanism to inject some char-
acters into the user input based on the attack strategy. This may lead
to an SQL injection attack. If an attacker can bypass the SQL injection
defense put at the web server, then the attacker can obtain some sensi-
tive information from the database. In this paper, we present a scheme,
SQLshield that prevents SQL injection attacks in web applications. SQL-
shield uses a randomization technique that modifies the user input data
before the SQL query is executed at the database server. The random-
ization technique used in SQLshield modifies the user input data in such
a way that the execution of the resultant SQL query does not divert
from its programmer-intended execution. We compare SQLshield with
other schemes and show that SQLshield performs better than the other
approaches used to detect and prevent SQL injection attacks.

Keywords: Web security · SQL injection attacks · SQL parse tree ·

Randomization

1 Introduction

World wide web consists of millions of web applications which are run with the
power of internet for a variety of services such as financial, healthcare, research,
entertainment, educational and so on. Most of the web applications’ services
require frequent access to the database while interacting with the users. These
applications provide mechanisms by which a user is allowed to submit a query
that aims to retrieve intended data or provide service with the help of the data-
base server. If such applications do not handle the malicious queries appropri-
ately, then the database’s response to such queries would reveal some sensitive
information to the malicious party. SQL injection attack [1,8,11] is one such
attack which poses some serious threats (primarily authentication bypass and
leakage of private information [17]) to web applications. Web application that
uses SQL statement for query-response mechanism between the server and a

c Springer International Publishing Switzerland 2015
S. Jajodia and C. Mazumdar (Eds.): ICISS 2015, LNCS 9478, pp. 192–206, 2015.
DOI: 10.1007/978-3-319-26961-0 12
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 193

client may potentially be vulnerable to SQL injection attacks. By injecting mali-

cious SQL statements into input fields, the attacker may execute malicious SQL
queries in the database server. Such unintended execution of the SQL queries
can reveal some sensitive information about the users as well as the server [15].
As a result, validating user-linked data is necessary in order to defend the web
applications from SQL injection attacks. We give a simple example below which
would help a naive reader to understand how a typical SQL injection attack
works on a web application.
Actual Query:
SELECT password FROM users WHERE name = ‘$username’
Attacker Query:
SELECT password FROM users WHERE name = ‘A’ OR 1=1 #’

Consider the Attacker Query. The attacker’s input to the query is A’ OR 1=1 #.
Here, 1=1 always results in true. Since the operation between the two operands
name = ‘A’ and 1=1 is an OR operation, the entire “WHERE clause” is
evaluated as TRUE. This would lead to the exposure of all the passwords from
the users’ table and a successful attempt at an SQL injection attack.
Several approaches [2–6,25] have been proposed in literature for detect-
ing (and/or preventing) SQL injection attacks. The techniques used in these
approaches include the use of aliases for table and field names, prepared state-
ment, stored procedures, limiting user input length, escaping string delimiters,
filtering the error messages and a learning based approach [24] to detect SQL
injection attack by measuring the anomaly score for a given query. Subsequently,
string constraint solving [22], dynamic runtime monitoring of untrusted strings,
training on trusted strings, automating the filtering and training mechanisms
[9,10] can work to some extent for detecting and preventing SQL injection
attacks. But, the training set and runtime monitoring downgrade the system’s
performance. The prevention mechanism can be effective if it detects malicious
input and allows only legitimate input. Sometimes it may so happen that the
user’s input contains legitimate data, but the security mechanism used for detect-
ing an SQL injection attack triggers it as a potential injection attack which
deprives the legitimate users from getting the intended services.
Our Contributions. We present a scheme, SQLshield, which can detect and
prevent SQL injection attacks on web applications. Whenever a user (possibly
malicious) gives input through the web-interface, SQLshield appends a random
key to the selected sub-strings of the user input (not to the underlined SQL
query’s keywords). Then, SQLshield forms the parse tree of a query and removes
the random key from the user input. Here, the parse tree of the SQL query
remains benign due to the randomization on user input. Therefore, the attacker
cannot execute an SQL injection attack as the intended behaviour of the SQL
query cannot be altered. We discuss some recently proposed techniques [2–4,6]
on defending SQL injection attacks and observe some limitations of them. Our
proposed scheme, SQLshield, mitigates such limitations. The following limita-
tions of SQLrand [2] and CANDID [3] are mitigated by SQLshield.
194 P. Mehta et al.

– Unlike SQLshield, SQLrand uses a secret key to prevent SQL injection attacks.
Therefore, there is no threat of getting the key revealed while using SQLshield
as a defence mechanism. In the case of handling exceptions and type-errors,
the secret key may be revealed from the proxy functioning on SQLrand. This
is due to the bad implementation of CGI scripts which ultimately exposes the
underlined randomized queries [2].
– CANDID detects SQL injection attacks when candidate query’s parse tree
does not match the actual query’s parse tree. If a benign user input contains
SQL keywords, CANDID detects it as an SQL injection attack due to the
mismatch occurring between the parse tree of the candidate query and user
query. As SQLshield randomizes user inputs, the underlined structure of SQL
query’s parse tree does not alter even if the user inputs are part of the SQL
keyword set.

The remainder of the paper is organized as follows. Section 2 reviews related

approaches on preventing SQL injection attacks. Section 3 presents our scheme,
SQLshield. Sections 4 and 5 provide implementation and performance details of
SQLshield. We conclude the paper in Sect. 6.

2 Related Work

Over the years many approaches [2–6,21,23] have been proposed for mitigating
SQL injection attacks on web applications. There exist several testing tools [26,
27] for the detection of code injection attacks including SQL injection. Overall,
none of these approaches prevent SQL injection attacks completely. Each of these
approaches has its merits and limitations towards the same security objective.
We review some of these approaches in order to compare our proposed approach
with them.

2.1 SQLrand

SQLrand [2] randomizes the SQL keywords used in a query statement. A secret
keyword is shared between the web server and the proxy server. The web server
appends this secret keyword to all the SQL keywords present in a query (contain-
ing user inputs), forms a randomized SQL and passes it to the proxy server. The
secret keyword is removed from the randomized SQL query by the proxy which
then produces the result set and forwards it to the web server. The architecture
of SQLrand is shown in Fig. 1.
SQLrand protects the web server from SQL injection assuming that the
attacker cannot steal the secret keyword (shared between web server and proxy)
that is used to randomize the SQL keywords in the query statement. One of the
advantages of choosing SQLrand to prevent SQL injection attacks is that it is
relatively easy to implement. A major drawback of SQLrand is its dependence
on a secret keyword. If the attacker manages to get the secret keyword, then
he can bypass the prevention mechanism [2]. We briefly illustrate SQLrand with
the secret keyword 123.
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 195

Actual Query:
SELECT password FROM users WHERE name = ‘$username’
Randomized Query:
SELECT123 .. FROM123 .. WHERE123 name = ‘$username’

Fig. 1. Architecture of SQLrand [2]

Now, if the attacker successfully gets the secret keyword (i.e. 123), then he
can append this keyword to all the SQL keywords in the (malicious) query (as
shown below) and then try to bypass the web server’s randomization process. If
the attacker succeeds in bypassing the web server with the correct choice of the
secret keyword, then the (malicious) query will get de-randomized by the proxy
followed by the (malicious) query’s successful execution by the database server.
Attacker Query:
SELECT123 .. FROM123 .. WHERE123 name = ‘A’ OR123 1=1 #

2.2 CANDID

CANDID (Candidate Evaluation for Discovering Intent Dynamically) [3] is also

used to prevent SQL injection attacks in web applications. CANDID adds a
benign query (known as candidate query) along the control path in the source
code and compares the structure of the candidate query’s parse tree with the
structure of the actual query (containing possibly malicious user inputs) during
runtime. CANDID detects an SQL injection attack when the structure of the
actual query’s parse tree (executed during the user’s interaction with the data-
base) differs from the structure of the benign query’s parse tree. The architecture
of CANDID is shown in Fig. 2.

Benign Query:
SELECT .. FROM .. WHERE name = ‘ABC’
196 P. Mehta et al.

Fig. 2. Architecture of CANDID [3]

Attacker Query:
SELECT .. FROM .. WHERE name = ‘A’ OR 1=1 #’
Here, the structure of the attacker query’s parse tree does not match to the
structure of the benign query’s parse tree. For example, the attacker query’s
parse tree has a node corresponding to the SQL keyword-OR which is not present
in the benign query’s parse tree. Therefore, CANDID detects such attempt at
an SQL injection attack and does not allow the attacker query to execute. One
major advantage of CANDID is that it considers special characters (e.g. #,
×, % etc.) as inputs to the query and detects SQL injection if the candidate
query’s parse tree structure does not match with the intended structure. One
of the drawbacks of CANDID is that if the user input consists any of the SQL
keywords or special characters, it may be treated as a malicious query even if
the input is benign. Therefore, it cannot distinguish between the benign and
the malicious inputs when the input itself is a legitimate SQL token. The query
execution fails if the input itself is an SQL token due to the structural mismatch
between the parse trees of the candidate query and actual query. Although there
is no malicious input, CANDID considers the SQL tokens as malicious inputs
and stops the execution of the query.

2.3 SDriver
SDriver (Secure Driver: location specific signatures) [6] keeps track of the stack
frame of all the active function calls which are used to distinguish between
legitimate and malicious query. SDriver is not easy to bypass as it does not
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 197

depend on the source code of the application. However, the training phase’s
dependence on application is a major limitation of SDriver. For every application,
it goes through the training process which results into a significant overhead in
the entire execution. The architecture of SDriver is shown in Fig. 3.

Fig. 3. Architecture of SDriver [6]

2.4 TAPS
TAPS (Tool for Automatically Preparing SQL statements) [4] transforms the
original query into its corresponding prepare statement. It uses the parse tree of
an SQL query to identify data place-holder. TAPS removes the burden of manual
transformation of each query into its prepared statement. The limitation of TAPS
is that it may malfunction depending on the source code of the web application.
Furthermore, the queries need to be verified manually on the occurrence of errors
once the transformation is performed. There also exist other defensive coding
practices which include the use of prepared statements and stored procedures.
Such techniques need a lot of software-development care [11] and some minor
bug may potentially lead to the vulnerability to SQL injection attacks. Readers
are encouraged to go through [11–14,16,20] to understand SQL injection attacks’
defences and their limitations.

3 SQLshield - An Improved Scheme

We present a scheme, SQLshield, to prevent SQL injection attacks on web appli-
cations. SQLshield has the merits of SQLrand and CANDID. At the same time,
it also mitigates their limitations. SQLshield uses a keyword to randomize user
198 P. Mehta et al.

Fig. 4. Architecture of SQLshield

Fig. 5. Working principle of SQLshield

inputs (but not the SQL keywords). Initially, all the sub-strings of a user input
are enumerated.
Then, the keyword is appended to a sub-string which belongs to the set of
the standard SQL tokens and special characters. After this randomization on
user inputs, the final structure of an SQL query’s parse tree is generated, the
user inputs are de-randomized and the query is executed. If the user inputs
are benign, appropriate result sets are returned to the web-server after the safe
access to the database. We note that the random keyword used for randomization
process in SQLshield does not necessarily have to be secret. The architecture of
SQLshield and the working principl e are presented in Figs. 4 and 5, respectively.
We illustrate SQLshield with the following example.

SELECT password FROM users WHERE name = ‘$username’

Suppose the attacker enters ’ OR 1=1 # as input, then SQLshield converts the
input ’ OR 1=1 # to ’999 OR999 1=9991 #999’ by choosing a random
key 999. Note that the random key is to be appended to the tokens (e.g., OR,
AND, =, #, ’, etc.) which are present in a user input. The modified query or
newly formed query is as follows.

SELECT .. FROM .. WHERE name = ‘’999 OR999 1=9991 #999’

Now the modified query (i.e., a query with modified inputs) is fed into the
SQL parser. The SQL parser generates the parse tree of the modified query (as
shown in Fig. 6).
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 199

Fig. 6. SQLshield - Parse tree of SQL query with a modified (malicious) input

Since the parse tree contains an unexpected leaf node (i.e., 999 OR999
1=9991 #999’, the SQL parser would report a syntactic error and does not
proceed further for the execution. In this way, SQLshield blocks an attempt
at SQL injection attack. If the user input is benign, the parse tree structure
created after randomization process will be syntactically valid. Therefore, after
the creation of the parse tree, SQLshield extracts the modified user input, de-
randomizes it with the random key 999 and gets the actual input. Then, the
parser places the actual input in appropriate places in the query’s parse tree and
sends the query to the database for execution.
The parse tree of the programmer intended query is shown in Fig. 7. If an
attacker injects a malicious input, the modified parse tree of the query is shown
in Fig. 8. Note that it has two unexpected nodes at the end due to the SQL
injection attack. It can be seen from Fig. 7 that these nodes are not supposed to
be present in this SQL query’s parse tree. SQLshield focuses on eliminating such
unintended structural change in SQL query’s parse trees to avoid SQL injection
attacks.

DELETE * FROM users WHERE id = ‘$username’

DELETE delete_list FROM table_list WHERE where_cond

identifier identifier identifier = literal

* users id $username

Fig. 7. Parse tree of SQL query containing a benign input

200 P. Mehta et al.

Fig. 8. Parse tree of SQL query with a malicious input

Algorithm 1 . SQLshield
1: procedure modifyQuery(original query)
2: sql set ← set of SQL keywords and characters
3: parse-tree ← original query.getParseTree()
4: parse-tree-valid ← parse-tree.isValid()
5: top:
6: if !(parse-tree-valid) then
7: return “ERROR”
8: end if
9: /* Main Operation of SQLshield */
10: map¡pos,str¿ extract-input ← parse-tree.InputsPos()
11: for all input positions pos in extract-input do
12: user input ← extract-input[pos]
13: for all sub-strings substr in user input do
14: if substr in sql set then
15: appendRandomKey(user input, substr )
16: end if
17: end for
18: extract-input[pos] ← user input
19: end for
20: parse-tree.putInputs(extract-input)
21: parse-tree-valid ← parse-tree.isValid()
22: if !(parse-tree-valid) then
23: return “ERROR”
24: end if
25: modified query ← parse-tree.formQuery()
26: return modified query
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 201

SQLshield randomizes the user input by appending a random key to specific

tokens of the user input, which belong to a pre-defined set of SQL tokens and
special characters, and forwards the query to the parse tree generator which will
generate the parse tree as shown in Fig. 6. Once this structure has been decided
and validated syntactically, the randomized input is removed from the parse
tree and it is replaced by the original input. In this way, our scheme does not
completely alter the inputs and also it does not allow the attacker to change the
parse tree structure of the query. As the actual cause of SQL injection attack
lies in the malicious input, the initial procedure of SQLshield makes sure that
the user inputs participating in the generation of the SQL query’s parse tree are
not malicious. To achieve this, SQLshield appends a random key to only those
sub-strings of the user input which belong to a pre-defined set of SQL tokens
and special characters. Even if the attacker knows the random key, he cannot
execute any malicious query and exploit the system because SQLshield appends
the random key (even the attacker has already appended the random key to any
SQL token) to the user input. Therefore, after de-randomization, the query will
have syntactically invalid SQL tokens which cannot be executed successfully as
per the attacker’s intention. The core idea of SQLshield is given in Algorithm 1.

4 Implementation of SQLshield

We implemented SQLshield using SQL Parser v1.5.1.8 written in JAVA [7]. The
SQL query is parsed and the place-holder for user inputs are located. Random-
ized inputs are placed in the SQL query and fed to the parser. After the query’s
parse tree is finalized, the random key appended in the initial randomization
stage is removed from the inputs. We evaluated SQLshield on a 64-bit Linux
Machine running on quad-core Intel Core i3 CPU M 370 @ 2.40 GHz with a
RAM of 5.6 GB. We have tested the following SQL queries (including malicious
ones) in our experiments on SQLshield.
Test Case 1
Input SQL: SELECT * FROM products WHERE price BETWEEN 10 AND 20
Input Data: 10,20
Output SQL: SELECT * FROM products WHERE price BETWEEN 10 AND 20
Test Case 2
Input SQL: SELECT * FROM customers WHERE state=‘oregon’ AND
city=‘remand’
Input Data: oregon, remand
Output SQL: SELECT * FROM customers WHERE state=‘or999egon’ AND
city=‘remand999’
Test Case 3
Input SQL: INSERT INTO .. VALUES (‘+1’,‘test#’)
Input Data: +1,test#
Output SQL: INSERT INTO .. VALUES (‘+9991’,‘test#999’)
202 P. Mehta et al.

Test Case 4
Input SQL: UPDATE .. SET name=‘John Morr’ WHERE age = ‘%1 %’
Input Data: John Morr,%1 %
Output SQL: UPDATE .. SET name=‘John Mor999r’ WHERE age =
‘%9991 %999’
The above four SQL queries have benign inputs. Since the user input contains
SQL keywords and special characters, SQLshield modifies them by appending
the random key 999 to each of such tokens (e.g., keywords, special characters).
Now, the parse tree structure is constructed and the modified inputs in the
parse tree are de-randomized by the same random key 999, which brings back
the original inputs into the programmer desired query’s parse tree.
Test Case 5
Input SQL: DELETE FROM .. WHERE id = ‘’ OR 1=1 #’
Input Data: ’ OR 1=1 #
Output SQL: DELETE FROM .. WHERE id = ‘’999 OR999 1=9991 #999’

The Test case 5 has malicious inputs. In this case, the user input contains an
SQL keyword (e.g., OR) and special characters (e.g., ’, =, #). Upon receiving
these inputs, SQLshield modifies them by appending the random key 999 to
each of such tokens (e.g., OR, ’, =, #). Then, the parse tree structure is con-
structed. Based on the flow of the SQL parse tree construction, the parse tree
has an input node without any text (shown as a blank node in Fig. 6) and an
unexpected node with the value 999 OR999 1=9991 #999’. After randomizing
the malicious user inputs, the modified inputs are no longer malicious. As the
modified inputs are benign, the finalized parse-tree structure would be either
the programmer’s intended structure which will not have any malicious input
or it will be syntactically invalid. As a result, even if the attacker injects mali-
cious inputs, SQLshield will make sure that the underlying structure of the SQL
query’s parse tree which is sent to database for execution cannot be altered by
the attacker.

4.1 Remarks

If the application developer wants to use any tool to strengthen the security (e.g.
JDBC Checker [18,19]), then such type-validations have to be performed before
SQLshield is executed. Therefore, the initial assumption while implementing
the proposed Algorithm 1 is that the algorithm starts executing after all the
necessary input validations and modifications such as input’s format validation,
are performed. The reason for this assumption is that if the randomization on
inputs is performed before the validations, the input format might be changed
and the application may misbehave. It is evident from the discussion that such
an assumption does not violate the generality of SQLshield’s security objectives.
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 203

5 Performance
We have executed 100 input queries and measured the starting and ending time
of the program. We found that our JAVA code’s average execution time is 2 s
for processing 100 queries on NetBeans IDE 8.0 leading to an average execution
time equal to 20ms per query which is in the same order of SQLrand [2]. This
shows that the execution time of SQLshield is not significantly higher than what
is normally observed. However, the additional cost in SQLshield is due to the
parsing of an SQL query and it seems to be practical to fulfil the objective of
preventing the application against SQL injection attacks.
SQLshield performs better than CANDID (and also others mentioned in
Table 1) to prevent SQL injection attacks as SQLshield allows to have user inputs
which belong to the set of SQL tokens and special characters. CANDID considers
such inputs as SQL tokens and qualifies even a benign query as a malicious query
and invalidates it. SQLshield overcomes this limitation as it allows SQL tokens
as inputs by appending a random key to the input’s sub-strings which match
exactly to the SQL tokens. SQLshield appends a random key to every SQL
token and special characters contained in the user input. If the attacker knows
the random key (999 in our example) and tries to inject any malicious input, the
attacker will not succeed in executing the query, because the SQL tokens in the
input will lose their actual interpretation due to the randomization as explained
in the previous section.

Table 1. Comparison of SQLshield with other schemes

Feature → Intermediate Key dependency Debugging costa

Scheme ↓ manipulation
SQLrand Yes Yes (must be secret) High
[2]
CANDID No No Moderate
[3]
SDriver [6] Yes No Moderate
TAPS [4] Yes No High
SQLshield Yes Yes (need not be secret) Low
a
Debugging cost denotes the amount of time and effort required by the
developers to identify bugs and fix them

5.1 Limitations of SQLshield

Even though SQLshield effectively prevents SQL injection attacks and mitigates
the limitations of SQLrand and CANDID, it has the following issues.
– Since SQLshield uses a string matching algorithm to identify SQL tokens and
delimiters’ presence in user input, the execution time of the program is a
204 P. Mehta et al.

function of the length of the input. Therefore, it may take more time if the
underlined string matching algorithm used is not efficient.
– The web application may have several user inputs. It may happen that not
all these inputs contribute to SQL queries. Therefore, the programmer has to
identify the inputs which go into an SQL query in order to determine which
inputs have to be randomized. We do not want to randomize and de-randomize
the user inputs which do not correspond to SQL query and do not cause SQL
injection. If the application programmer wants this task to be automated, it
requires development care and some extra effort in the implementation.

6 Conclusion
Preventing SQL injection attacks is an important requirement for smooth cus-
tomer service in web-based applications. The main cause of SQL injection attacks
lies in the malicious inputs submitted to a web application that allows the
attacker to execute the malicious query and thereby, obtain some sensitive infor-
mation of user or database. We proposed a scheme, SQLshield, to prevent SQL
injection attacks on web applications. SQLshield inserts a random key in user
inputs. After the parse tree of an SQL query is formed, the inputs are brought
back from the tree and transformed to its original version by removing the ran-
dom key. Then, SQLshield puts this original data in the respective place-holders
in the query’s parse tree and sends it for execution to the database server. We
note that even if the attacker knows the random key, he cannot succeed in exe-
cuting a malicious query because the malicious inputs are randomized again and
the injected tokens are treated as invalid at the database server. Unlike other
schemes, SQLshield allows a legitimate user input containing any SQL com-
mand. We compared SQLshield with SQLrand, CANDID, SDriver and TAPS,
and showed that SQLshield performs better than others due to its strong defence
against SQL injection attacks.

References
1. The Open Web Application Security Project (OWASP), OWASP top 10 web appli-
cation security risks in year (2013). https://www.owasp.org/index.php/Top 10
2013-Top 10
2. Boyd, S.W., Keromytis, A.D.: SQLrand: preventing SQL injection attacks. In:
Jakobsson, M., Yung, M., Zhou, J. (eds.) ACNS 2004. LNCS, vol. 3089, pp. 292–
302. Springer, Heidelberg (2004)
3. Bisht, P., Madhusudan, P., Venkatakrishnan, V.N.: CANDID: Dynamic candidate
evaluations for automatic prevention of SQL injection attacks. ACM Trans. Inf.
Syst. Secur. 13(2), 1–39 (2010)
4. Bisht, P., Sistla, A.P., Venkatakrishnan, V.N.: TAPS: automatically preparing safe
SQL queries. In: Proceedings of the International Conference on Financial Cryp-
tography and Data Security, pp. 272–288 (2010)
5. Buehrer, G., Weide, B.W., Sivilotti, P.A.: Using parse tree validation to prevent
SQL injection attacks. In: Proceedings of the International Workshop on Software
Engineering and Middleware, pp. 106–113 (2005)
SQLshield: Preventing SQL Injection Attacks by Modifying User Input Data 205

6. Mitropoulos, D., Spinellis, D.: SDriver: Location-specific signatures prevent SQL

injection attacks. J. Comput. Secur. 28(3–4), 121–129 (2009)
7. General SQL parser implemented in JAVA. http://www.sqlparser.com/products.
php
8. Clarke, J.: SQL Injection Attacks and Defense, vol. 2. Elsevier publisher, USA
(2012)
9. Halfond, W.G., Orso, A.: Combining static analysis and runtime monitoring to
counter SQL-injection attacks. In: Proceedings of the Third International Work-
shop on Dynamic Analysis, pp. 22–28 (2005)
10. Martin, M., Lan, M.S.: Automatic generation of XSS and SQL injection attacks
with goal-directed model checking. In: Proceedings of the Conference on Security
Symposium, pp. 31–43 (2008)
11. Halfond, W.G., Viegas, J., Orso, A.: A classification of SQL-injection attacks and
countermeasures. In: Proceedings of the IEEE International Symposium on Secure
Software Engineering (2006)
12. McClure, R., Kruger, I.: SQL DOM: compile time checking of dynamic SQL state-
ments. In: Proceedings of the International Conference on Software Engineering
(ICSE 05), pp 88–96 (2005)
13. McDonald, S.: SQL Injection: Modes of attack, defense, and why it matters. White
paper (2002). GovernmentSecurity.org
14. Anley, C.: Advanced SQL Injection In SQL Server Applications. Next Generation
Security Software Ltd., White paper (2002)
15. McDonald, S.: SQL Injection Walkthrough. White paper, SecuriTeam, May 2002.
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
16. Antunes, N., Laranjeiro, N., Vieira, M., Madeira, H.: Effective detection of
SQL/XPath injection vulnerabilities in web services. In: Proceedings of IEEE Inter-
national Conference on Services Computing (SCC 2009), pp. 260–267. IEEE (2009)
17. Shahriar, H., Zulkernine, M.: Mitigating program security vulnerabilities:
approaches and challenges. ACM Comput. Surv. 44(3), 1–46 (2012). Article 11
18. Gould, C., Su, Z., Devanbu, P.: JDBC Checker: a static analysis tool for
SQL/JDBC applications. In: Proceedings of the International Conference on Soft-
ware Engineering (ICSE 2004) - Formal Demos, pp. 697–698 (2004)
19. Gould, C., Su, Z., Devanbu, P.: Static checking of dynamically generated queries in
database applications. In: Proceedings of the International Conference on Software
Engineering (ICSE 2004), pp. 645–654 (2004)
20. Maor, O., Shulman, A.: SQL injection signatures evasion. White paper, Imperva
(2002)
21. Xie, Y., Aiken, A.: Static detection of security vulnerabilities in scripting languages.
In: Proceedings of the USENIX Security Symposium, pp. 179–192 (2006)
22. Kiezun, A., Ganesh, V., Guo, P.J., Hooimeijer, P., Ernst, M.D.: Hampi: a solver
for string constraints. In: Proceedings of the International Symposium on Software
Testing and Analysis, pp. 105–116 (2009)
23. Halfond, W.G., Orso, A.: AMNESIA: analysis and monitoring for neutralizing
SQL-injection. In: Proceedings of the IEEE/ACM International Conference on
Automated Software Engineering, pp. 174–183 (2005)
24. Valeur, F., Mutz, D., Vigna, G.: A learning-based approach to the detection of
SQL attacks. In: Proceedings of the Conference on Detection of Intrusions and
Malware Vulnerability Assessment, pp. 123–140 (2005)
206 P. Mehta et al.

25. Baranwal, A.K.: Approaches to detect SQL injection and XSS in web applications.
Term Survey paper-EECE 571b, University of British Columbia (2012)
26. Security Compass. SQL Inject Me. https://addons.mozilla.org/en-US/firefox/
addon/sql-inject-me/
27. Larouche, F.: SQL Power Injector. http://www.sqlpowerinjector.com/