Web Application Reinforcement via Efficient Systematic Analysis and Runtime Validation (ESARV)

ABSTRACT


INTRODUCTION
Web applications are widely used due to providing accessibility and convenience. Their vast usage makes them a suitable target for an attacker; therefore preserving their security becomes essential. Despite the significance of web application security, less attention has been given in this area and the reasons can be: they are written by developers that have less programming and security skills, some web applications are produced by integrating works from several developers, so reviewing and verifying the code completely is not always possible, and finally, the developers are asked to focus on functionality rather than security; therefore we might have insufficient input validation [1]. As a result, although we have been given security patterns and guideline such as the ones introduced in [2] that can help standardize the design and development of the security architecture, but unsecure web applications still exist. Furthermore, security experts could also use Honeypots [3] for monitoring various attacks in web applications and collecting information in order to boost security. Different types of attacks exist for web applications and according to OWASP Top Ten in 2017 [4], SQLIA has the highest frequency among them all. This shows the significance of securing web applications and their data against this frequent attack. SQLI occurs when an attacker attempts to inject code via the input and change the semantic of the intended query. SQLIAs have different types: tautology, illegal/logically incorrect, union, piggy backed, blind injection, timing attacks, alternate encoding and Stored Procedure (SP). Here we will give an example of tautology (for more information please refer to [5]- [6]). Consider a login  [19] output the results of the attacks, SAFELI generates test cases according to the constructed abstract syntax tree of each hotspot (a spot in a web application that has interaction with the underlying database). Success in these tools depends on the completeness of the injected attacks, whereas no web application modification is required. SecuBat [20] is also a web application scanner that identifies SQLI and Cross-Site Scripting (XSS) vulnerabilities; therefore it is suitable for securing the web application.
Prepared statements, if properly used can also be a solution to reduce SQLIAs and have no overhead for dynamic statement analysis. These parameterized statements, are prepared SQL templates executed with high efficiency. SecurePHP [21], [22], and SQLPIL [23] attempt to find the vulnerable queries and use prepared statements instead. While [22] and SQLPIL automatically replace the vulnerable queries with the safe ones, SecurePHP requires the developer's effort.

Dynamic
Dynamic techniques perform all the demanded operations at runtime. The introduced techniques consider dynamic queries and use a runtime generated model for SQLIA detection, while having the overhead of runtime model generation.
SQLGuard [24], CANDID [25], and DSD [26] compare the actual and runtime parse trees at runtime so that in case of mismatch (SQLIA), the query would not be executed. SQLGuard partially covers dynamic queries, and its shortcomings are not being capable of identifying SP attacks [10] and the need for code modification. On the other hand, CANDID requires no manual code modification and partially identifies the attacks. Finally, DSD demands no access to the source code, while having a low false positive rate [26].

