preventing sql injection attacks by automatic...

Scientia Iranica D (2019) 26(6), 3469{3484

Sharif University of TechnologyScientia Iranica

Transactions D: Computer Science & Engineering and Electrical Engineeringhttp://scientiairanica.sharif.edu

Preventing SQL injection attacks by automaticparameterizing of raw queries using lexical andsemantic analysis methods

S. Dolatnezhad Samarin and M. Amini�

Department of Computer Engineering, Sharif University of Technology, Azadi Ave., Tehran, P.O. Box 11155-8639, Iran.

Received 22 May 2017; received in revised form 20 June 2018; accepted 7 January 2019

KEYWORDSDatabase security;SQL Injection (SQLI);Intrusion detectionand prevention;Parameterized query;Semantic analysis.

Abstract. SQL Injection (SQLI) is one of the most important security threats toweb applications. Many techniques have been proposed for counteracting SQLI Attacks(SQLIAs); however, second-order attacks and the injection attacks that raise data-typemismatch errors have been ignored in most of them. In this paper, we propose a newanomaly-based method (deployed as a proxy between the application server and its databaseserver) for detection and/or prevention of SQLIAs without requiring any modi�cationto the source code of vulnerable applications. The majority of attacks, which lead to achange in the syntax of application queries, are identi�ed in the detection phase by lexicalanalysis of the queries. The remaining types of attacks, such as second-order attacks andattacks generating data-type mismatch errors, are prevented in the prevention phase, whereeach query is automatically converted to a parameterized query (before submitting to thedatabase) using a semantic analysis method.© 2019 Sharif University of Technology. All rights reserved.

1. Introduction

Nowadays, most organizations use web applications tocollect, store, process, and represent their requiredinformation using back-end databases. If an ap-plication does not preserve its security completely,intrusion to its back-end database can be performedeasily. OWASP is a non-commercial organization thathas been created to improve the security of applica-tions. This organization reports the 10 most commonvulnerabilities in web applications every three years.In its latest report [1], OWASP identi�ed injectionvulnerability as the most common security risk in webapplications. One type of injection vulnerabilities in

*. Corresponding author. Tel.: +98 21 66166656Email addresses: [email protected] (S.Dolatnezhad Samarin); [email protected] (M. Amini)

doi: 10.24200/sci.2019.21229

web applications is SQL injection (SQLI). The mainreason for this vulnerability is the use of dynamicqueries in applications. A dynamic query is a querythat is created during the application execution time byconcatenating some inputs (taken from a user) to therest of the query. An attacker can append SQL codesto the dynamic query, create their desirable query, andrun an SQLI Attack (SQLIA).

SQLIAs can be classi�ed from two di�erent per-spectives, namely the order of the attack and how theapplication responds to a malicious input. From the�rst perspective, we can classify attacks as the �rst-order and second-order. In the �rst-order attacks, theuser's input is concatenated to the query and when thedatabase executes the query, the attack is completed.Second-order attacks occur when the application storesuser's input in the database and uses it in anotherquery to complete the attack later.

Responses to a malicious input could be di�erentwith respect to the purpose of the attacker. The

3470 S. Dolatnezhad Samarin and M. Amini/Scientia Iranica, Transactions D: Computer Science & ... 26 (2019) 3469{3484

application may do an action (such as user authenti-cation), show some data to the attacker, show an errormessage, or do nothing. In many cases, an attacker useserror messages returned by the application and extractssome information from these messages. Database errormessages could be sorted into three groups [2], namelylogical errors, syntax errors, and data-type mismatcherrors. Attacks with the purpose of raising the data-type mismatch errors cannot be simply detected andrequire the query to be executed or having informationabout the data type of the input �elds in the query.In this paper, we focus more on the second-orderattacks and data-type mismatch errors, which are notconsidered in most of the existing solutions to SQLIAs.

Many techniques and frameworks have been pro-posed for detecting and preventing SQLIAs in theapplication level, database level, and proxy level;however, some of them need to change the sourcecode of applications and most of them ignore second-order attacks and injection attacks resulting in data-type mismatch errors. One of the best methods thatcan prevent SQLIAs completely is employing preparedstatements (parameterized queries). Some methodsuse this feature for preventing SQLIAs automatically.Thomas et al. [3], Bisht et al. [4], and Masri andSleiman [5] stated that a method needed to accessthe application source code that automatically replacedqueries with parameterized queries.

The proposed approach in this paper, similar tosome other related work, utilizes parameterized queriesto completely prevent SQLIAs. The main contributionof the proposed approach in contrast to other relatedapproaches such as [3-5] is that the parameterizedqueries are created automatically (by semantic analysisof the queries) in the middle of the application and thedatabase without interfering the functionality of theapplication or requiring any change in the applicationsource code.

The proposed method is a kind of anomaly-basedintrusion detection and prevention approaches. Thismethod consists of three phases: learning, detection,and prevention. In the learning phase, the pro�lesof legal queries are generated by lexical analysis andsyntactic structure of them. These pro�les are usedto detect attacks in the detection phase and to cre-ate parameterized queries in the prevention phase.Executing parameterized queries (instead of the rawones) prevents completing the attacks that do notdirectly change the structure of the queries, such as thesecond-order attacks. In preparing the parameterizedqueries, we can also easily detect the malicious queriesresulting in data-type mismatch errors without needingto execute the queries.

Another advantage of the proposed method is itse�ect on the performance of the application. Thismethod imposes negligible performance overhead in

the initial execution of the queries due to the creationof parameterized queries, but overall, it also improvesthe performance of the application using the preparedparameterized (or pre-compiled) queries.

In summary, the main contributions of the paperare as follows:

� The proposed approach is a new general approachwhich is application-independent. It works as aproxy and does not need the source code of theunder-protected applications (in fact, having thebinary code is su�cient). It can be used for dif-ferent applications written in di�erent programminglanguages;

� The proposed approach can detect and prevent allknown SQLIAs, especially the attacks that use data-type mismatch errors and second-order attacks be-fore delivering the query to the database server. Tothe best of our knowledge, the existing mechanismsare vulnerable to these two types of attacks;

� The proposed approach not only does not attenuatethe performance of the under-protected applica-tions, but also improves their performance after awhile.

The rest of this paper is organized as follows.Section 2 surveys the existing detection and preven-tion methods. We explain our proposed solution inSection 3 and evaluate its accuracy and overhead inSection 4. Finally, Section 5 concludes the paper.

2. Related work

Various defense techniques and frameworks have beenproposed for preventing SQLIAs in dynamic queries.

These techniques can be considered in three dif-ferent levels [6]:

� Application-level techniques, which are called de-fense coding.

� Database-level techniques, such as access control andstored procedures.

� Proxy-level techniques, such as intrusion detectionand �ltering tools.

Recently, some methods have been introduced forusing machine learning for huge amounts of data inlearning and detecting SQLIAs [7,8].

Employing some of these techniques is not asimple task; it is often done during the application de-velopment process and needs to change the applicationsource code, which is not always possible. Therefore,researchers try to propose methods to automate thesetechniques. For example, the proposed method byHa�z and Johnson [9] automatically converts the inputto a secure input in the application.

S. Dolatnezhad Samarin and M. Amini/Scientia Iranica, Transactions D: Computer Science & ... 26 (2019) 3469{3484 3471

Overall, automated methods for detecting andpreventing SQLIAs are based on two di�erent types ofanalysis, namely static and dynamic. By using staticanalysis methods, such as the ones proposed in [10-13], we can �nd and �x errors and SQLI vulnerabilitiesof the application, before deploying the application inits operational environment. These methods need tochange the source code of applications, while dynamicanalysis methods, such as the ones proposed in [14-16],detect SQLIAs at runtime and in the test phase of theapplication development process. These methods donot need to modify the application source code, andthe vulnerabilities found using these methods shouldbe �xed manually. Most of the existing methods, suchas [17-20], use a combination of these two methods fordetecting or preventing SQLIAs at runtime when theapplication is deployed in its operational environment.These methods use static analysis to analyze the sourcecode or equip the code (by making some changes) todetect or prevent SQLIAs at runtime.

Our proposed method in this paper detects andprevents SQLIAs at runtime. For this reason, in thispaper, we focus more on the techniques that couldbe used at runtime and are closely related to ourapproach. These techniques can be classi�ed into threecategories: grammar-based, query skeleton-based, andanomaly-based methods.

2.1. Grammar-based methodsIn this type of methods, detection or prevention ofattacks is performed according to the syntax of SQLstatements. The methods that use the parse tree datastructure or models (which are created based on theSQL grammar) can be placed in this category. Theparse tree is a suitable data structure for detectingSQLIAs. Because a minimal change in the structureof the query leads to a di�erent parse tree of the query,Su and Wassermann [21] added some meta-charactersto the query to specify the beginning and end of theinput values, and used an augmented grammar tocreate the parse tree of the query. At runtime, if theaugmented query was parsed correctly, it was benign;otherwise, it was malicious. Buehrer et al. [22] andBandhakavi et al. [23] used similar approaches in theirsystems. They created a benign sample of each queryin the application. At runtime, the parse tree of thegenerated query and the sample query were compared;if they matched, no attack was diagnosed and thequery was sent to the database. Halfond and Orso [19]used a �nite state machine to model queries in anapplication. The change from one state to another wasdone with respect to the SQL operators, keywords, anddelimiters. At runtime, the dynamic query traversedthroughout the model and if it violated the model, itwas deleted.

Grammar-based methods can detect all attacks

leading to change in the syntax of the query, but thesecond-order attacks and attacks raising the data-typemismatch errors cannot be detected. Furthermore, thistype of methods needs an analyzer (such as a parser) toanalyze the SQL queries, which have various grammarin di�erent DBMSs.

2.2. Query skeleton-based methodsIn query skeleton-based methods, a template or askeleton is generated for each query in an applicationthat is used for detecting attacks. If the template of thequery changes at runtime, the attack is detected. Thetemplate of the query is a query string in which all con-stant values are labeled or replaced by a placeholder.Lee et al. [24] used a function for removing attributevalues from the query string. This function removedvalues based on the single quotes existing in the query.As we know, numeric values do not need to have singlequotes, so their function does not work properly fornumerical entries. Kar and Panigrahi [25] created atemplate of the query according to a conversion table.Their approach computed the hash of the template asa digest of the query and used it for detecting attacks.The main problem of this approach is its weakness indetecting and preventing the second-order attacks.

2.3. Anomaly-based methodsAnomaly-based intrusion detection systems create apro�le of the normal behavior of users or applications.Anything outside the pro�le is considered as an attack.Valeur et al. [26], in 2005, proposed an anomaly-based intrusion detection system for databases. Theirapproach has been the basis of many studies in this�eld, such as [27-29]. Their system uses several modelsto characterize the pro�le of normal access to thedatabase. This approach can detect all attacks witha low rate of false-positive errors; however, in thismethod, it is still possible to do some of the SQLIAs.For example, attacks that raise data-type mismatch er-ror cannot be identi�ed using this method. Prabakar etal. [30], in 2013, proposed an anomaly-based preventionmethod that created pro�les for anomaly patterns andchecked the received query with them. If the querymatched an anomaly pattern, an attack was detected;otherwise, an anomaly score was calculated for it. Ifthe score was more than the prede�ned threshold, thequery was reported to the administrator.

3. Overview of the proposed approach

Our proposed solution is a kind of anomaly-basedintrusion detection and prevention methods. In thisapproach, the normal behavior is de�ned by collectionof information about the raw (benign) queries of theapplication. The information is extracted from eachraw query of the application in the learning phase andnamed as the pro�le of the query. The pro�le of a query


consists of the query identi�er and other informationabout the structure of the query such as the numberand type of its parameters.

After learning and in the deployment phase, if thereceived query is a legal query of the application, thecorresponding pro�le is found and other information inthe pro�le is checked. In fact, in this approach, anydeviation from the normal behavior is considered as anattack.

The structures of most of the malicious queriesdi�er from all the benign queries of the application.Therefore, by extracting the structures of benignqueries in the learning phase and storing them in acollection of normal query pro�les, malicious queriescould be detected.

After detecting a query as a benign one, theinformation in its pro�le is used to convert the queryto a parameterized format. Then, the parameterizedquery is sent to the database instead of the main rawquery. The purpose of creating the parameterizedquery, after the process of detection, is preventingattacks that do not change the structure of the queries.These attacks include second-order attacks and attacksthat try to create data-type mismatch errors to infersome information about the schema of the database.

3.1. Proposed architectureThe architecture of the proposed solution is illustratedin Figure 1 and contains the following components:

� Key generator module (lexical analyzer mod-ule): This module creates a key (a query identi�er)for each incoming query. The key is created usingthe lexical analysis of the query. In the learningphase, the generated key is stored in the knowledgebase at runtime, and the key is used to detectattacks and extract the required information fromthe knowledge base for possibly normal queries;

� Detection module: In the detection stage, thismodule searches the generated key for each incomingquery in the knowledge base. If it does not �nd thekey, the query is considered as a malicious one andblocked. Otherwise, the query is transmitted to theprevention module;

� Prevention module: This module is to preventattacks that are not diagnosed in the detection phaseand consists of two sub-modules:1. Semantic analyzer module: In the learning

stage, semantic analysis of each query is per-formed in order to extract the required infor-mation in creating a parameterized query in theprevention stage;

2. Parameterized query generator: In theprevention stage, according to the informationobtained in the learning phase, this moduleconverts the query to a parameterized one. Atthis stage, we can detect data-type mismatcherrors too.

� Knowledge base: The required information todetect and prevent attacks is stored in the knowledgebase. The information consists of the keys of thenormal queries and a sequence of required informa-tion to create parameterized queries at runtime.

According to the described architecture, our pro-posed process for detection and prevention of attacks isshown in Figure 2. As it is shown, this solution consistsof three phases: the learning phase, the detectionphase, and the prevention phase. Each of these phasesis described in more details in the rest of this paper.

3.2. Learning phaseThe power of an anomaly-based intrusion detectionsystem depends on the accuracy and completenessof the information obtained in the learning phase.

Figure 1. Architecture of the proposed system.


Figure 2. The process of detection and prevention of attacks in the proposed solution.

Hence, the learning phase is the most important onein the process of detection and prevention. At thisstage, all queries in the application that contain benigninput values are sent to the database in a protectedenvironment. The queries are captured in the middleof the way (from the application server to the database)in order to extract the required information and storeit in the knowledge base. The gathered informationis used during the process of detection and preventionto reduce the processing overhead at runtime. Thisapproach is applicable to the applications that havequeries with prede�ned structures. For example, con-sider an application allows its users to enter SQL codesin an input �eld. In this application, users can createany SQL commands. Hence, the learning phase cannotcreate a unique set of pro�les and this approach cannotbe leveraged in such applications.

The information obtained in this stage for a query(qi) of an application contains the following items:

� key(qi): The key of the query (a query identi�er);� I(qi): The number of the constant tokens in the

query that may contain user input;� DTj(qi): The data type of the j'th constant token.

The data type is needed for setting the type of theparameters (or arguments) in the template of theparameterized query.

� Qt(qi): The template of the query. The templateof the query is a query string in which the probableinput values are replaced by a placeholder.

To calculate the key, lexical analysis of the queryand to obtain other information, semantic analysis ofthe query are required.

3.2.1. Lexical analysisThe process of converting a query into a sequence oftokens is called lexical analysis of the query [31]. Theproposed detection method detects attacks by using thekey of the query created in the lexical analysis process.The key is constructed from the string of the querywith empty input �elds. In the learning phase, the keysare created for all queries in the application. SQLIAsmainly lead to a change in the string of the query. Atruntime, the query with �lled input is received in theproxy and the key of the received query is created usingthe lexical analysis process. Then, the key is searched


Figure 3. Tokens of a sample query.

Plainkey string: SELECT*FROMACCOUNTSWHE RENAME= ?ANDAGEBETWEEN?AND?;Key(query)= sha256(Plainkey string) = 3c27fdaffc69039ff80d3ddd6f684bd7f2e8 b3b 71fecc217f1097b9e117523ea

Box I

among the keys created in the learning phase. If thekey is found, the attack is detected.

Consider the following query as a sample query inan application. In this query, user input can deter-mine the name and age columns of a record in theaccounts table.

query= SELECT*FROM accounts WHERE name='goodUser'AND age BETWEEN 10 AND 50;

Key generation processFor generating a key for the above query, the followingsteps should be taken:

1. Perform the lexical analysis of the given query andobtain its tokens. The tokens of the above query areshown in Figure 3. Constant tokens in this queryare highlighted;

2. Replace the constant tokens with question mark (?);3. Uppercase the characters of the tokens and concate-

nate them together to create the new string;4. Remove all white spaces in the query string;5. Compute the hash of the key and store it in the

knowledge base.

Based on the mentioned steps, the key for theabove sample is shown in Box I.

3.2.2. Semantic analysisTo automatically create a parameterized query inthe prevention phase, we need additional informationabout the query. This information is derived from thesemantic analysis of the query in the learning phase.The semantic analysis is performed using the parse treestructure of the query. The main parts of the SQLstatements, which may contain the inputs, are SQLexpressions. In the proposed solution, expressions indi�erent parts of the query are obtained with the pre-order traversal of the parse tree. Then, the requiredinformation is extracted from the expressions. Theinformation extracted for each input (in the output ofthe semantic analysis process) has the same order asthe input in the query.

For example, the pre-order traversal of the follow-ing expression is shown in Figure 4.

Figure 4. Pre-order traversal of parse tree.

username=`good'jj`User' and age > 10

The semantic analysis of the expressions varieswith the type of the expression. The process startsby determining the operator and its operands in eachexpression. If the operands in an expression haveconstant values, they are examined in the semanticanalysis process. We categorize expressions into fourgroups based on the type of operator used in them.

1. Relational expressions: These expressions con-sist of two SELECT queries and use relationaloperators such as UNION. Semantic analysis ofrelational expressions is done by semantic analysisof their operands;

2. Computational expressions: These expressionscontain arithmetic operators (such as + or �) orconcatenation operator (such as jj). In this typeof expressions, the data type of each operand isdetermined with respect to the operator used inthe expression. In the following example, theinformation obtained for each constant value isspeci�ed.

expression E: `text'jj (1+2)DT1 (E) = StringDT2 (E) = NumericDT3 (E) = Numerictemplate (E) = ? jj (?+?)

3. Comparative expressions: The comparative


expressions contain comparison operators (such as>, = or Like). In some comparative expressions,in which one of the operands has a constant valueand another is a column of a table, we obtainthe data type of the constant value with queryingthe database. For example, information obtainedfrom the expression username = `gooduser' is asfollows.

expression E: username = `gooduser'DT1(E) = Stringtemplate (E): username = ?

4. Logical expressions: The expressions containinglogical operators (such as AND OR ) are logicalexpressions. Each operand in these expressionscan be a relational, computational, or comparativeexpression; thus. we need to analyze themseparately based on their type.

The semantic analysis in di�erent SQL commandsvaries with the grammar of the queries. In this paper,we explain the semantic analysis of the SELECT,UPDATE, INSERT, and DELETE statements that arecommonly utilized in web applications.

Semantic analysis of the SELECT statementThe SELECT statement is typically used in most of theapplications. We can use this statement in di�erentparts of the SELECT (such as the SELECT clause,FROM clause, or WHERE clause) and other com-mands. For semantic analysis of the SELECT query,all expressions in di�erent parts of the query must beextracted and processed in order. The grammar of thiscommand is shown in Figure 5.

In this �gure, the parts which are enclosed ina square may contain expressions. Thus, they mustbe extracted and analyzed in the semantic analysisprocess. Algorithm 1 describes how the semanticanalysis of the SELECT statement is done. This algo-rithm �rst checks whether the command is a relational

expression or not. If it is a relational expression, eachof the queries on the left and right operands mustbe extracted and analyzed separately. Otherwise, allexpressions in the query are extracted and analyzedrespectively.

For example, consider the following query:

query= SELECT namejj`,'jjlastname FROM(SELECT * FROM accounts,users WHEREusername=ùser id' and age BETWEEN 20 AND 50)

WHERE name LIKE àli%';

After the semantic analysis of this query, theinformation extracted from the SELECT clause will beas follows:

SELECT clause: namejj`,'jj lastnameDT1(SELECT clause)= StringTemplate(SELECT clause)= namejj?jjlastnameThe following information is extracted from the FROMclause:

FROM clause: (SELECT * FROM accounts,users WHERE username =`$user id'AND age BETWEEN 20 AND 50)

DT1(FROM clause)= StringDT2(FROM clause)= NumberDT3(FROM clause)= Numbertemplate(FROM clause): (SELECT * FROM accounts,

users WHERE username=?AND age BETWEEN ? AND ?)

The following information is extracted from the condi-tional WHERE clause:

WHERE clause: name LIKE àli%'

DT1(WHERE clause)= String

Figure 5. Grammar of the SELECT statement.


Algorithm 1. Semantic analysis of the SELECT statement.

Figure 6. Grammar of the UPDATE statement.

template(WHERE clause): name LIKE ?

Finally, the information obtained for the abovequery is as follows:

I(query)= 5DT1(query)= StringDT2(query)= StringDT3(query)= NumberDT4(query)= NumberDT5(query)= StringQt(query): SELECT namejj?jjlastname FROM(SELECT * FROM accounts, users WHERE username=?

and age BETWEEN ? AND ?)WHERE name LIKE ?;

Semantic analysis of the UPDATE statementThe UPDATE statement is used for assigning a newvalue to a column of a table in a database. Thesyntax of this command is shown in Figure 6. Inthis command, the input can be entered in the SETclause and WHERE conditional clause; therefore, weneed to extract these two clauses and analyze them in

order. In a SET clause, the left operand is a columnname or a list of column names and the right operandis only a constant value or a list of constant values.Hence, the data type of the constant value of the rightoperand should be same as the corresponding columnin the left operand and it is obtained by queryingthe database. The conditional WHERE clause isanalyzed similarly to the analyzing WHERE clause inthe SELECT statement.

Semantic analysis of the INSERT statementThe INSERT command is used for inserting one ormore rows in a table of a database. This command canselect some columns of a table and insert the valuesin them. In Figure 7, the syntax of this command isillustrated. As it is observed, the input can just appearin the VALUES clause. The VALUES clause can be aSELECT query, a set of constant values, or a set ofexpressions. The data type of the values is determinedbased on the data type of the corresponding column inthe query. If the names of the columns are not speci�edin the query, they should be obtained by querying thedatabase.


Figure 7. Grammar of the INSERT statement.

Figure 8. Grammar of the DELETE statement.

Semantic analysis of the DELETE statementThe DELETE command is used for deleting one ormore rows of a table. The conditional WHERE clausein this command, as illustrated in Figure 8, is theonly part of this command that may contain an input.Hence, in the semantic analysis process, we only needto analyze this part.

3.3. Detection phaseAfter completing the learning phase, the system can bedeployed in its operational environment. At this stage,when an application sends a query to the database,the query is captured in the middle of the way and akey is generated for it. Then, the detection modulesearches the key in the knowledge base. If the key isnot found, the query is not a legal or normal queryand an attack is detected. Otherwise, the query istransmitted to the prevention module (to prevent theattacks that do not change the syntactic structure ofthe query). In the detection phase, we can detect theattacks that change the syntax of the learned queries.For example, consider the following query as a legalquery of an application.

SELECT * FROM accounts WHERE username=`username0AND password = `password';

The key of this query (before hashing it) is as follows:

SELECT*FROMACCOUNTSWHEREUSERNAME=?ANDPASSWORD=?;

If the attacker enters `OR" =' as the username in the

above query, the generated key becomes as follows,which di�ers from the main key; thus, the attack isdetected and the query is blocked.

SELECT*FROMACCOUNTSWHEREUSERNAME=?ANDPASSWORD=?OR?=?;

When the attacker's input does not change thesyntax of the query (e.g., in second-order attacks),this module cannot detect the attack. Therefore, wetransmit the query to the prevention module. Theprevention module converts the raw query to a param-eterized query that results in preventing such attacksand other unknown attacks.

3.4. Prevention phaseAs mentioned before, in the prevention phase, thequery is converted to a parameterized query and sentto the database. Parameterizing the query or usinga prepared statement is a method that can preventSQLIAs, including second-order attacks and attacksraising data-type mismatch errors. Creating the pa-rameterized query from the pro�le of a query (which isformed in the learning phase) consists of two stages:

� Extracting input values: Input values are derivedby comparing the template of the query (which isobtained from the knowledge base) and the mainquery. The process of extracting inputs for a samplequery is shown in Figure 9;

� Creating parameterized query: After extract-ing all the inputs, the parameterized query is createdby using the information existing in the pro�le of thequery (obtained from the knowledge base). The pro-cess of creating a parameterized query is representedin Algorithm 2. In this algorithm, Qt(q) is thetemplate of the given query q, I(q) is the number ofinputs in q, DT (q) is a set containing all data types

Figure 9. Extracting input values of a sample query.


Algorithm 2. Creating the parameterized query from query q.

of inputs, and Inputs array is the set of all input val-ues. Each input value is set in the template based onthe corresponding data type, so we can also detectthe attacks raising data-type mismatch errors.

The following example shows how the parameter-ized query is created for the query shown in Figure 9.

Qt= SELECT * FROM accounts WHERE name=?AND age BETWEEN ? AND ?;

ps=prepareStatement(Qt);ps.setStringValue(1,`goodUser');ps.setNumberValue(2,10);ps.setNumberValue(3,50);ps.execute();

4. Evaluation and experimental results

In order to evaluate our approach, we developed aprototype of the proposed system (which was called

APQS -Automatic Parameterizing Query System). Weimplemented the system in Java and ran it on amachine with 4 GB RAM and 2.3 GHz CPU processor.Moreover, we used PostgreSQL 9.3.2 as a back-enddatabase server. The developed system is somewhatdependent on the DBMS, because it needs a parserwhich varies in di�erent DBMSs. However, it can beeasily improved to support other databases.

The main features of the proposed method indetection and prevention of SQLIAs in comparison withother methods are presented in Table 1. Our method isa combination of grammar-based, skeleton-based, andanomaly-based methods. The proposed method createsa pro�le for each query based on the grammar of thequery and the key of the pro�le is actually the templateof the query. However, the main mechanism used inits detection engine is based on the pro�le of the legalqueries, so we consider it as an anomaly-based method.

The techniques proposed to detect and preventSQLIAs are usually evaluated from two aspects: ac-

Table 1. The proposed method in comparison with other SQLI detection and prevention approaches.

Ref. Defensemechanism

Detectionapproach

Detectionlocationchanging

Changingsourcecode

Preventingdata typemismatch

error

Preventingsecond-order

attacks

Su and Wassermann [21] Detection Grammar-based Proxy X � �Buehrer et al. [22] Prevention Grammar-based Application X � �Bandhakavi et al. [23] Prevention Grammar-based Application X � �Halfond and Orso [19] Detection prevention Grammar-based Application X � �Lee et al. [24] Detection prevention Query skeleton-based Application/proxy X/ � � �Kar and Panigrahi [25] Detection prevention Query skeleton-based � � � �Valeur et al. [26] Detection prevention Anomaly-based Proxy � � �Proposed method Detection prevention Anomaly-based Proxy � X X


curacy rate of the detection and prevention, and theperformance overhead that the approach imposes onthe applications.

4.1. AccuracyFor measuring the accuracy of APQS in detection andprevention of SQLIAs, we considered a vulnerable web-based application written in PHP and extracted all thenormal queries (140 queries) employed in the appli-cation. The application did not validate any inputs;hence, all the inputs were vulnerable to SQLIAs. We�rst trained the system with these 140 normal queries,created a pro�le for each normal query, and stored themin a hash table.

Then, we generated a complete set of test casesand measured the accuracy of the system with them.The generated test cases were categorized into 10classes, which are shown in Table 2. For measuringFPR (detecting benign queries as malicious), we gen-

erated 140 benign queries with benign inputs (di�erentfrom the queries generated in the training phase).For measuring FNR (detecting malicious queries asbenign), we generated 1072 malicious queries.

Since there was no standard source for the testcases, we collected all attacks reported in the relatedarticles, books, and websites. We also used two au-tomated SQLI tools, namely Havij [32] and SQLMAP[33], to analyze our vulnerable Web-based application.We intercepted the URLs generated by these tools andextracted malicious inputs from them for reconstruct-ing successful attacks driven by these tools. Overall,we generated 1072 malicious queries among which 300were generated by employing the inputs extracted fromsuccessful attacks run by these tools.

After completing the process of learning, we sentback the benign and malicious queries in the test setto the database. The evaluation results are shownin Table 3. As it is observed, the system was able

Table 2. Di�erent types of SQLIAs.

Attack type Attacker's input Example

Tautology ' OR 'some thing'='some thing' --SELECT * FROM accounts WHERE username= '' OR

'some thing'='something' -- ';

Attack using comment admin'--SELECT * FROM accounts WHERE username='admin' --'

AND password='123';

Union attack ' UNION SELECT 1,2,3 ; --SELECT * FROM accounts WHERE username='' UNION

SELECT 1,2,3 ; --' AND password='123';

Piggy-backed queries ';DROP TABLE tablex; --SELECT * FROM accounts WHERE username='';DROP

TABLE tablex; --' AND password='123';

Attacks using groupby,orderby, having cluase

'GROUP BY 1,2,3 --SELECT * FROM accounts WHERE username=''GROUP

BY 1,2,3 --' AND password='123';

Alternate encodings'||chr(65 )||chr(68)||chr(77)

||chr(73) ||chr(78)||chr(29) --

SELECT * FROM accounts WHERE username=''

||chr(65)||chr(68)||chr(77)|| chr(73)

||chr(78)||chr(29) --' AND password='123';

Inference attackinput1= ' OR 1 = 1 -- and

input2= ' OR 1 = 0 --

SELECT * FROM accounts WHERE username= '' OR

1 = 1 --' AND password='123';

Second-order attacks Alice'' or username= '' adminINSERT INTO accounts(username, password)

VALUES('Alice'' or username= ''admin', 'pass');

Illegal/incorrect queries some stringsINSERT INTO accounts(username,password)

VALUES('ali','pass' ,'some strings');


Table 3. Accuracy of detection of attacks by APQS.

Attack type No. of queriesCorrect

detectionFPR FNR Preventing

attacksBenign queries 140 140/140 %0 %0 XTautologies 173 173/173 %0 %0 XAttack using comment 120 120/120 %0 %0 XUnion attack 430 430/430 %0 %0 XPiggy-backed queries 30 30/30 %0 %0 XAttacks using groupby, orderby, having cluase 20 20/20 %0 %0 XAlternate encodings 20 20/20 %0 %0 XInference attack 199 199/199 %0 %0 XSecond-order attacks 20 0/20 %0 %100 XIllegal/incorrect queries 60 60/60 %0 %0 X

Table 4. Detection accuracy of the method proposed by Buehrer et al. [22].

Attack type No. of queries Correct detection FPR FNR

Benign queries 140 140/140 %0 %0Tautologies 173 173/173 %0 %0Attack using comment 120 120/120 %0 %0Union queries 430 430/430 %0 %0Piggy-backed queries 30 30/30 %0 %0Attacks using groupby, orderby, having clause 20 20/20 %0 %0Alternate encodings 20 20/20 %0 %0Inference 199 199/199 %0 %0Second-order attacks 20 0/20 %0 %100Illegal/incorrect queries 60 46/60 %0 %23

to distinguish between benign queries and all otherattacks leading to change in the structure of the query.

The second-order attack did not change the struc-ture of the query. Thus, the detection component ofAPQS could not detect it. However, this attack wasprevented completely in the prevention phase. In theset of illegal/logically incorrect queries, seven queriescaused data-type mismatch errors. As previouslymentioned, this type of attack did not change thestructure of the query, but in the prevention phase,it was detected and prevented completely. The overallaccuracy of the detection component, using Eq. (1),was equal to 98.3% and the remaining 1.7% of theattacks were prevented to have no negative side e�ecton the database (in the prevention phase), althoughthey were not detected by the detection component.

AC =TP + TN

TP + TN + FP + FN: (1)

In the previous section, we described the process ofcalculating the key of a query in detail. The key wascomputed based on the grammar of SQL statementsand used for detecting attacks. To compare the detec-

tion accuracy of our method with methods using thegrammar of SQL statements, we tested and comparedour proposed method with the method proposed byBuehrer et al. [22] using the same train and test queries.Their method compares parse trees of each query beforeand after entering user inputs at runtime. If theymatch, no attack is detected. The results of this testare shown in Table 4. The results con�rm that themethod by Buehrer et al. cannot detect or prevent thesecond-order attacks and the attacks raising data-typemismatch errors. Also, its precision is 97.1%, which isless than the accuracy of our proposed method.

4.2. Performance overheadPerformance overhead, which was imposed by theproposed method on an application, could be measuredin terms of di�erent parameters in the detection andprevention stages. In fact, we evaluated the systemusing two di�erent scenarios. The measures consideredfor evaluating the system in these two scenarios are asfollows:� ddetect: Delay of detection stage;� dprevent: Delay of prevention stage;


� dpexec: Parameterized query execution time;� dexec: Normal query execution time.

To measure the performance overhead, we needto send a set of benign or malicious queries to thedatabase. The execution time of an SQL commandvaries in di�erent runs and depends on several factorssuch as the speed of the processor, the complexity ofthe command, the number of rows processed by thecommand, database load at the command executiontime, and the plan selected by the optimizer. Thus,in some circumstances, we need to run a commandmultiple times and consider the average time as thequery execution time. The query execution time alsodepends on the size of the value stored in the database.Thus, we created tables similar to those in our testapplication and inserted 1000 records in each of them.

4.2.1. First scenario: sending a query containingmalicious input to the database

By sending a malicious query to the database, if thesystem can detect the attack, the time overhead (ordelay) added to the application is shown as ddetect. Fordetecting an attack, the system only needs to calculatethe key and search it in the hash table; thus, thedetection time is much less than the query executiontime.

delay = ddetect � dexec:

To obtain the detection time, we sent 1,000 randomlyselected malicious queries to the database and com-puted the average detection time for each of them (eachquery was sent to the database 100 times). The averagedetection time for each query and the total averagedetection time are shown in Figure 10. As it is shown,the average detection time is trivial and equal to 0.667milliseconds.

It seems that the detection time depends on thenumber of tokens existing in the query. To evaluatethis hypothesis, we measured the detection time basedon the number of tokens in the query. We sorted thequeries based on the number of tokens in them (from7 to 72 tokens) and calculated the average detection

Figure 10. Attack detection time in di�erent test queries.

Figure 11. Attack detection time with respect to thenumber of the tokens existing in the query.

time for each of them. The detection time with respectto the number of the tokens in the query is shown inFigure 11.

As it is observed, the detection time is somewhatascending, although some cases do not follow the aboverule. This could be due to the mechanisms usedfor lexical analysis of the query. Typically, lexicalanalyzer uses regular expressions to tokenize the SQLstatements. The times of matching tokens with otherones are various. Thus, the detection time of a querynot only is a function of the number of tokens, but alsodepends on the type of tokens used in the query.

4.2.2. Second scenario: sending a query containingapparently benign inputs to the database

In this scenario, the query is converted into a parame-terized query. The overhead (or delay) imposed by thissystem is computed as follows:

delay = ddetect + dprevent + dpexec:

If the query is sent to the database for the �rst time(during a session), the parameterized query executiontime becomes greater than the normal query executiontime, i.e., delay > dexec. If the query is sent to thedatabase for the second time or more, the value ofdpexec is usually much less than dexec. Since executiontime of parameterized queries decreases signi�cantlyafter building the parse tree and query plan (forthe �rst time), and the overhead of detecting andpreventing attacks in the proposed approach is verylow, it is expected that the overhead added by thesystem be less than the query execution time (dexec),i.e., delay < dexec in this situation. In this condition,the system not only does not add any overhead tothe application, but also has a positive impact on theapplication performance.

To evaluate the impact of the system on theapplication performance, we sent a legal query to thedatabase 5 times and measured the query executiontime with and without APQS. The query execution


Figure 12. Comparing the query execution times with and without APQS.

Table 5. Overall query execution times with and without APQS.

Average attack detection time using APQS 0.667 ms

Average query execution time using APQS 2.442 ms

Average query execution time without using APQS 2.233 ms

times in these two cases are shown in Figure 12. Asit is observed, when the query is sent to the databasefor the �rst time, the query execution time is morethan the normal query execution time. By sendingthe query for the second time or more, the overheadbecomes less than the normal query execution time and34.7% improvement can be seen in this case.

To measure the average prevention time, wemeasured the average time for executing 100 legalqueries. Table 5 represents the average times requiredto execute the query (for the �rst time) using APQSand without using it. The overhead of using our systemis equal to 2.442 ms. Note that if we run the queriesfor the second time or more, the execution time wouldbe less than the values represented in this table incase of using APQS (similar to the one depicted inFigure 12).

In the prevention phase, one of the main factorsa�ecting the attack prevention time (in creating andexecuting the parameterized queries) is the number ofinput values in the query. To determine the variationof the query execution time with the number of inputsin the template of the query, we considered a simplequery and then, increased the number of entries in itfrom 1 to 10. Each of these queries was sent to thedatabase 100 times and the average execution time wascalculated for each of them. The obtained results areshown in Figure 13. As it was expected, by increasingthe number of inputs in the query, the execution timeof the parameterized query increased too.

In order to compare the performance of our

Figure 13. Required time to execute the parameterizedqueries with respect to the number of inputs in them.

method with similar methods, there is a trade-o�between the performance and accuracy of the methodin detecting attacks and using the opportunity ofpreventing unknown attacks. As shown in Table 1,and to the best of our knowledge, the existing methodscan neither detect attacks raising data-type mismatcherrors nor prevent the second-order attacks. In orderto make these improvements, the overhead of theproposed method is somewhat higher than those of theother similar methods.

Nevertheless, as observed in Table 5, the per-formance overhead of the method is insigni�cant andin the prevention phase, in some conditions (when aquery is executed more than one time), it helps toimprove the overall performance of the system. Inaddition, it should be noted that our code has not beenimplemented in the most e�cient mode. Certainly,e�cient implementation will reduce this overhead.


5. Conclusion

Most of the existing methods for detection or preven-tion of SQLIAs are not able to counteract all types ofSQLIAs (attacks described in Table 2), such as second-order attacks and the attacks that try to raise data-typemismatch errors.

In this paper, we have proposed a method fordetecting and preventing SQLIAs. In fact, SQLIAscan be classi�ed into the attacks that change thestructure of normal queries and the attacks that do notchange the structure (like second-order and mismatch-type error attacks). Our proposed method coulddetect all attacks changing the syntactical structureof the queries. For this purpose, in the learningphase (in which only the benign inputs were used inthe application), the structure of normal queries andauxiliary information (such as the data type of theinput) were extracted and pro�led in the system. Inthe detection phase, the malicious queries with di�erentstructures were identi�ed by comparing them with theexisting pro�les of normal queries. For the secondcategory of SQLIAs, in which the malicious inputsdid not modify the structure of the parse tree of anormal query, the described solution was not e�cient.For this type of attacks, we proposed a preventionmethod without the need to detect the attack. Tothis aim, each query was automatically converted toa parameterized query using the information existingin the pro�le of the corresponding normal query. Inthis situation, the malicious inputs could not a�ectthe normal behavior of the application, because inexecuting the parameterized queries, the parse treeof the query was constructed without considering thevalues of its parameters.

The main contribution of this paper is proposingan automated method to create parameterized queriesdynamically by semantically analyzing the raw queriessent from a vulnerable application. By creatingparameterized queries, we could prevent second-orderand unknown attacks, and detect/prevent attackscausing data-type mismatch errors without the needto execute the query. In the proposed method, wedid not need to change the application source code.Evaluation of the proposed approach in practiceshowed that the performance overhead imposed by thismethod was minimal and in some cases, it even led toimprovement in the performance of the application byparameterizing the queries.

References

1. Top 10-2017 Top 10, fhttps://www.owasp.org/index.php/Top 10-2017 Top 10g,Last accessed 26 Oct 2018.

2. Halfond, W.G., Viegas, J., and Orso, A. \A classi�ca-tion of SQL-injection attacks and countermeasures",

IEEE Int. Symp. on Sec. Softw. Eng., Arlington, VA,USA, pp. 13-15 (2006).

3. Thomas, S., Williams, L., and Xie, T. \On automatedprepared statement generation to remove SQL injec-tion vulnerabilities", Info. Softw. Technol., 51(3), pp.589-598 (2009).

4. Bisht, P., Sistla, A.P., and Venkatakrishnan, V.N.\Automatically preparing safe SQL queries", Int.Conf. on Financial Cryptography and Data Security,Springer, Berlin, Heidelberg, pp. 272-288 (2010).

5. Masri, W. and Sleiman, S. \SQLPIL: SQL injectionprevention by input labeling", Secur. Commun. Net-works, 8(15), pp. 2545-2560 (2015).

6. Clarke-Salt, J., SQL Injection Attacks and Defense,Syngress Publishing, 1st edition (2009).

7. Uwagbole, S.O., Buchanan, W.J., and Fan, L. \Anapplied pattern-driven corpus to predictive analyticsin mitigating SQL injection attack", 7th. Int. Conf. onEmerging Security Technologies, pp. 12-17 (2017).

8. Ross, K., Moh, M., Moh, T.S., and Yao, J. \Multi-source data analysis and evaluation of machine learn-ing techniques for SQL injection detection", 2018 An-nual ACM Southeast Conf. (ACMSE '18), Richmond,Kentucky, p. 1 (2018).

9. Ha�z, M. and Johnson, R. \A security oriented pro-gram transformation to add on policies to preventinjection attacks", 2nd. Workshop. on RefactoringTools (WRT'08), Nashville, Tennessee, p. 12, ACM(2008).

10. Medeiros, I., Neves, N., and Correia, M. \Detectingand removing web application vulnerabilities withstatic analysis and data mining", IEEE Trans. Rel.,65(1), pp. 54-69 (2016).

11. Damiano, M.D., Lovato, A., Macedonio, D., Spiridon,C., and Spoto, F., Boolean Formulas for the StaticIdenti�cation of Injection Attacks in Java, In: Davis,M., et al. (Eds.) LPAR-20 2015. LNCS, 9450, pp.130145, Springer, Heidelberg (2015).

12. McClure, R.A. and Kruger, I.H. \SQL DOM: compiletime checking of dynamic SQL statements", 27th Int.Conf. on Softw. Eng., Missouri, USA, pp. 88-96. ACM(2005).

13. Fu, X., Lu, X., Peltsverger, B., Chen, S., Qian,K., and Tao, L. \A static analysis framework fordetecting SQL injection vulnerabilities", 31st Annu.IEEE Int. Computer Software and Applications Conf.(COMPSAC 2007), 1, pp. 87-96 (2007).

14. Ceccato, M., Nguyen, C.D., Appelt, D., and Briand,L.C. \SOFIA: an automated security oracle for black-box testing of SQL-injection vulnerabilities", 31stIEEE/ACM Int. Conf. on Automated Software Engi-neering, pp. 167-177, ACM (2016).

15. Kosuga, Y., Kono, K., Hanaoka, M., Hishiyama, M.,and Takahama, Y. \Sania: Syntactic and semanticanalysis for automated testing against sql injection",23rd Annu Computer Security Applications Conf. (AC-SAC 2007), Miami, FL, USA, pp. 107-117 (2007).


16. Khalid, A. and Yousif, M.M. \Dynamic analysis toolfor detecting SQL injection", Int. J. Comput. Sci. Inf.Secur., 14(2), pp. 224-232 (2016).

17. Choudhary, S., Jain, A.K., and Kumar, A. \Modelquery, tokenization and character matching: A com-bined approach to prevent SQLIA", Int. J. Comput.Appl., 162(9), pp. 13-18 (2017).

18. Wang, Y., Wang, D., Zhao, W., and Liu, Y. \DetectingSQL vulnerability attack based on the dynamic andstatic analysis technology", 39th Annu. IEEE Int.Computer Software and Applications Conf. (COMP-SAC 2015), 3, pp. 604-607 (2015).

19. Halfond, W.G. and Orso, A. \AMNESIA: analysis andmonitoring for NEutralizing SQL-injection attacks",20th IEEE/ACM Int. Conf. on Automated SoftwareEngineering, Long Beach, CA, USA, pp. 174-183(2005).

20. Jang, Y.S. and Choi, J.Y. \Detecting SQL injectionattacks using query result size", Comput. & Secur.,44, pp. 104-118 (2014).

21. Su, Z. and Wassermann, G. \The essence of commandinjection attacks in web applications", Conf. of Rec.33rd ACM SIGPLAN-SIGACT Symp. on Principlesof Programming Languages (POPL06), New York, NY,USA, pp. 372-382 (2006).

22. Buehrer, G., Weide, B.W., and Sivilotti, P.A. \Usingparse tree validation to prevent SQL injection attacks",5th Int. Workshop on Software Engineering and Mid-dleware, pp. 106-113, ACM (2005).

23. Bandhakavi, S., Bisht, P., Madhusudan, P., andVenkatakrishnan, V.N. \CANDID: preventing sql in-jection attacks using dynamic candidate evaluations",14th ACM Conf. on Computer and CommunicationsSecurity, pp. 12-24, ACM (2007).

24. Lee, I., Jeong, S., Yeo, S., and Moon, J. \A novelmethod for SQL injection attack detection based onremoving SQL query attribute values", Math. Comput.Model., 55(1-2), pp. 58-68 (2012).

25. Kar, D. and Panigrahi, S. \Prevention of SQL Injectionattack using query transformation and hashing", 2013IEEE 3rd Int. Advance Computing Conf. (IACC), pp.1317-1323 (2013).

26. Valeur, F., Mutz, D., and Vigna, G. \A learning-basedapproach to the detection of SQL attacks", 2nd Int.Conf. on Detection of Intrusions and Malware, andVulnerability Assessment, Vienna, Austria, pp. 123-140 (2005).

27. Kiani, M., Clark, A., and Mohay, G. \Length basedmodelling of HTTP tra�c for detecting SQL injec-tion attacks", RNSA Security Technology Conf., Mel-bourne, Australia, pp. 67-78 (2007).

28. Vigna, G., Valeur, F., Balzarotti, D., Robertson,W., Kruegel, C., and Kirda, E. \Reducing errorsin the anomaly-based detection of web-based attacksthrough the combined analysis of web requests andSQL queries", J. Comput. Secur., 17(3), pp. 305-329(2009).

29. Kiani, M., Clark, A., and Mohay, G. \Evaluationof anomaly based character distribution models inthe detection of SQL injection attacks", 3rd IEEEInt. Conf. on Availability, Reliability and Security(ARES'08), pp. 47-55 (2008).

30. Prabakar, M.A., Karthikeyan, M., and Marimuthu, K.\An e�cient technique for preventing SQL injectionattack using pattern matching algorithm", 2013 Int.Conf. on Emerging Trends in Computing, Communi-cation and Nanotechnology (ICE-CCN), pp. 503-506(2013).

31. Levine, J., Flex & Bison: Text Processing Tools, 1stEd., OReilly Media, Inc. (2009).

32. Havij Advanced SQL Injection, http:itsecteam.com/products/havij-advanced-sql-injection/, Last accessed25 Oct (2018).

33. Automatic SQL Injection and Database Takeover Tool,http://sqlmap.org/, Last accessed 25 Oct 2018.

Biographies

Somayeh Dolatnezhad Samarin received her MScdegree in IT Engineering from Sharif University ofTechnology, Tehran, Iran. Currently, she is PhDcandidate in the Department of Computer Engineeringat Sharif University of Technology, Tehran, Iran, do-ing research on computational integrity of outsourcedcomputations. Her research interests are databasesecurity, cloud computing security, secure delegationof computation, and cryptography.

Morteza Amini received his PhD in Software Engi-neering (with specialty in Data Security) from SharifUniversity of Technology. He is currently an AssistantProfessor in the Department of Computer Engineering,Sharif University of Technology, Tehran, Iran. He isone of the leaders of Data & Network Security Lab(DNSL) in this department. His research interestsinclude database security, access and information owcontrol, intrusion detection and alert correlation, andmobile devices security.

preventing sql injection attacks by automatic...

Documents