Web Services Based SQL Injection Detection and Prevention System for Web Applications

Web Services Based SQL Injection Detection and Prevention System for Web Applications Monali R. Borade 1, Neeta A. Deshpande 2 1 PG Students, 2 Assistant Professor, Matoshri College of Enginering & Research Centre, Pune University Nashik, Maharashtra, India Abstract Web applications form an integral part of our day to day life. The number of attacks on websites and the compromise of many individuals secure data are increasing at an alarming rate. Hence, providing increased amount of security for the users and their data becomes essential. Most important vulnerability as described in top 10 web security issues by Open Web Application Security Project is SQL injection attack (SQLIA). SQLIA's occur when attacker modifies the intended effects of query to gain unauthorized access of web applications and their underlying databases. The Proposed system focuses on how the advantages of randomization can be employed to prevent SQL injection attacks in web based applications. The two most important advantages of the proposed approach against existing analogous mechanisms that are, first, it prevents almost all forms of SQL injection attacks using X_PAATH validation technique (i.e. active guard and service detector components) by scanning user inputs for malicious attacks with the advantage of web services; second, use of randomization encryption algorithm provides enhanced security while detecting and preventing SQL injection attacks in database. The result clearly indicate enhancement in the performance of the system in terms of improved SQL injection detection and prevention ability and improved response time. Keywords-- Randomization, SQL injection, Vulnerability; Web Application Security, Runtime Monitoring, Service Detector, Active Guard. I. INTRODUCTION SQL injection is a major concern belongs to code injection problem categories. [1] Unsecured web applications allow injection attacks to perform unwanted and malicious operations on backend databases and theft of data. Hence security of web applications has become a necessity these days. In these types of attacks, input given by the user is included in an SQL query in such a way that part of the user s input is treated as SQL code and taking advantage of these vulnerabilities, an attacker gain access to web applications and their underlying databases by submitting SQL Commands. The main reason of SQL injection vulnerabilities is insufficient validation of inputs. 418 To address these problems developers have proposed a variety of detection and prevention strategies [2] which provide defensive approaches such as encoding user inputs, performing input validations and many more. A rigorous and systematic combination of these approaches makes an effective solution for detecting and Preventing SQLIA s. To address these issues this paper presents a comprehensive approach to detect and prevent SQLIA s. The further paper is organized as follows: Section 2 describes different types of SQL injection attacks. Section 3 focuses on current techniques for detection and prevention of SQLIA s. Section 4 describes proposed system with its implementation details and algorithms used. Section 5 describes system evaluation and comparison of proposed system with other techniques. Finally in section 6 this paper is concluded and there will be a discussion on future trends and directions. 2.1 Types Of SQLIA S 2.1.1 Tautologies II. BACKGROUND Tautology attacks are used to inject code in one or more Conditional statements so that they will always evaluate to true. This technique is most commonly used to bypass authentication pages and extract data. If the attack is Successful, the code either displays all of the returned records or performs some action if at least one record is returned. Example: In this example attack, an attacker submits or 1=1 - -. The Query for Login mode is: SELECT * FROM user info WHERE loginid= or 1=1 -- AND pass1= References: [3] [4] [5] [6] [1] 2.1.2 Illegal/Logically Incorrect Queries This type of queries uses the error message sent from databases on being sending wrong SQL queries which may contain some useful debugging information helpful to attacker in finding parameters vulnerable to web application and their underlying databases.