Combinational
These techniques contain two phases named static and dynamic. Although the operations fulfilled in the static phase have no overhead at runtime, success depends on the accuracy of this phase.
SQLrand [27] is based on randomization and appends a key to SQL standard keywords in the static phase. Since the key is not known by the attacker SQLIAs are identified. At runtime, the proxy derandomizes the query and if all the keywords contain the key, the query is sent with standard keywords to the database for execution. Advantages of SQLrand are performing de-randomization inside the proxy and hiding the database errors via the proxy. In contrast, the security of SQLrand depends on the security of the key and it's not capable of identifying illegal/logically incorrect, SP, and alternate encoding attacks [5].
SQLiGoT [28] and SQLiDDS [29] have a training phase; therefore their accuracy depends on the percentage of training samples and fine tuning of the training parameters. Using graph of tokens and Support Vector Machine (SVM), SQLiGoT normalizes the queries into a sequence of tokens and generates a weighted graph from the tokens. After that, it trains an SVM classifier using the centrality measure of nodes and finally at runtime, malicious queries are identified by means of the classifier. SQLiDDS requires no source code access and uses clusters of injected structures for identifying SQLIAs. In the offline phase the collected SQLIAs are transformed into a text form so that document similarity measurement is simplified. Then, they are grouped into clusters based on their document similarity and attack vectors in each cluster are merged into a document. At runtime, SQLiDDS detects the attacks by comparing document similarity of an incoming query with these documents according to rejection and suspicious thresholds.
Model construction techniques also lie in the combinational group. In the static phase, a model indicating all the valid queries of each hotspot is created and at the second phase, the runtime queries are examined to see whether they match their corresponding model or not. If not, the query would not be executed and SQLIA is prevented. SP attacks and dynamic queries are an issue in these techniques. The models used in AMNESIA [30], SQLCHECK [31], [32], SQLProb [33] and [34] respectively are Non-Deterministic Finite Automaton (NDFA), augment queries with key-marked inputs, SQL-graph, parse tree, and attribute removed queries. AMNESIA adjusts the web application by inserting a call to the runtime monitor before the query execution. After that, if the automaton accepts the runtime query, it would be executed. In SQLCHECK valid queries are those parsed by the augment grammar and sent without the keys to the database for execution. SQLCHECK's security depends on the security of the key. Furthermore, it requires manual code modification for inserting keys in the queries; therefore incompleteness is an issue. [32] requires no code modification which will spare money and time. Furthermore, by using SQL-graph only the queries that are supersets of other queries are inspected for compatibility of their static and dynamic SQLfinite state machines. It should be mentioned that [32] has also used parallel implementation in order to decrease runtime execution. SQLProb extracts inputs at runtime so that they could be validated by the output of the Parse Tree Generator, and executed if normal. SQLProb requires no code modification, is independent of the web application's programming language, and is capable of identifying all SQLIAs. On the other hand, it's limited to Mysql database [35] and the main causes of delay are query alignment, parse tree generation, and user input validation. Finally, authors in [34] use the opinion of Removing Attribute Values (referred to as RAV). For SQLIA detection, the two extracted models are compared via XOR and if the result of the comparison is zero the query is safe to be executed. Simplicity is the advantage of this method, while its disadvantage is performing unnecessary inspections at runtime which leads to overhead increase. Taint propagation is another technique that can be used to secure web applications. The main idea is that any variable which can be changed by the user is tainted and if used in execution of sensitive functions, a security breach may occur [36]. Here we will introduce three of these techniques that are capable of identifying all types of SQLIAs. WebSSARI [37] uses static analysis for inspecting tainted flows against preconditions of sensitive functions. During the analysis, WebSSARI suggests sanitization functions for those points where the preconditions are not satisfied and automatically inserts runtime guards in the vulnerable parts of code. Although being effective, WebSSARI has some disadvantages, it requires some information provided by the developer [38] and cannot remove SQLI vulnerabilities, but only lists the inputs as black or white [39]. WASP [40] and IDL [41] are based on positive tainting and perform automatic syntax aware validation. That is, the query is tokenized into a sequence of SQL keywords, operators, and literals. Then if all of the tokens except the literals are made from trusted data, the query is safe for execution. WASP and IDL require transformation, the former on the bytecode and the latter on the source code. WASP demands to specify trusted external data sources because they are not hard coded in the application and if not specified, false positives occur. Furthermore, at runtime IDL compares the query result size of the runtime and actual query via the usage of Equivalence and Largest Selectivity algorithm [42]. IDL requires developer intervention in some conditions and generates false positives in queries with multiple tables or very high complex "WHERE" clause.

