A Survey Of Sql Injection Countermeasures <s> SQLProb <s> An SQL injection attack targets interactive web applications that employ database services. Such applications accept user input, such as form fields, and then include this input in database requests, typically SQL statements. In SQL injection, the attacker provides user input that results in a different database request than was intended by the application programmer. That is, the interpretation of the user input as part of a larger SQL statement, results in an SQL statement of a different form than originally intended. We describe a technique to prevent this kind of manipulation and hence eliminate SQL injection vulnerabilities. The technique is based on comparing, at run time, the parse tree of the SQL statement before inclusion of user input with that resulting after inclusion of input. Our solution is efficient, adding about 3 ms overhead to database query costs. In addition, it is easily adopted by application programmers, having the same syntactic structure as current popular record set retrieval methods. For empirical analysis, we provide a case study of our solution in J2EE. We implement our solution in a simple static Java class, and show its effectiveness and scalability. <s> BIB001 </s> A Survey Of Sql Injection Countermeasures <s> SQLProb <s> SQL injection attacks (SQLIAs) consist of maliciously crafted SQL inputs, including control code, used against Database-connected Web applications. To curtail the attackers' ability to generate such attacks, we propose an SQL Proxy-based Blocker (SQLProb). SQLProb harnesses the effectiveness and adaptivity of genetic algorithms to dynamically detect and extract users' inputs for undesirable SQL control sequences. Compared to state-of-the-art protection mechanisms, our method does not require any code changes on either the client, the web-server or the back-end database. Rather, our system uses a proxy that seamlessly integrates with existing operational environments offering protection to front-end web servers and back-end databases. To evaluate the overhead and the detection performance of our system, we implemented a prototype of SQLProb which we tested using real SQL attacks. Our experimental results show that we can detect all SQL injection attacks while maintaining very low resource utilization. <s> BIB002
SQLProb BIB002 is another dynamic analysis approach. It uses a customized MySQL Proxy to collect queries, extract user input, generate parse trees, and validate user input. Figure 9 shows the architecture of the SQLProb system. The shaded area is the off-the-shelf MySQL Proxy. In the data collection phase, the Query Collector collects all the queries expected by the programmer and stores them in the system. In the query evaluation phase, an incoming query q generated by the application is sent to the Parse Tree Generator module and the User Input Extractor module at the same time. The Parse Tree Generator module generates the tree Tree(q) for the query using JavaCC. The User Input Extractor module uses an enhanced version of the Needleman-Wunsch algorithm to align query q with all the queries gathered in the data collection phase BIB002 . The algorithm can calculate the similarity of the query q and every collected query. The collected query that has the highest similarity value is called the prototype query of q. If there are m queries stored in the system, this step will require m comparisons, which is expensive. So the system preprocesses all the collected queries by clustering and aggregating them to reduce the size of the query collection. The paper shows the size of the collected query can be reduced to only 6% to 25% of the original size BIB002 . This will save a lot for the query comparisons. After the prototype query of q has been found, the Needleman-Wunsch algorithm extracts the user input portion of q by aligning q and its prototype query. The extracted user input is fed into the User Input Validator module. Tree(q) generated by the Parse Tree Generator also comes into this module. The user input is actually corresponding to a set of leaf nodes that appear in the parse tree. Let S denotes this set of nodes. To validate the user input, we simply conduct an upward depth-first search from all the nodes in S until their paths intersect at an internal node. Then starting from this internal node, we perform a breadth-first search to reach all the leaves of the tree. If the result set of the leaves is a superset of S, the user input is considered malicious and will be rejected. Figure 10 shows an example WHERE clause subtree. The user input for the password field is "nonsense' OR '1=1". Its corresponding five leaf nodes intersect at the node SQLExpression by using depth-first search. Then starting from the node SQLExpression, we can do breadth-first search which will reach all the leaves of this WHERE clause subtree. The breadth-first search result is a superset of the five leaf nodes. Therefore, the user input is determined as malicious. Unlike many other approaches such as BIB001  that need to add functions or methods to the source code, SQLProb does not require any code changes. Due to the nature of the NeedlemanWunsch algorithm, if the queries need to be compared are very long, the technique can cause significant delay BIB002 . The performance of SQLProb also depends on the completeness of the collected queries as well as the accuracy of aggregating these queries. What's more, SQLProb development uses the off-the-shelf MySQL Proxy, which is a program for MySQL server. So this tool cannot be used on other database systems.