Example- The error message for sending a wrong password may be like:- Select * from <tablename> where userid = <id> and password = <wrongpassword> or 1=1; References: [7] [8] [9] [1] 2.13 Union Query In these types of attacks, an attacker uses vulnerable parameters to change the data set returned for a given query. The Attackers do this by injecting a statement of the form: UNION SELECT <rest of injected query> because the attackers can completely control the second/injected query they can use original query to retrieve information from a specified table. In output the database returns a dataset that is the union of the results of the original first query and the results of the injected second query. [6] [10] [2] [1] Example- SELECT accounts FROM users WHERE login= UNION SELECT cardno from CreditCards where acctno=11123 -- AND pass= AND pin= 2.1.3 Alternate Encodings This technique performs injection by modifying query, means replacing characters in query by some other characters or symbols like Unicode, ASCII, hexadecimal. In this way attacker can escape the filter for wrong characters [1]. This attack could be extremely harmful for web applications if used in combination with other techniques because it can target different layers of a web application. This method can be used to hide all kinds of SQL injection attack Example- SELECT name FROM <tablename> WHERE id= and password=o; exec (char (O x2324456789j776e)) 2.1.4 Stored Procedures These are the routines stored in the database and executed by the database engine. These procedures can be either user-defined or procedures provided by the database by default. Depending on the type of stored procedure there are different ways to attack. [1] It s vulnerable to web applications. Moreover all the types of SQL injection attacks applicable to web application are also going to work at this level. Example:- CREATE PROCEDURE DBO.isAuthenticated @username varchar2, @pass varchar2, @pin int EXEC("SELECT accounts FROM users WHERE login= " +@username+ " and pass= " +@password+ " and pin=" +@pin); GO 2.2 Remote Code Execution Remote Code Injection consists of injecting code which is then interpreted /executed by the web application. This type of attack exploits poor handling of untrusted data. These types of attacks are usually happens because of lack of proper input/output data validation. 2.3 Cross Site Scripting In Cross-Site Scripting attacks malicious scripts are injected into the otherwise benign and trusted web sites. XSS occurs when an attacker make use a web application to send malicious code, usually in the form of a browser side script, to a different end user. 2.4 Local File Inclusion (LFI) Local File Inclusion (LFI) is the process of including local files on a server through the web browsers. This attack occurs when a page include is not properly sanitized, and allows directory traversal characters (such as dot-dotslash) to be injected. III. LITERATURE SURVEY Until now Researchers have proposed a range of techniques to address the issue of SQL injection attacks. This technique varies from developing best coding practices to fully automated frameworks for detecting and preventing SQLIAs. This section summarizes some of these techniques with their features and limitations. 3.1 Defensive Coding Practices The main reason of SQL injection vulnerabilities is improper input validation. Therefore, the perfect solution application of suitable defensive coding Practices like input type checking, encoding user inputs, positive pattern matching, and identification of all input sources to these vulnerabilities. Although defensive coding practices are the best way to prevent SQL injection vulnerabilities, but their application in reality is problematic. Defensive coding practices are prone to human errors and cannot completely and rigorously apply as automated techniques [11] [12] [13] [1]. 419