PROPOSED METHOD
Our proposed method is implemented in a tool named ESARV (Figure 1), to automate all the operations, and facilitate its usage. Figure 1. Architecture of ESARV [43] As shown in Figure 1, ESARV is capable of reinforcing Java-based web applications and their underlying databases against SQLIAs. This tool is based on systematic analysis and runtime validation and contains two phases named static and dynamic. The main components of ESARV are Analysis, Process, and Validation. The Analysis component is an introduction to achieve the main objective of our method in the other two components that perform the basic task. The input of ESARV is the original web application that enters the Analysis component and the output is the reinforced form of the input which exits the Process component. The overall goal in the static phase is generating the reinforced form of the original web application, which requires constructing models and gathering information for the latter phase that aims to detect and prevent SQLIAs.
The static phase which is in charge of systematic analysis contains the Analysis and Process components and its operations can be summarized as follows: 1. Generating the Control Flow Graph (CFG) to indicate the structure of the code. On the other hand, the dynamic phase is in charge of runtime validation and contains the Validation component in which both validation and dynamic model construction will occur. The operations of this phase, as stated below, are repeated until either an SQLIA is detected or no attack has taken place and the runtime query is safe for execution. These operations can be summarized as follows: 1. Checking the input location based on the information gathered in the static phase.
2. If the result of the previous step is positive or in other words, the query is valid up to now, the dynamic model is gradually constructed by means of our new technique. Each of the main components in ESARV would be explained in detail in this section.

Analysis
The Analysis component performs the first two steps of the static phase mentioned before. This main component is used for extracting information for our detection and prevention technique. The symbols used in this section are shown in Table 1. Table 1. Symbols used in reaching definition analysis

