\documentclass{CRPITStyle}
%\documentclass{report}
\usepackage[authoryear]{natbib}
\usepackage{parskip}
\usepackage{courier}
\usepackage{setspace}
\setlength{\parindent}{.5cm}
\renewcommand{\cite}{\citep}
\pagestyle{empty}
\thispagestyle{empty}
\hyphenation{roddick}

\begin{document}

\title{A Survey of Methods For Preventing SQL Injection Attacks}
\author{Silvio Marco Costantini}
\affiliation{School of Engineering, \\
Victoria University of Wellington, \\
Email:~{\tt mcsilvio@gmail.com}}

\maketitle

\begin{abstract}

The internet and other systems comprise many applications that rely on connectivity to a database. Almost all of these systems embed user input into database queries for processing. However, therein lies a critical security vulnerability; the SQL Injection Attack.

This paper is a survey on recent methods for preventing SQL Injection Attacks. It begins by describing the nature of SQL Injection Attacks, and six recent methods for preventing them. An analysis is performed on these methods, and finally, a conclusion is drawn which states that SQLProb has the highest benefit for its cost.

\end{abstract}

\section{Introduction}

As the trend to move applications to the web increases, online databases are needed in abundance. Data such as user details, user-created content, usage data, and more need to be stored permanently and online. This data is often highly sensitive, private, and its integrity is often of critical importance. Protecting such data is not only considered a best-practice, but it is demanded by web-application users world-wide.

The problem of security is exacerbated by the fact that a typical online database is completely connected to every one of its end-users. This is true even though a single user requires only a portion of it. In order to supply a user with only his own data, user authentication and identification is required. A common way to achieve this is through secret information being given to the application by the user (i.e. a username and password combination). However, this creates the connection between the user and the entire database, and subsequently, a security vulnerability. Malicious users may exploit this vulnerability through an SQL Injection Attack (SQLIA). Due to the sensitivity and privacy of the online-data, sufficient preventative measures must be taken against SQLIAs.

This paper is a survey of several recent SQLIA prevention methods. First a brief background of the domain is given. Then the methods themselves are described. These are; SQLProb, CANDID, Parse-Tree Validation, SQL-IDS, Attribute Value Removal, and TAPS. After this, an analysis is done. Therein, a description of the analysis criteria is found, followed by the analysis itself. Finally a conclusion is made concerning which SQLIA prevention method yields the best benefit for its cost.

\section{Background}

Breaching security with an SQLIA can be accidental, but it is typically the result of malicious misuse of the system. To perform an SQLIA is to take advantage of an application's need to gather input from the user by injecting SQL code directly into user input fields. Because the user input will eventually be used to query a database, any SQL instuctions found within will be executed. Hence, malicious code also could potentially be executed. A simplified, but valid, example of this is:

\begin{itemize}
\raggedright
\onehalfspace
\item A `username' and `password' are requested by an application.
\item The username \linebreak
\texttt{admin} \linebreak
is supplied.
\item The password \linebreak
\texttt{wrongpw' OR 1=1; --} \linebreak
is supplied.
\item The application then generates the following valid SQL query: \linebreak
\texttt{SELECT * FROM users} \linebreak
\texttt{WHERE username = `admin'} \linebreak
\texttt{AND password = `wrongpw'} \linebreak
\texttt{OR 1=1; --'}
\end{itemize}


For typical user-authentication, both the given username and password would be sent to the database in an SQL query. Normally, the query's WHERE clause would only be true if the given password matched that for the given username. However, in the augmented query above, a malicious user forces the WHERE clause to return true without a real check ever taking place. This is because of the injection of the `OR 1=1' SQL code in the password field. Since `1=1' is always true, and here is part of the check, the WHERE clause always returns true. If a username is known (e.g. `admin') a malicious user could acquire access belonging to that user without a valid password. Additionally, there are many flavours of SQLIAs, all developed to circumvent detection methods. For a formal definition of command injection into applications, see Su and Wassermann (2006).

By exploiting this vulnerability, a malicious user could destroy, or modify, either the application data or the database itself. Some such malicious intentions include; learning about the database and its structure, which is private information; adding, modifying or deleting data or database elements; causing the database to malfunction, potentially resulting in a denial-of-service to its users; avoiding authentication and/or adjusting a user's privileges. (Halfond, Orso, and Viegas, 2006). This vulnerability is ultimately caused by ineffective validation of user input, and its persistence is a testament to how challenging that can be.

\section{SQL Injection Attack Prevention Methods}

In the following subsections, descriptions of six SQLIA prevention methods are found. Those are; CANDID, SQLProb, Parse Tree Validation, Attribute Value Removal, SQL-IDS, and TAPS.

\subsection{SQLProb}

Many SQLIA prevention methods are dependent on the source-code of the web application that needs protection. This may not be available, and modifying it may not be appropriate. SQL Proxy-based Blocker (SQLProb) aims to provide a non-intrusive method of SQLIA prevention.

SQLProb works by the use of a proxy that exists between the database and the web-application. The proxy is given the generated query, and the original user input is extracted from it (despite existing within the query). The original user input is then validated/invalidated using the generated query's syntax. Genetic algorithms are used for the input validation, and continually become more effective as training examples of input are given.

The SQLProb system has four main components: the Query Collector, User Input Extractor, Parse Tree Generator, and the User Input Validator. The Query Collector component gathers and processes all of the queries that the application produces. The User Input Extractor separates the user input from the generated queries in which the input is embedded. The Parse Tree Generator creates a parse tree for query structure analysis. The User Input Validator judges whether the input is benign or malicious and discards the query accordingly.

The researchers behind SQLProb claim that it has several advantages over other methods of SQLIA prevention. One advantage is that SQLProb is a ``Black-Box'' solution. This means that no modification or access to application or database code is required. It only needs to exist between the two systems as a proxy. Another is that SQLProb does not require any information or meta-data for the queries it is given. Also, SQLProb can make use of an ``off-the-shelf'' proxy, and requires little effort to set up. Lastly, SQLProb is a solution that is independent of implementation language. Potentially the most significant advantage is that one instance of SQLProb could protect multiple systems simultaneously.

For the evaluation, a prototypical implementation of SQLProb was used. A test suite called AMNESIA (Halfond and Orso, 2006) was used to induce SQLIAs. AMNESIA contains both an automated attacking method, as well as several applications to test preventative measures on. It is fully automated, and performs attacks that are based on thirty attack patterns. These patterns cover all of the attack types (Halfond et al. 2006), but were extended by the research team to include several more attacks which were aimed at acquiring ``sensitive'' information from the database.

The evaluation comprised two sets of tests which were aimed at effectiveness and performance, respectively. Effectiveness was evaluated in terms of the number of attacks that were detected. The results of the effectiveness evaluation showed that 100\% of the attacks performed were detected successfully. Performance was evaluated in terms of the response time of the query (in seconds), and the CPU usage (percentage). The results of the performance evaluation show that for the majority of test conditions, the SQLProb created a significant but reasonable delay in response time which ranged from 16\% to 27\%. For exceptionally large query strings, SQLProb exhibited an increase in response time of 181\%. Although this is undesirable, the authors claim that queries of such extreme length are not typically found in applications.

\subsection{CANDID}

CANDID (Candidate Evaluation for Discovering Intent Dynamically) is an SQLIA prevention tool designed by Bisht et al. (2010) which is claimed to be an automatic method of preventing SQL Injection Attacks. It is designed for web-applications implemented with Java Server Pages or as Java servlets. CANDID can be implemented in one of three supported ways. It can either repair SQLIA vulnerabilities in an existing web-application by transforming its source code, it can be set to monitor the Java Byte Code, or it can work via a modification to the Java Virtual Machine itself.

If the source code of an application is available, CANDID's approach to detecting malicious input is, essentially, to compare a generated query's structure against a predefined ``candidate'' query. Here, CANDID scans all of the application source code for any SQL queries. Then for each one, it adds a valid SQL query with place-holder text for values. Additionally, code is added to the application so that whenever a query request is made, both the generated query and the candidate query are compared for structural similarity  - using a parse tree - before submission to the database.

If the source code of an application is unavailable, CANDID can monitor the Java Byte Code to protect it. CANDID looks for the creation of string variables, and for every string variable it encounters, it creates a candidate string variable. Also, in JSP / Java-based web-applications, user input is retrieved by a finite set of methods (e.g. getParameter(), getAttribute()). Thus, when CANDID identifies these methods in the Java Byte Code, it creates and initializes a corresponding candidate string. For any operation it encounters that manipulates a string variable, it performs the same manipulation on the candidate strings. Lastly, when CANDID encounters a method for submitting a string to the database as a query, it first uses a parse tree to compare the structure of the string to that of the corresponding candidate string.

An alternative implementation of CANDID is to modify the Java Virtual Machine itself. This mainly involves modifying the java.lang.string class. CANDID requires many of the string operations in the class to also create their candidate counterparts. This modification affords that any updates or modifications to the Java Virtual Machine may affect the correct operation of CANDID.

An advantage of CANDID is that it is a comprehensive method for reducing SQLIA vulnerabilities. Additionally, the Java Byte Code and Java Virtual Machine implementations require no modification to the application itself. A disadvantage of CANDID is that there exist exceptional cases, where it breaks altogether. In these cases, even benign input is evaluated as malicious. Also, if the Java Virtual Machine is modified, further updates and modifications need to be reviewed for incompatibility with CANDID. Another disadvantage is that CANDID only works with Java-based applications. The authors also report a limitation inherent in the approach itself. An example is if there exists string manipulation in the source code, and the text ``OR'' (an SQL keyword) naturally exists therein. This case will be incorrectly recognized as malicious intent.

The research team effectively evaluated CANDID in terms of; comprehensiveness of attack types prevented, real-world effectiveness, and the performance overhead required for protection. For simulating attacks, AMNESIA was used (mentioned in the previous section). The authors claim that CANDID successfully prevents SQLIAs of all types. Real-world effectiveness was tested using three commercial applications with known vulnerabilities. For all applications, CANDID prevented all attacks and issues zero false positives. Performance evaluation was done in terms of Client Response Time (milliseconds), and was done separately for two of the implementation types: Java Byte Code transformation, and Java Virtual Machine transformation. For the Java Byte Code implementation, the response time was approximately 18\% higher on average across all tested applications with CANDID operating. For the Java Virtual Machine implementation, the response time was approximately 5\% higher on average across all tested applications with CANDID operating. The authors claim that this overhead is acceptable for the quality of the solution.

\subsection{Parse-Tree Validation}

Many applications make use of database connectivity interfaces, such as JDBC. By communicating to a database through such an interface, many implementation-specific details are hidden from the developer. This also creates a single point of communication with a database. Buehrer et al. (2005) have designed an approach for preventing SQLIAs that takes advantage of this encapsulation. At this point of communication, Parse Trees are used to validate any query requests sent to the database.

A Parse Tree is a data structure which contains the tokens of a computable string. SQL queries are such strings. Buehrer et al. (2005) have designed a SQLIA prevention method that uses Parse Trees to compare the structure of an SQL query before - and after - user input has been embedded. To do this, some additional code must be present in the application. Firstly, the standard JDBC drivers must be substituted for the ones created by Buehrer et al. (these drivers ``extend'' JDBC). Secondly, each query needs slight augmentation. User input must be passed to a function which marks the input with a private ``key''. At run-time, the replacement drivers will intercept any generated queries, use the key to separate the user's input from the generated query, and use Parse Trees to compare their structure. If it is found that the user input has changed the structure of the query, the query is discarded.

An advantage of the proposed system is that very little modification to the application is needed for the prevention method to work. The drivers need to be substituted, and the user input portions of the application need to be given to a function first. Another advantage is that the research team has made the tool's source code publicly available. A disadvantage of the system is that the method is implementation specific. Only applications that use JDBC to communicate to a database can be protected by this system. Another disadvantage is that user input must not be meant to contain SQL syntax. Although less common, the authors give an example of a ``SQL teaching application'' in which the user may be asked in give SQL queries as input. The proposed system will produce false positive evaluations on such applications.

The authors evaluated their system using a case study for a real company: the Ohio Department of Transportation. The research team's university was contracted by this company to build a web-application, and the team took the opportunity to evaluate their SQLIA prevention approach. The tool was evaluated for its performance overhead. The author notes that every SQLIA type was used for evaluation. For performance overhead, the research team measured the response time (milliseconds) against the number of simultaneous requests, with both the presence and absence of the tool. They show that their tool has a maximum overhead of 3\% increase in response time.

\subsection{SQL-IDS}

Platform or implementation dependence restricts the applicability of a system. SQL Injection Detection System (SQL-IDS) is a proposed approach for identifying SQLIAs that is platform and implementation independent. The approach is based around creating a specification (a set of rules) for all valid queries that the application will generate. The authors have also built a prototype that employs their approach, and provides the result of an evaluation of it.

SQL-IDS prevents SQLIAs in six phases. The first phase is to create the specification for valid queries. This specification is what the SQL-IDS approach is based upon. It is a set of ``rules'' that describes what syntax is valid for a given query in an application, and its creation is done once. The remaining phases take place at run-time. The second phase of the approach is to intercept all SQL queries for analysis. The third phase is to analyse the query lexically. That is, the query string is parsed into a sequence of ``tokens''. The fourth phase is the validation of the query syntax using the tokens gathered in the previous phase. This is the primary step in the approach. It evaluates the generated query by comparing its syntax to that found in the specification. The fifth phase is to forward the valid queries to the Database Management System (DBMS) and the final phase is to log the previous events.

The authors claim that SQL-IDS has three advantages. The first being that all SQLIA types are prevented. The second advantage is that it is platform independent. Additionally, the system requires no modification to the application source-code. A disadvantage not mentioned by the authors is that SQL-IDS is based on the assumption that correct user input should not modify the syntactic structure of the generated query. This assumption does not encompass all possible web-applications (e.g. SQL-teaching applications). Another disadvantage is inherent in the approach: The creation of the query specification requires in depth-knowledge of the application source-code. Also, scalability is affected because as new queries are added to the application, the specification needs to be updated.

A prototype was developed that makes use of the described approach. The evaluation of SQL-IDS was done using this prototype and was based on three criteria; the performance overhead of the system, the effectiveness of the system's ability to prevent SQLIAs, and the precision of the system's prevention abilities. For performance overhead, the research team found that SQL-IDS required an additional one millisecond - on average - to analyse and submit a query to the DBMS. They claim that since web-application requests take approximately one to two seconds, the overhead of SQL-IDS is acceptable. The effectiveness of SQL-IDS was measured in terms of a count of false negatives. That is, queries that were malicious but were not detected as such. After being given 420 malicious queries - in a total 2450 test queries - SQL-IDS produced zero false negatives. For precision, a count of false positives was measured. That is, benign queries identified as malicious. After being given 2030 benign queries, SQL-IDS produced zero false positives.

\subsection{Attribute Value Removal}

Jeom-Goo Kim (REF) proposes a method of detecting SQLIAs that utilises a combination of static and dynamic analysis. At the core of the solution is a function which removes attribute values from SQL query strings. This function is used to compare the structure of each query before and after it has been injected with the user's input. Thus, the solution has two phases: static query analysis, and dynamic query analysis.

The proposed system relies on a function that accepts an SQL query as text input, and outputs the same query with all values removed. Using this function, static analysis is performed and all of the queries - as they exist statically - are stored in a table without any values. Once the system is used to prevent SQLIAs, dynamic analysis is performed upon all query requests. This analysis also makes use of said function to remove all attribute values from the generated queries. For every query request, both of the valueless static and dynamic versions are compared. Typically, user input should not affect the structure of the intended SQL query. The authors formally show that, through this method, any processed, generated query should be identical to its corresponding processed, static query. Thus, by comparing the two, malicious queries are detected and discarded.

An advantage of the proposed system is that the application source-code does not need to be modified. Only an analysis of it needs to be done. Another advantage is that complex structures and algorithms, such as Parse Trees and learning algorithms, are not needed. This is because the value extraction method only needs to perform simple string operations. Also, the system is platform independent. A disadvantage is that if the source-code ever changes, the static analysis must be done again. Additionally, any applications that naturally accept SQL code as input will be mistreated by the system.

For the evaluation of the proposed system, the research team used five pre-built, database-connected applications acquired from the ``GotoCode'' website (REF). The evaluation of the proposed system was done through the execution of SQL queries - many of which being malicious. This was not only done with the prevention method proposed here, but was done alongside other prevention methods for comparison (SQLCheck and AMNESIA). The results show that the proposed method detected 100\% of the malicious queries (all types) with 0\% false positives. The results also show that the other two systems used had the same performance. Subsequently, the research team tested eighteen different prevention methods for their theoretical ability to prevent SQLIAs of different types. The results of this analysis show that while the method proposed here prevents attacks of all known types, many of the tested methods do not. Thus, the authors claim that based on this and the detection rate, the proposed method is effective.

\subsection{TAPS}

``PREPAREing'' an SQL query is the action of pre-compiling it, making its structure unchangeable via malicious input (REF). The method of SQLIA prevention proposed by Bisht et al. (2010) is what they call the ``first of its kind''. It is named Tool for Automatically Preparing SQL Queries (TAPS) and it is a method for automatically transforming the source-code of an existing application so that each query is PREPARED.

While manually PREPARING queries is not a difficult task, the authors report that doing this transformation automatically is challenging. Because an application may contain hundreds of queries, it is necessary to perform the transformation automatically. Thus, Bisht et al. (ref) have devised a method for doing so. The method is generally described as such: each string variable in an application's source-code that will ultimately contain the user input for an SQL query is replaced by a placeholder string (i.e. `?'). This allows an algorithm to ``prepare'' all of the queries therein. This means that if malicious input is given, the DBMS will reject the generated query as the structure will be incompatible with its PREPARED version.

The author's declare that the above approach will only be correct while the following assumption holds true: the string variables that will contain the user input must not be altered by string operations. The authors go on to claim that this assumption holds true for most typical applications, and that many other SQLIA prevention methods make this assumption as well.

The fundamental challenge for this system is ultimately the identification of string variables in the source-code that will hold the user's input for a query. This is achieved by symbolic execution, which is a method for organising a program by its abstract symbols instead of its literal values (King, 1976). After two passes of source-code analysis, the query strings and input-holding variables are identified. At this point, they can be used to generate PREPARE statements with placeholder strings for input. At run-time, it is these prepared statements that are used instead of regular queries, and hence, SQLIAs are prevented.

An advantage of the proposed method is that it is able to prevent all SQLIA types. Another advantage is that once transformed, the applications do not suffer in query response time. A disadvantage is that developer intervention is required for three different situations. The first is if the primary assumption is violated. The second is if the query can not be constructed statically (e.g. use of library call-back at runtime, or infeasible program traversal). The third is if conflicts exist in the analysis process (e.g. loops which can not be evaluated). Another disadvantage is that is the application changes, and includes new queries, it must be reanalysed by TAPS.

Two experiments were done to evaluate TAPS; one for effectiveness, and one for performance. For effectiveness, TAPS was tested on nine applications for the number of queries successfully transformed. For the largest three applications (in terms of lines of code), an average of 91\% of all the queries were successfully transformed. The other applications experienced a 100\% transformation of their queries. The authors state that this shows that developer intervention is required for large applications.

Performance was measured in terms of time required to fully transform an application, and the change in response time for a transformed application to operate normally. It was found that the largest application took two hours to transform. The other applications took less than one hour to transform. For change in response time, it was found that there was no significant increase in response time for the transformed applications. On some occasions, it was found that the transformed application outperformed the original version of the application.

\section{Analysis of Prevention Methods}

Following is an analysis of the aforementioned SQLIA prevention methods. The criteria chosen for the analysis is given first, and is followed by the analysis itself.

\subsection{Criteria}

In order to compare and contrast the various SQLIA prevention and detection techniques described in this paper, a criteria is formed. The performance and effectiveness of each prevention method described in this paper is shown to be high. The analysis found in this paper is done expands upon this and is done based on three other criteria. Those are; platform-independence, changes required when queries are modified in an application, and whether or not the prevention method modifies the platform itself. For platform-independence, each method will analysed for whether it requires a specific programming language, database management system, or specific software libraries. Also, each query will be analysed for whether updating is needed - on either the application or the prevention system, itself - when a query in the application is modified. Finally, each method will be analysed for its need to modify part of the platform directly.

\subsection{Analysis}

When comparing SQL Injection Attack prevention methods, performance and effectiveness are important factors. As developers strive to provide end-users with a responsive and high-quality application experience, these factors play an increasingly important role. However, for all SQLIA prevention methods described in this paper, their evaluations commonly show a high-degree of performance and effectiveness. That is, their increases in query response time or source-code transformation is acceptable, and they protect their applications from all types of SQLIAs. Thus, the analysis in this paper uses that assumption as a basis, and illuminates other aspects of the prevention methods.

\begin{center}
  \begin{tabular}{ | l | c | }
    \hline
    SQLProb & Yes \\ \hline
    CANDID & Yes \\ \hline
    Parse-Tree Validation & Yes \\ \hline
    SQL-IDS & Yes \\ \hline
    Attribute Value Removal & Yes \\ \hline
    TAPS & Yes \\ \hline
  \end{tabular}
\end{center}

Based on the criteria given in the previous sub-section, the SQLIA prevention methods herein are analysed. The first criterium concerns platform-independence (Table 1). In this paper, the term platform is overloaded and includes the concepts of implementation language, software libraries and database management system. Naturally, the less restricted a system is to a specific platform, the greater the number of environments that it can be applied to. For the methodologies described herein, platform-independence is varied. Only SQLProb, SQL-IDS, and the Attribute Value Removal methods work on any platform. However, dependence on a particular platform does have advantages. One of which is that the system in question may be ``tailored'' to the platform, potentially increasing performance. This was found in two of the three platform-dependent methodologies: Parse-Tree Validation (3\% increase in response time), and TAPS (insignificant increase in response, and occasionally, even better performance than the original application). Thus, for contexts where a solution is already developed using a particular platform, and high-performance is desired, these methodologies may be desirable. For solution designers, who may be investigating SQLIA prevention methods before their application is developed, the platform-independent methodologies may provide better flexibility.

The second criterium is the degree of modification required to either the SQLIA prevention system itself or the application, when queries are added, changed or removed from the application (Table 2). Some of the described methods require a static analysis of the source-code when this occurs. Those methods are; CANDID, Parse-Tree Validation, and TAPS. Because they transform the source-code at the query level, when a query must be changed, transformation of the source-code must be performed again. Other methods require that a data structure which exists within the prevention system to be updated. SQL-IDS and the Attribute Value Removal methods both keep records of each query as it exists statically. These records need to be updated manually (at present) when query modification occurs. On the other hand, one prevention method described here needs no updating at all when application queries are modified. This is SQLProb. Because it is well encapsulated, and exists as a proxy - which is within neither the database or the application - when queries are modified in the application, no maintenance to either system is required. In an environment where the application structure changes regularly, and hence so do the queries, SQLProb is highly advantageous. Changing structure is atypical of software applications and so the other prevention systems should not be dismissed. However, for the other methodologies, consideration is still needed. Because changes to queries occur in the application, the prevention methods that require updating therein are more advantageous than those that require updating in a separate system. The reason for this is centralisation.

The final criterium is whether or not the SQLIA prevention method requires modification to the platform itself (Table 3). Both CANDID and Parse-Tree Validation require changes be made in the Java Virtual Machine and JDBC drivers, respectively. Although this approach affords that inclusion of the prevention system into the application is simple, it yields a significant disadvantage: when the platform is updated to a newer version, careful checking must be done that the installed updates did not affect the SQLIA prevention system. For open-source languages and libraries such as Java and its libraries, this knowledge can be learned exactly - albeit, potentially, with great effort. However, using the same approach on closed-source software (not yet done) means that the developer must rely on the granularity of the software's documentation. Thus, the notion of platform-modification is a disadvantageous attribute.

Based on the combination of performance, effectiveness, and the three criteria mentioned here, there exists one methodology that, seemingly, has the most benefit for its cost. That is SQLProb. Being well encapsulated and isolated, it yields all of the advantages of modularity. A closer look into SQLProb gives further insight into its applicability. Although deemed acceptable by its designers, the performance of SQLProb was the lowest of all the prevention methods described in this paper. For extremely large query strings, SQLProb struggled to provide responsive evaluations. This is intrinsic to its modularity, as it only has the final generated query to analyse, and hence, needs complex algorithms. The authors report that queries of such length are atypical, and indeed, SQLProb exhibited acceptable performance for most applications. Additionally, the designers of SQLProb claim report that SQLProb could be used to protect multiple applications simultaneously. They do not evaluate the performance of their system while protecting multiple applications, but even the addition of one or two applications to the protection of SQLProb is highly advantageous. In theory, if many simple applications were protected by a central installation of SQLProb, and did not suffer significantly in response time, SQLProb would be a highly valuable approach.

Based on the analysis done here, it is recommended that future research be done on SQLProb. This can be done in two ways; investigating the performance of SQLProb as it protects multiple systems, and improving the performance of the algorithms it uses. An ideal improvement for SQLProb would be for its analysis algorithms to be of such high performance that it could protect a large number of systems simultaneously. This would increase the centralisation of SQLProb even further. An extreme vision is that one cluster of SQLProb servers could protect all of the web-applications that exist on the internet.

\section{Conclusion}

All of the SQLIA prevention methods described in the previous sections are of high quality. They each exhibit a high degree of comprehensiveness for SQLIA types prevented. Each method shows, through experimentation results, a low performance overhead. Fortunately, each approaches the problem uniquely, and hence has a different set of advantages and disadvantages.

For the majority of circumstances, SQLProb is the most advantageous. It's proxy-based approach, and no-modification installation affords that it is well encapsulated and capable of protecting multiple systems simultaneously. While this may not be advantageous for small or medium sized businesses with one database server, those businesses that have multiple database systems at different locations could benefit greatly from a central source of SQLIA prevention. Therefor, for its scalability, isolation, and effectiveness, SQLProb is the recommended solution for preventing SQL Injection Attacks.





\bibliographystyle{agsm}    % or some other suitable package.

\begin{thebibliography}{xx}

Halfond, W.G., Orso, A., and Viegas, J. (2006) A Classification of SQL-Injection Attacks and Countermeasures. In Proc. of the Intl. Symposium on Secure Software Engineering, Mar. 2006.

Su, Z., and Wassermann, G. (2006) The Essence of Command Injection Attacks in Web Applications. In The 33rd Annual Symposium on Principles of Programming Languages (POPL 2006), Jan. 2006.

Halfond, W.G., and Orso, A. (2006) Preventing SQL injection attacks using AMNESIA. In Proceedings of the 28th international conference on Software engineering (ICSE '06). ACM, New York, NY, USA, 795-798.

King, J.C. (1976) Symbolic execution and program testing. Commun. ACM, 19(7), 1976.

Amirtahmasebi, K., Jalalinia, S.R., Khadem, S. (2009) A survey of SQL injection defense mechanisms. Internet Technology and Secured Transactions. ICITST 2009. International Conference for , vol., no., pp.1-8, 9-12 Nov. 2009

Bisht, P., Madhusudan, P., and Venkatakrishnan, V.N. (2010) CANDID: Dynamic candidate evaluations for automatic prevention of SQL injection attacks. ACM Trans. Inf. Syst. Secur. 13, 2, Article 14 (March 2010), 39 pages.

Liu, A., and Stavrou, A., Wijesekera, D., and Yuan, Y. (2009) Sqlprob: a proxy-based architecture towards preventing sql injection attacks. In ACM symposium on Applied Computing, pages 2054-2061, Honolulu, Hawaii, 2009. ACM

Buehrer, G., Sivilotti, P.A., and Weide, B.W. (2005) Using parse tree validation to prevent SQL injection attacks. In Proceedings of the 5th international workshop on Software engineering and middleware (SEM '05). ACM, New York, NY, USA, 106-113.

Kemalis, K., and Tzouramanis, T. (2008) SQL-IDS: a specification-based approach for SQL-injection detection. In Proceedings of the 2008 ACM symposium on Applied computing (SAC '08). ACM, New York, NY, USA, 2153-2158.

Kim, J.G. (2011) Injection Attack Detection Using the Removal of SQL Query Attribute Values, Information Science and Applications (ICISA), 2011 International Conference on , vol., no., pp.1-7, 26-29 April 2011

Bisht, P., Sistla, A. P., and Venkatakrishnan, V. (2010) Automatically Preparing Safe SQL Queries. In FC’10: Proceedings of the 14th International Conference on Financial Cryptography and Data Security. Tenerife, Canary Islands, Spain


\end{thebibliography}

\end{document}

​