3.2 Static Code Checkers Tautology checker is a technique proposed by Wassermann and Su which provides an analysis framework for providing security in web application. It combines static analysis with automated reasoning to verify whether the SQL queries generated in the application layer contains a tautology or not [14]. This technique has limited scope of detecting and preventing tautologies and cannot detect other type of vulnerabilities [1]. 3.3 Instruction Set Randomization SQLRand is a technique proposed by S. W. Boyd and A. D. Keromytis for preventing SQL injection attacks by instruction set randomization. This technique attaches SQL keywords with the key generated by the randomization Algorithm [15]. When an attacker having no knowledge of the key, performs the attack will fail because the query constructed by the attacker will not match with the query containing randomly generated key. The keywords in both the queries will differ, therefore prevents SQL injection attack. As it s a static analysis technique, the security of server s web databases is not compromised due to attack. However, implementation of a proxy server for randomization and de-randomization adds to the performance overhead [1]. 3.4 Static and Dynamic Analysis Techniques Amnesia [16] [17] [18] is the technique proposed by W. G. Hal fond and A. Orso, which a combination of static analysis and run-time monitoring used for prevention of SQL injection. It works in two phases. It builds a model of all the queries generated by the application in static phase. To do this, the tool needs to access the entire source code. The query built during run-time is validated against the model built during the Static phase in dynamic phase. But the limitation is it needs to access whole source code and response time [1]. 3.5 Taint Based Approach Web App. Hardening [19] proposed by Nguyen-Tuong and colleagues and CSSE [20] proposed by Pietraszek and Berghe tracks precise per-character taint information by modifying a PHP interpreter. The approach uses a context sensitive analysis to detect and reject queries to check for untrusted input used to create certain types of SQL tokens. A common limitation of these two approaches is that they require modifications of the runtime environment, which greatly affects portability. 3.6 Framework For Sql Retrieval On Web Applications This technique is proposed by Haeng Kon Kim [21]. It proposes a framework for web application security. The technique has two parts - Pattern Creation Module (PCM) and Attack Detection Module (ADM). PCM creates a model of attacks based on the patterns observed from previous attacks and ADM checks whether the query fired by an application matches an existing pattern [1]. 3.7 Intrusion Detection Systems This technique is proposed by Valeur and colleagues [36] to detect SQLIAs. It uses machine learning technique to train a set of typical application queries. It builds models of the typical queries and then monitors the application at runtime to identify unmatched queries [1]. 3.8 Random4 Encryption Algorithm It is a technique proposed by Avireddy s. [5] which converts the user s plaintext inputs into cipher text inputs by using random values from lookup table to detect and prevent SQL injection. This is just to provide the additional security to the user inputs. But the technique has limited scope. Outcomes of literature survey: By studying these existing technique and algorithms, we concluded with the aim of removing limitations of existing techniques such as, 1. Some methods only provide SQLIA s detection abilities. 2. The response time is critical issue in many techniques. 3. The scope is limited to very few attacks detection and prevention. IV. IMPLEMENTATION DETAILS This section focuses on working methodology of proposed system with exploration of its different components. 4.1 Systm Architecture Fig.1 describes the proposed system architecture and its components. This technique uses runtime monitoring to detect and prevent SQLIA s. The solutions can be applied to each kind of application. In the proposed solution, when the login page will be redirected to checking page where it will detect and prevent SQL injection attacks without stopping legitimate access. This proposed system will be using web services which have functions Db-to-XML generator and XPAATH-validator which is an XML query language used to select specific part of an XML document? 420

XPAATH is used to traverse nodes from XML and collect information. The copy of original database is maintained in the form of XML documents which is a temporary storage of sensitive data in the database. Firstly the active guardian module detects and prevents SQL injection attacks. Second module service detector & locator authenticate and allow valid user to access the web applications. This technique monitors both statically and dynamically generated queries at runtime and checks them for malicious inputs. If the comparison does not satisfies the rules proposed in the model then it is treated as a potential SQLIA s and blocked from gaining access to the database. The proposed system has 4 modules: two filtrations modules, one encryption module and web services layer to detect and prevent SQL injections. 4.1.1 Active Guardian Filtration module: This module works at application layer which builds a susceptibility detector for Detecting and preventing the malicious characters or Meta characters from queries in order to prevent the malicious attacks from gaining access to the user sensitive data stored in database. Active guard accepts query as an input and removes special characters, Meta characters, and special symbols. It stores the filtered input into array lists. Encryption algorithm then encrypts the filtered inputs using lookup table. Then it finds out the attack type using SQL_Attack function. The procedure then compares the filtered inputs with the original inputs and if inputs are valid, active guard provides inputs to service detector and locator. 4.1.4 Web service layer: Service detector & locator module calls web services using SOAP protocol. Web services execute two types of processes that are DB-to-XML generator and XPAATHvalidator. DB-to-XML generator creates temporary copy of user sensitive data from database in an XML format. The user inputs from service detector & locator are then compare with the data existed in XML documents in XPAATH-validator, if the data is matched XPAATHvalidator sends a flag with the count value=1 to service detector & locator module by conveying that the user data is valid. 4.1.5 Identifying vulnerabilities or hotspots: This module perform simple step of scanning web applications in order to identify vulnerabilities or hotspots. Each vulnerability will be verified with the active server by removing the malicious characters from the code using specific methods like system.data.sqlclient namespaces.1 and sqlcommand.executereader (string). Using these methods dynamically generated queries are categorized as malicious or non-malicious. 4.1.2 Random4 Encryption algorithm: This algorithm converts the user s plaintext inputs into cipher text inputs by using random values from lookup table. This is just to provide the additional security to the user inputs because as we know Cipher text is difficult and time consuming to crack. 4.1.3 Service detector & locator module: This model also works at application layer which validates user inputs from XPAATH-validator where user s sensitive data from database stored in XML format. This is the second level of filtration of queries. The user inputs are compared with the existing inputs from XPAATH- Validator, if they matched the access is granted to user, if not the access is blocked. Fig 1. Architecture Diagram 421