Symbol Definition Entry
The entry point in the CFG S A basic block in the CFG P A member in the set of predecessors (comes before S in the CFG) The set of all definitions that are assigned to `variable y As we can see in Figure 1, the Analysis component contains two subcomponents named Extract CFG and DFA. For both of these subcomponents we have used the facility that Soot (http://www.sable.mcgill.ca/soot/) [44] provides. As mentioned earlier, our method is based on systematic analysis and should be performed on a model that is constructed from the code. For this purpose, we extracted a CFG which will be used inside the DFA section in order to gather the information required for producing the validation code (for more information on CFG and DFA please refer to [45]). Based on our goal, we have used reaching definitions for DFA. According to [45] this technique is defined as follows:

Definition1. It is said that a definition d reaches a point p if there is a path from the point immediately following d to p, such that d is not "killed" along that path. A definition of a variable x is killed if there is any other definition of x anywhere along the path.
Reaching definition analysis as shown in equations (1) to (5) [45] is a forward data flow framework with the data flow values of definitions.

OUT[S] = GEN[S]  (IN[S] -KILL[S])
(3) (5) In this technique, four sets are computed for each node. GEN and KILL are the two local sets which are used for computing the global IN and OUT sets. For convenience, reaching definitions can be stored in the form of UD chains, where the use (U) of a variable and all the definitions (D) that can reach that use are considered. In our method, all these UD chains should be computed and propagated until the hotspot is reached. The hotspot is a use of the related variable(s) inside the query and all the definitions that reach that variable(s) in the hotspot are the definitions that we are looking for in order to produce the validation code required for reinforcement. Using Soot, we have computed the UD chains of the corresponding variable(s) in the hotspot. These chains, which are the results of DFA, are then given to the Process component for further inspection.

Process
The Process component performs steps three to five of the static phase mentioned in section 3 and contains three subcomponents as shown in Figure 1. This basic component of the static phase is responsible for generating the reinforced form of the original web application. For this purpose, it produces the required validation code according to the CFG, analysis results, hotspot type, and our detection and prevention technique and then transforms the web application accordingly. The first action is identifying the hotspots through traversing the CFG and this is performed by the Identify Hotspot subcomponent. In this part, locations in the CFG that contain statements like executeQuery and executeUpdate are identified as hotspots. After that, the query or the variable(s) of the related hotspot could be accessed according to the results of DFA. The policy of the Extract Validation Code subcomponent for generating the proper validation code based on our detection and prevention technique varies according to the three query types mentioned below: 1. Containing no input (constant). 2. Containing input and having a clear structure at compile time (static). In the UD chains of this type of query, each use has only one reaching definition; therefore, we can obtain the structure of the valid query and input locations by propagating the definitions. 3. Containing input and having a structure that is not clear until runtime (dynamic). In the UD chains of this type of query at least one use has more than one reaching definition; therefore different inputs, result in different queries at runtime. One of the specifications of our proposed method is gathering as much information as possible in the static phase in order to lower the runtime overhead. In addition to the hotspot type, another important part of this information is related to input locations. These locations are detected via our new policy which is based on the symbols demonstrated in Table 2. We have divided the query into three elements: input, containing input and constant as follows: 1. Input: An element only containing functions related to receiving inputs that we indicate it with i and its definition is: In this definition, inputFunction is a symbolic method used for receiving user inputs such as getParameter and getAttribute in JavaServer Pages (JSP).
2. Contains input: An element with an i element on the Right-Hand Side (RHS) either direct or indirect that we indicate it with ci and its definition is: 3. Constant: An element that contains constants on the RHS either direct or indirect that we indicate it with c. A constant might be used for computing input locations and its definition is: We know that each definition in a UD chain contains a LHS and a RHS which based on the introduced elements can have different conditions where order is important. For identifying input locations, the information related to query elements could be either needed or not depending on their location; therefore we define them as follows: 1. Needed: An element which according to its position, its information is needed for extracting input locations. We indicate it with n and its definition for variables and constants is: Identifying the input locations, only requires the n elements, whereas preserving the query structures intended by the developer, requires all the query elements whether n or nn. This information will be used in our new detection and prevention technique with the pseudocode given in Figure 2.  [43] In addition to the queries intended by the developer and the input locations, the validation code might contain static variables and certainly a call to the validation function before the execution of the query. These transformations vary depending on the type of the query mentioned earlier in this section. A constant query has no possibility of SQLI and requires no further action due to input absence and identical static and dynamic models. On the other hand, when we have a static query with a clear structure at compile time the information given from the previous components needs to be processed. For this purpose, we use the UD chains of the variable(s) related to the hotspot, the CFG of the web application, our policy for identifying input locations, and also our detection and prevention technique; hence according to them, the validation code required for the corresponding hotspot is produced and passed to the next component for transformation. For dynamic queries which are the complicated form, more process is required. Since different inputs create diverse queries the validation code needs to be flexible in order to cover this type of queries. In this condition, beside transformations required for the hotspot (like the static form) some transformations might be required for the variables that have different values according to user inputs.
For securing the web application in the static phase, the final action of our proposed method is transforming it and producing the reinforced form. The validation code generated at the Extract Validation Code subcomponent is given to the Transform subcomponent for insertion in the related positions of the original web application. For instance, before the query is executed a condition is added and our validation method checks whether the static and dynamic models are identical based on the input locations. If so, the query would be safe for execution, while on the opposite side, SQLIA has taken place and an exception is thrown. For transformation, we have used the facility that Soot provides and reinforced the web application according to our demands. This reinforced web application which is the output of the first phase, will be used in the dynamic phase. The pseudocode of the Process component is shown in Figure 3.

Validation
This component of the dynamic phase, detects and prevents SQLIAs according to the information gathered in the previous phase. The Validation component as shown in Figure 1, contains two subcomponents named Check Validation and Construct Dynamic Model.
At runtime, the HTTP request containing user inputs is sent to the reinforced web application and before the query is sent to the database for execution the Validation component processes the request to check whether its valid or not (Figure 4). The Check Validation subcomponent uses the runtime query and the static information to check the validity of user inputs. This inspection is done for each input in the query and one of the three conditions mentioned here might occur.
1. Valid input: In this condition, the related input will be removed and the dynamic phase operations will continue. 2. Attack input inside one of the internal inputs: In this condition, the related input will also be removed. But, due to the changes made to the structure of the query, the next input will not be in its place, so before further inspections the injection will be identified. As a result, the query will not be executed, hence SQLIA is prevented. 3. Attack input inside the last input: This condition occurs when the attack is not identified in one of the internal steps. Thus, the entire dynamic model is constructed and a final check is required. For this purpose, the equality of the related static (from the static phase) and dynamic (from the dynamic phase) models is checked. As a result, due to the changes made by the attacker, the structure of the models are not identical; therefore the query is malicious and will not be executed. The Construct Dynamic Model subcomponent is in charge of constructing the dynamic model gradually by means of our new technique. Depending on the type of the input, this subcomponent will perform one of the following methods: 1. String: The input value which is inside the single quote operators will be removed and if the input contains single quote as a value it will be removed like the other characters until the single quote operator it reached. In order to preserve the query intended by the developer, the LIKE clause inside a query requires special care, due to the fact that the user input might be placed beside a pattern. In this condition, the user input will be a portion of the string inside the single quote operator not the whole. 2. Numeric: The input value is replaced with a space that shows the location of the input and the value is removed until it contains valid characters for various types of numbers. After introducing our proposed method thoroughly, in the next section we will demonstrate the experimental results and compare ESARV with other combinational techniques.

EXPERIMENT AND EVALUATION
In order to evaluate ESARV and show our expectations in practice we used the test suite of AMNESIA [30] which contains five web applications with different sizes as shown in Table 3. This table indicates the size of each web application in Line Of Code (LOC), and gives a brief description for each of them. This test suite also contains two types of datasets named attack and non-attack for each web application. To preserve the full automatic characteristic of the testbed the attacks include different patterns of SQLIAs except those that require human intervention and interpretation such as second-order injection. On the other hand, the non-attack dataset contains legitimate inputs that although containing no SQLI can cause failure in simple detection techniques. For evaluation, we have used four criterions named performance, accuracy, effectiveness, and deployment requirements. These criteria are used to compare ESARV with other combinational techniques introduced in section 2.3 (these experiments are an extention of our thesis work [43]). All of the experiments have taken place on a system which had an Intel Core i7-2600 3.4GHz with Windows 7 Ultimate SP1 OS and 8GB RAM. In this section, we will explain each criterion in detail and discuss the results thoroughly.

Performance
This criterion is used for measuring the runtime overhead. For this purpose, the non-attack dataset is used for accurate measuring of performance since maximum inspections are performed in this condition. ESARV stops whenever an injection occurs without performing further inspection and only traverses a small fraction of the query. While for RAV [34], the required inspections do not differ whether the input is an attack or not, the whole runtime query needs to be traversed. Since attackers often try to inject through the IJEEI ISSN: 2089-3272 

Web Application Reinforcement via ESARV (Zeinab Lashkaripour)
373 initial inputs so that the later parts of the query are commented (by --, and /* multiline */ in MySQL and SQL Server) with no impact, RAV performs unnecessary inspections whereas ESARV speeds up detection. Figure  5 illustrates the average runtime overhead for the evaluated methods and when none of the methods is used for securing the web applications respectively. In this experiment, the non-attack dataset is used on the original web application and the time is measured by means of Apache JMeter (an open source software designed to load test functional behaviour and measure performance). After that, the same dataset is used on the web application that is secured with one of the methods under test, and again the time is measured. The difference between these two (the None row and the other two rows) is the actual overhead of the method. Figure 5. Average runtime overhead [43] As expected, Figure 5 confirms that ESARV has a lower overhead in comparison to RAV and this difference in performance would be more noticeable in cases that the queries are more complex or even more in number. In order to compare the methods accurately and specify the efficient method, we have shown the percentage of overhead and performance in Table 4. Maintaining the security of a web application with the least overhead is essential and between the methods under test ESARV has accomplished it. The average speed improvement in ESARV in comparison to RAV which is a simple method, is 5.32%. These results confirm that the difference in performance between ESARV and other combinational methods that are more complicated than RAV will surely be significant.

Accuracy
Accuracy is evaluated by measuring false positive and false negative (Table 5). For the former we apply the non-attack inputs to see if the method mistakenly prevents their execution, and for the latter the attacks are used on the secured web application to determine the ones mistakenly executed. The legitimate section of Table 5 shows that among the total number of legitimate inputs how many were executed correctly along with the error rate. The attack section also shows how many of the attacks were prevented safely along with the detection rate.
The results show that ESARV has no error rate in comparison to RAV and also identifies and prevents all of the attacks correctly. The first is due to the fact that our method would not prevent the execution of legitimate inputs containing the value ' (not the operator ') and consider them as non-attack inputs. On the other hand, the lower detection rate in RAV is due to not supporting numerical inputs and being dependent to input type.

Effectiveness
A technique has a better effectiveness whenever more attacks are detected. In this section, we have compared the combinational techniques based on their capabilities against various types of SQLIAs as indicated in Table 6. This table contains three different symbols: '-' as impossible, '+' as totally possible, and '~' as partially possible. In Table 6 we have sorted the techniques so that the least supportive one is at the top of the Based on this we can classify the combinational techniques as shown in Figure 6, into three levels of effectiveness. As the colors and the name of the levels illustrate, the first level has the highest effectiveness.  Figure 6. Effectiveness classification

Deployment Requirements
Last but not least, in Table 7 techniques are sorted according to their deployment requirements, and the best technique is located at the bottom. The considered factors are whether any code modification is required by the developer or not, if the detection and prevention are performed automatically or semiautomatically, and finally, if any additional infrastructure is required. The best techniques are ESARV and AMNESIA that require no manual code modification, perform detection and prevention automatically and finally require no additional infrastructure. According to Table 7, considering the four mentioned factors, the combinational techniques could be classified into three levels as shown in Figure 7. This figure, illustrates that the first level has the least deployment requirements.

Comparative Discussion
In order to extract a final conclusion based on the evaluated criteria, further discussion is required. Therefore, the results of Figure 6 and Figure 7 require further analysis. These figures demonstrate the best options according to effectiveness and deployment requirements levels for securing a web application and the stored data against SQLIAs. AMNESIA is not a suitable choice due to its third level of effectiveness, and this would leave ESARV, WASP, IDL, SQLprob, and WebSSARI. WebSSARI, as stated in [37] has a low error rate, SQLprob has a high and IDL has a very high time complexity [41]; therefore due to the importance of precision and real time interaction, they are unsuitable. Hence, ESARV and WASP are remained and for conclusion, a more detailed comparison is performed in Table 8. The first six factors of Table 8 are identical for both tools, while the remaining factors vary. ESARV is totally automatic with no manual modification, very simple, has a negligible overhead, and requires automatic source code transformation. Whereas, WASP requires manual code modification, is not as simple as ESARV, has a higher overhead than ESARV, and requires source code transformation by the developer and automatic bytecode transformation. As a result, if the web application has no user defined SPs (like the testbed) then with no doubt ESARV is the best tool for reinforcing. On the other hand, if user defined SPs exist the choice would be as follows: if effectiveness is of importance and overhead and human interaction are not an issue, WASP would be the choice. Whereas, if you are looking for an automatic solution with the least response time, ESARV is the best choice.

CONCLUSION
In this paper, we proposed a new method capable of securing a web application and its database against SQLIAs. This combinational method is based on systematic analysis and runtime validation and uses our proposed detection and prevention technique for information security. In the static phase, user inputs are removed from SQL queries and based on the query type, static models and input locations are gathered in order to make the detection and prevention easier and faster at runtime. To facilitate the usage of our method and perform empirical evaluations, ESARV was implemented for Java-based web applications. Evaluations indicated that ESARV is the best choice for web application reinforcement. For this purpose, we have used the test suite of AMNESIA and also Apache JMeter for measuring performance and accuracy. ESARV was able to stop all of the attacks with no false negatives and no false positives. It also proved to be efficient by having negligible overhead for the reinforced web application. Although no manual code modification or additional infrastructure is required and detection and prevention are performed automatically, ESARV is not capable of identifying user defied SP attacks; therefore improvement is required in order to attain 100% effectiveness.
As a future work our method could be extended to support user defined SPs inside the database. Another future work would be to use our method without the demand to alter the web application's code which would lead to extra overhead, whereas at the moment modifications are performed automatically with negligible overhead. Finally, due to the significance of maintaining web application security further research is required in this field.