4.2 Procedure of Runtime Data Monitoring When a Web application fails to properly sanitize the parameters, which are passed to, dynamically created SQL statements (even when using parameterizations techniques). It is possible for an attacker to alter the construction of back-end SQL statements. When an attacker is able to modify an SQL statement, the statement will execute with the same rights as the application user; when using the SQL server to execute commands that interact with the operating system, the process will run with the same permissions as the component that executed the command (e.g., database server, application server, or Web server), which is often highly privileged. Current technique as shown in Fig 1 appends With Active Guard, to validate the user input fields to detect the Meta character and prevent the malicious attacker. Transact-SQL statements will be prohibited directly from user input. For each hotspot, statically build a Susceptibility detector in Active Guard to check any malicious strings or characters append SQL tokens (SQL keywords and operators), delimiters, or string tokens to the legitimate command. Concurrently in Web service the DB_2_Xml Generator generates a XML document from database and stored in X_PAATH Validator. Service Detector receive the validated user input from active guard and send through the protocol SOAP (Simple Object Access Protocol) to the web service from the web service the user input data compare with XML Validator if it is identical the XML Validator send a flag as a iterator count value = 1 to Service Detector through the SOAP protocol then the legitimate/valid user is authenticated to access the web application, If the data mismatches the XML Validator send a flag as a count Value = 0 to Service Detector through the SOAP protocol then the illegitimate/invalid user is not Authenticated to access the web application. In the existing technique query validation occur to validate a Authenticated user and the user directly access the database but in the current technique, there is no query validation.from the Active Guard the validated user input fields compare with the Service Detector where the Sensitive data is stored, db_2 _XML Generator is used to generate a XML file and initialize to the class X_PAATH document the instance Navigator is used to search by using cursor in the selected XML document. Within the X_PAATH validator, Compile is a method which is used to match the element with the existing document. The navigator will be created in the X_PAATH document using select method result will be redirected to the X_PAATH node iterator. The node iterator count value may be 1 or 0, if the flag value result in Service Detector as 1 then the user consider as Legitimate user and allowed to access the web application as the same the flag value result in service detector as 0 then the user consider as Malicious user and reject/discard from accessing the web application If the script builds an SQL query by concatenating hard- coded strings together with a string entered by the user, As long as injected SQL code is syntactically correct, tampering cannot be detected programmatically. String concatenation is the primary point of entry for script injection Therefore, we Compare all user input carefully with Service Detector (Second filtration model). If the user input and Sensitive data's are identical then executes constructed SQL commands in the Application server. Existing techniques directly allows accessing the database in database server after the query validation. Web Service oriented X_PAATH authentication technique does not allow directly to access database in database server. 5.1 Experimental Setup V. EXPERIMENTAL RESULTS The proposed technique is deployed and tried few trial runs on the web server. The evaluation parameters are Execution time/response time to Queries from web application and number of attack types detected and prevented. Figure 2 shows the results of proposed technique on different web application and its prevention Capacity. It shows the result for two web applications based on windows operating system another based on open source operating system. The graph in Figure 2 along with Table 1 shows the number of applied attacks on the web application along with prevented number of attacks and successful attacks. Table 1: Results of proposed System on Different web Applications 422

5.2.2 SQLIA Detection and Prevention Ability of Proposed System Both the protected and unprotected web Applications are tested using different types of SQLIA's; namely use of Tautologies, Union, Piggy-Backed Queries, stored procedures and different authentication bypass attacks like remote code execution, malicious file upload and many other. Table 2: Execution time Comparison of Existing and Proposed System Figure 2: Results of proposed System on Different web Applications 5.2 Evaluation Parameters / Performance Measures 5.2.1. Execution Time/ Response Time It's the time taken by server to execute the query submitted by user & respond them back. For the proposed system the response time will also be dependent on the web application using the system. Execution Time Comparison of Proposed system With Existing System at runtime validation: The runtime validation incurs some overhead in terms of execution time at both the Web Service Oriented X_PAATH Authentication Technique (Proposed Technique) and SQL- Query based Validation Technique (Existing Technique) as depicted in Table 2. Analysis: Taken a sample web site we measured the extra computation time at the query validation, this delay has been amplified in the graph (Figure 2) to distinguish between the Time delays using bar chart shows that the data validation in XML Validator performs better than query validation due to following differences: i. In Query validation the user input is generated as a query in script engine then it gets parsed in to separate tokens then the user input is compared with the statistical generated data if it is malicious generates error reporting. ii. In Web Service Oriented X_PAATH Authentication Technique user input is generated as a query in script engine then it gets parsed in to separate tokens, and send through the protocol SOAP to Susceptibility Detector, then the validated user data is sequentially send to Service Detector through the protocol SOAP then the user input is compared with the sensitive data, which is temporarily stored in data set. If it is malicious data, it will be prevented otherwise the legitimate data is allowed to access the Web application. 423 Figure 3: Execution time comparisons for proposed technique Table 3 shows that the proposed technique prevented all types of SQLIA s and authentication bypass attacks in almost all cases. So the prevention ability of proposed technique is observed to be approximately 100% against existing technique predefined set of attacks. The proposed technique is thus a secure and robust solution to defend against SQLIA's and authentication bypass attacks. The Figure 4(a) and Figure 4(b) show the comparison of prevention ability of Existing techniques with proposed system. The graph clearly indicates the detection and prevention ability of implemented system.

Table 3: Detection and Prevention Ability of Proposed System 5.3 Comparisons With Other Tools The Figure 5 and Figure 6 show comparison of proposed system with other existing tools. The comparison is made on whether any encoding was part of the technique and the automation in detecting and preventing SQLIA's. Figure 5: Comparison with Existing Tools Figure 4 (a): Detection and Prevention Ability of Existing System Figure 4(b): Detection and Prevention Ability of Proposed System 424 Figure 6: Comparison of Existing system and proposed system 5.4 Disscussion The response rate of existing system was in a range of 40000-120000 millisecond which was directly proportional to the number of inputs to web application. As number of inputs increases the performance of the system were degraded. The response time /execution time for earlier work were more because of direct accesses provided to the database for query execution. Also the previous system's attack detection and prevention ability was limited to number of attacks. System was static system and was able to detect and prevent only few numbers of attacks.

This is illustrated in Table 4. There is clearly an enhancement in the results of proposed system against earlier work in terms of Query execution time/ response rate and Detection and Prevention ability. The response time was reduced from range of 40000-12000 to 10000-20000 for same number of inputs as a result of X_PAATH validation technique which checks the user input with valid database which is stored separately in X_PAATH and do not affect database directly so the time delay occurred in database access was reduced and hence response time is improved as shown in Table 5 Also the detection and prevention ability was increased by approximately 60% than the earlier work for same set of predefined attacks. Table 4: Results of Earlier Work The proposed technique focused on 10 types of attacks mainly which are SQL injection attacks like Tautology, Union Query etc. and authentication bypass attacks like Remote Code Execution, Cross-Site Scripting etc. This proposed technique was able to suitably classify the predefined set of attacks that performed on the applications without blocking legitimate accesses to the web application. The result of proposed work clearly indicates increased performance in terms of attack types detected and prevented and improved response time/execution time to query validation. These observed results show that proposed technique represents a promising approach to countering SQLIA's as it uses web services which can be used by any web application to authenticate their users and provide enhanced security and also motivate further work in this direction. Table 5: Results of Proposed Work VI. CONCLUSION AND FUTURE WORK SQL Injection Attacks attempts to modify the parameters of a Web-based application in order to alter the SQL statements and can gain unauthorized access to web applications and their underlying databases. The proposed technique is used to detect and prevent the SQLI flaw (Susceptibility characters & exploiting SQL commands) in susceptibility detector and prevent the susceptibility attacker. Web Service Oriented X_PAATH Authentication Technique checks the user input with valid database which is stored separately in X_PAATH and does not a affect database directly then the validated user input field is allowed to access the web application as well as used to improve the performance of the server side validation. 425 VII. FUTURE SCOPE The proposed work can be extended further to detect more number of attacks and further performance can be improved. 1. System can be modified for detection and prevention of XML attacks and attacks on web services 2. Can be extended for detection and prevention of more number of attacks. REFERENCES [1] Monali Borade, Neeta Deshpande. Extensive review of SQLIA s detection and prevention techniques. International Journal of Emerging Technology and Advanced Engineering, ISSN 2250-2459,Volume 3, Issue 10, October 2013. [2] William G.J. Hal fond and Alessandro Orso, A Classification of SQL injection attacks and Countermeasures, proc IEEE int l Symp. Secure Software Engg., Mar. 2006. [3] G. T. Buehrer, B. W. Weide, and P. A. G. Sivilotti. Using Parse Tree Validation to Prevent SQL Injection Attacks. In International Workshop on Software Engineering and Middleware (SEM), 2005. [4] W. R. Cook and S. Rai. Safe Query Objects: Statically Typed Objects as Remotely Executable Queries. In Proceedings of the 27 th International Conference on Software Engineering (ICSE 2005). [5] Avireddy, S. Perumal, V. ; Gowraj, N. ; Kannan, R.S. ; Thinakaran, P. ; Ganapthi, S. ; Gunasekaran, J.R. ;Prabhu, S. Random4: An Application Specific Randomized Encryption Algorithm to prevent SQL injection, IEEE TRANSACTIONS ON COMMUNICATIONS, VOL. 60, NO. 5, MAY 2012. [6] Indrani Balasundaram., Dr. E. Ramara. An Approach to Detect and Prevent SQL Injection Attacks in Database Using Web Service. IJCSNS International Journal of Computer Science and Network Security, VOL.11 No.1, YEAR 2012. [7] F. Bouma. Stored Procedures are Bad, O kay? Technical report, Asp.Net Weblogs, November 2003. http://weblogs.asp. net/fbouma/archive/2003/11/18/38178.aspx.

[8] D. Litchfield. Web Application Disassembly with ODBC Error Messages. Technical document, @Stake, Inc., 2002. http://www.nextgenss.com/papers/webappdis.doc. [9] S. McDonald. SQL Injection: Modes of attack, defense, and why it matters. White paper, GovernmentSecurity.org, April 2002. [10] Abhishek Kumar Baranwal, Approaches to detect SQL injection and XSS in web applications. EECE 571B, TERM SURVEY PAPER, APRIL 2012 [11] Y. Huang, F. Yu, C. Hang, C. H. Tsai, D. T. Lee, and S. Y. Kuo. Securing Web Application Code by Static Analysis and Runtime Protection. In Proceedings of the 12th International World Wide Web Conference (WWW 04), May 2004. [12] V. B. Livshits and M. S. Lam. Finding Security Errors in Java Programs with Static Analysis. In Proceedings of the 14th Usenix Security Symposium, pages 271 286, Aug. 2005. [13] D. Scott and R. Sharp. Abstracting Application-level Web Security. In Proceedings of the 11th International Conference on the World Wide Web (WWW 2002), pages 396 407, 2002. [14] G. Wassermann and Z. Su. An Analysis Framework for Security in Web Applications. In Proceedings of the FSE Workshop on Specification and Verification of Component-Based Systems (SAVCBS 2004), pages 70 78, 2004. [15] S. W. Boyd and A. D. Keromytis. SQLrand: Preventing SQL Injection Attacks. In Proceedings of the 2nd Applied Cryptography and Network Security (ACNS) Conference, pages 292 302, June 2004. [16] V. Haldar, D. Chandra, and M. Franz. Dynamic Taint Propagation for Java. In Proceedings 21st Annual Computer Security Applications Conference, Dec. 2005. [17] W. G. Halfond and A. Orso. AMNESIA: Analysis and Monitoring for Neutralizing SQL-Injection Attacks. In Proceedings of the IEEE and ACM International Conference on Automated Software Engineering (ASE 2005), Long Beach, CA, USA, Nov 2005. [18] W. G. Halfond and A. Orso. Combining Static Analysis and Runtime Monitoring to Counter SQL-Injection Attacks. In Proceedings of the Third International ICSE Workshop on Dynamic Analysis (WODA 2005), pages 22 28, St. Louis, MO, USA, May 2005. [19] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans. Automatically Hardening Web Applications Using Precise Tainting Information. In Twentieth IFIP International Information Security Conference (SEC 2005), May 2005. [20] T. Pietraszek and C. V. Berghe. Defending Against Injection Attacks through Context-Sensitive String Evaluation. In Proceedings of Recent Advances in Intrusion Detection (RAID2005), 2005. [21] Haeng Kon Kim. Frameworks for SQL retrieval on Web Application Security. In Proceedings of the International Multiconference of Engineers and Computer Scientists, volume 1, page 5, Hong Kong, 2010. IMECS, International Association of Engineers. [22] F. Valeur, D. Mutz, and G. Vigna. A Learning-Based Approach to the Detection of SQL Attacks. In Proceedings of the Conference on Detection of Intrusions and Malware and Vulnerability Assessment (DIMVA), Vienna, Austria, July 2005. [23] D. Aucsmith. Creating and Maintaining Software that Resists Malicious Attack. http://www.gtisc.gatech.edu/bio aucsmith.html, September 2004. Distinguished Lecture Series. [24] C. Anley. Advanced SQL Injection In SQL Server Applications. White paper, Next Generation Security Software Ltd., 2002. [25] Subodh Raikar, SQL Injection Prevention using Runtime Query Modeling and Keyword Randomization. [26] T. O. Foundation. Top Ten Most Critical Web Application Vulnerabilities,2005http://www.owasp.org/documentation/topten.html [27] C. Gould, Z. Su, and P. Devanbu. JDBC Checker: A Static Analysis Tool for SQL/JDBC Applications. In Proceedings of the 26th International Conference on Software Engineering (ICSE 04) Formal Demos, pages 697 698, 2004. [28] N. W. Group. RFC 2616 Hypertext Transfer Protocol HTTP/1.1. Request for comments, The Internet Society, 1999. [29] M. Howard and D. LeBlanc. Writing Secure Code. Microsoft Press, Redmond, Washington, second edition, 2003. [30] Y. Huang, S. Huang, T. Lin, and C. Tsai. Web Application Security Assessment by Fault Injection and Behavior Monitoring. In Proceedings of the 11th International World Wide Web Conference (WWW 03), May 2003. [31] O. Maor and A. Shulman. SQL Injection Signatures Evasion. White paper, Imperva, April 2004. http://www.imperva.com/application defense center/white papers/sql injection signatures evasion.html. [32] M. Martin, B. Livshits, and M. S. Lam. Finding Application Errors and Security Flaws Using PQL: A Program Query Language. In Proceedings of the 20th annual ACM SIGPLAN conference on Object oriented programming systems languages and applications (OOPSLA 2005), pages 365 383, 2005. [33] R. McClure and I. Kr uger. SQL DOM: Compile Time Checking of Dynamic SQL Statements. In Proceedings of the 27th International Conference on Software Engineering (ICSE 05), pages 88 96, 2005. [34] Z. Su and G. Wassermann. The Essence of Command Injection Attacks in Web Applications. In The 33rd Annual Symposium on Principles of Programming Languages (POPL 2006), Jan. 2006. [35] Stephen Thomas and Laurie Williams. Using Automated Fix Generation to Secure SQL Statements. In Proceedings of the Third International Workshop on Software Engineering for Secure Systems, SESS 07, pages 9, Washington, DC, USA, 2007. IEEE Computer Society. [36] Prabakar, M.A. ; Karthikeyan, M. ; Marimuthu, K. An efficient technique for preventing SQL injection attack using pattern matching algorithm IEEE International Conference on Emerging Trends in Computing, Communication and Nanotechnology (ICE- CCN), 2013 Digital Object Identifier: 10.1109/ICE- CCN.2013.6528551 Publication Year: 2013, Page(s): 503 506 426