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, January 2011 197 An Approach to Detect and Prevent SQL Injection Attacks in Database Using Web Service IndraniBalasundaram 1 Dr. E. Ramaraj2 1 Lecturer, Department of Computer Science, Madurai Kamaraj University, Madurai 2 Director of Computer Centre Alagappa University, Karaikudi. Abstract SQL injection is an attack methodology that targets the data residing in a database through the firewall that shields it. The attack takes advantage of poor input validation in code and ebsite administration. SQL Injection Attacks occur when an attacker is able to insert a series of SQL statements in to a ‘query’ by manipulating user input data in to a web-based application, attacker can take advantages of web application programming security flaws and pass unexpected malicious SQL statements through a web application for execution by the backend database. This paper proposes a novel specification-ba sed methodology for the prevention of SQL injection Attacks. The two most important advantages of the new approach against xisting analogous mechanisms are that, first, it prevents all forms of SQL injection attacks; second, Current technique does not allow the user to access database directly in database server. The innovative technique â€Å"Web Service Oriented XPATH Authentication Technique† is to detect and prevent SQLInjection Attacks in database the deployment of this technique is by generating functions of two filtration models that are Active Guard and Service Detector of application scripts additionally allowing seamless integration with currently-deployed systems. General TermsLanguages, Security, Verification, Experimentation. Keywords Database security, world-wide web, web application security, SQL injection attacks, Runtime Monitoring changes to data. The fear of SQL injection attacks has become increasingly frequent and serious. . SQL-Injection Attacks are a cl ass of attacks that many of these systems are highly vulnerable to, and there is no known fool-proof defend against such attacks. Compromise of these web applications represents a serious threat to organizations that have deployed them, and also to users who trust these systems to store confidential data. The Web applications hat are vulnerable to SQL-Injection attacks user inputs the attacker’s embeds commands and gets executed [4]. The attackers directly access the database underlying an application and leak or alter confidential information and execute malicious code [1][2]. In some cases, attackers even use an SQL Injection vulnerability to take control and corrupt the system that hosts the Web application. The increasing number of web applications falling prey to these attacks is alarmingly high [3] Prevention of SQLIA’s is a major challenge. It is difficult to implement and enforce a rigorous defensive coding discipline. Many olutions based on defensive coding ad dress only a subset of the possible attacks. Evaluation of â€Å"â€Å"Web Service Oriented XPATH Authentication Technique† has no code modification as well as automation of detection and prevention of SQL Injection Attacks. Recent U. S. industry regulations such as the Sarbanes-Oxley Act [5] pertaining to information security, try to enforce strict security compliance by application vendors. 1. Introduction 1. 1 SAMPLE – APPLICATION Information is the most important business asset in today’s environment and achieving an appropriate level of Information Security. SQL-Injection Attacks (SQLIA’s) re one of the topmost threats for web application security. For example financial fraud, theft confidential data, deface website, sabotage, espionage and cyber terrorism. The evaluation process of security tools for detection and prevention of SQLIA’s. To implement security guidelines inside or outside the database it is recommended to access the sensitive databases should be monitored. It is a hacking technique in which the attacker adds SQL statements through a web application's input fields or hidden parameters to gain access to resources or make Application that contain SQL Injection vulnerability.The example refers to a fairly simple vulnerability that could be prevented using a straightforward coding fix. This example is simply used for illustrative purposes because it is easy to understand and general enough to illustrate many different types of attacks. The code in the example uses the input parameters LoginID, password to dynamically build an SQL query and submit it to a database. For example, if a user submits loginID and password as â€Å"secret,† and â€Å"123,† the application dynamically builds and submits the query: Manuscript received January 5, 2011 Manuscript revised January 20, 2011 198IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 SELECT * from FROM loginID=’secret’ AND pass1=123 user_info WHERE If the loginID and password match the corresponding entry in the database, it will be redirect to user_main. aspx page other wise it will be redirect to error. aspx page. 1. dim loginId, Password as string 2. loginId = Text1. Text 3. password = Text2. Text 3. cn. open() 4. qry=†select * from user_info where LoginID=’† & loginID & â€Å"’ and pass1=† & password & â€Å"† 5. cmd=new sqlcommand(qry,cn) 6. rd=cmd. executereader() 7. if (rd. Read=True) Then 8. Response. redirect(â€Å"user_main. spx†) 9. else 10. Response. redirect(â€Å"error. aspx†) 11. end if 12. cn. close() 13. cmd. dispose() b. Union Query In union-query attacks, Attackers do this by injecting a statement of the form: UNION SELECT because the attackers completely control the second/injected query they can use that query to retrieve information from a specified table. The result of this attack is that th e database returns a dataset that is the union of the results of the original first query and the results of the injected second query. Example: An attacker could inject the text â€Å"’ UNION SELECT pass1 from user_info where LoginID=’secret – -† nto the login field, which produces the following query: SELECT pass1 FROM user_info WHERE loginID=’’ UNION SELECT pass1 from user_info where LoginID=’secret’ — AND pass1=’’ Assuming that there is no login equal to â€Å"†, the original first query returns the null set, whereas the second query returns data from the â€Å"user_info† table. In this case, the database would return column â€Å"pass1† for account â€Å"secret†. The database takes the results of these two queries, unions them, and returns them to the application. In many applications, the effect of this operation is that the value for â€Å"pass1† is displayed along with the account informationFigure 1: Example of . NET code implementation. 1. 2 Techniques of SQLIA’S Most of the attacks are not in isolated they are used together or sequentially, depending on the specific goals of the attacker. a. Tautologies Tautology-based attack is to inject code in one or more conditional statements so that they always evaluate to true. The most common usages of this technique are to bypass authentication pages and extract data. If the attack is successful when 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=’’ The code injected in the conditional (OR 1=1) transforms the entire WHERE clause into a tautology the query evaluates to true for each row in the table and returns a ll of them. In our example, the returned set evaluates to a not null value, which causes the application to conclude that the user authentication was successful. Therefore, the application would invoke method user_main. aspx and to access the application [6] [7] [8]. c. Stored Procedures SQL Injection Attacks of this type try to execute stored procedures present in the database.Today, most database vendors ship databases with a standard set of stored procedures that extend the functionality of the database and allow for interaction with the operating system. Therefore, once an attacker determines which backend database is in use, SQLIAs can be crafted to execute stored procedures provided by that specific database, including procedures that interact with the operating system. It is a common misconception that using stored procedures to write Web applications renders them invulnerable to SQLIAs. Developers are often surprised to find that their stored procedures can be just as vulner able o attacks as their normal applications [18, 24]. Additionally, because stored procedures are often written in special scripting languages, they can contain other types of vulnerabilities, such as buffer overflows, that allow attackers to run arbitrary code on the server or escalate their privileges. CREATE PROCEDURE DBO. UserValid(@LoginID varchar2, @pass1 varchar2 AS EXEC(â€Å"SELECT * FROM user_info WHERE loginID=’† [email  protected]+ â€Å"’ and pass1=’† [email  protected]+ â€Å"’†);GO Example: This example demonstrates how a parameterized stored procedure can be exploited via an SQLIA. In the example, we assume that the query string constructed at ines 5, 6 and 7 of our example has been replaced by a call IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 to the stored procedure defined in Figure 2. The stored procedure returns a true/false value to indicate whether the u ser’s credentials authenticated correctly. To launch an SQLIA, the attacker simply injects â€Å" ’ ; SHUTDOWN; –† into either the LoginID or pass1 fields. This injection causes the stored procedure to generate the following query: SELECT * FROM user_info WHERE loginID=’secret’ AND pass1=’; SHUTDOWN; -At this point, this attack works like a piggy-back attack.The first query is executed normally, and then the second, malicious query is executed, which results in a database shut down. This example shows that stored procedures can be vulnerable to the same range of attacks as traditional application code [6] [11] [12] [10] [13] [14] [15]. d. Extended stored procedures IIS(Internet Information Services) Reset There are several extended stored procedures that can cause permanent damage to a system[19]. Extended stored procedure can be executed by using login form with an injected command as the LoginId LoginId:';execmaster.. xp_xxx;-Passwo rd:[Anything] LoginId:';execmaster.. p_cmdshell'iisreset';-Password:[Anything] select password from user_info where LoginId=†; exec master.. xp_cmdshell ‘iisreset'; –‘ and Password=† This Attack is used to stop the service of the web server of particular Web application. Stored procedures primarily consist of SQL commands, while XPs can provide entirely new functions via their code. An attacker can take advantage of extended stored procedure by entering a suitable command. This is possible if there is no proper input validation. xp_cmdshell is a built-in extended stored procedure that allows the execution of arbitrary command lines. For example: exec master.. p_cmdshell ‘dir' will obtain a directory listing of the current working directory of the SQL Server process. In this example, the attacker may try entering the following input into a search form can be used for the attack. When the query string is parsed and sent to SQL Server, the server wi ll process the following code: SELECT * FROM user_info WHERE input text =† exec master.. xp_cmdshell LoginId /DELETE'–‘ 199 Here, the first single quote entered by the user closes the string and SQL Server executes the next SQL statements in the batch including a command to delete a LoginId to the user_info table in the database. . Alternate Encodings Alternate encodings do not provide any unique way to attack an application they are simply an enabling technique that allows attackers to evade detection and prevention techniques and exploit vulnerabilities that might not otherwise be exploitable. These evasion techniques are often necessary because a common defensive coding practice is to scan for certain known â€Å"bad characters,† such as single quotes and comment operators. To evade this defense, attackers have employed alternate methods of encoding their attack strings (e. g. , using hexadecimal, ASCII, and Unicode character encoding).Common scanning an d detection techniques do not try to evaluate all specially encoded strings, thus allowing these attacks to go undetected. Contributing to the problem is that different layers in an application have different ways of handling alternate encodings. The application may scan for certain types of escape characters that represent alternate encodings in its language domain. Another layer (e. g. , the database) may use different escape characters or even completely different ways of encoding. For example, a database could use the expression char(120) to represent an alternately-encoded character x†, but char(120) has no special meaning in the application language’s context. An effective code-based defense against alternate encodings is difficult to implement in practice because it requires developers to consider of all of the possible encodings that could affect a given query string as it passes through the different application layers. Therefore, attackers have been very succe ssful in using alternate encodings to conceal their attack strings. Example: Because every type of attack could be represented using an alternate encoding, here we simply provide an example of how esoteric an alternativelyencoded attack could appear.In this attack, the following text is injected into the login field: â€Å"secret’; exec(0x73687574646f776e) – – †. The resulting query generated by the application is: SELECT * FROM user_info WHERE loginID=’secret’; exec(char(0x73687574646f776e)) — AND pass1=’’ This example makes use of the char() function and of ASCII hexadecimal encoding. The char() function takes as a parameter an integer or hexadecimal encoding of a character and returns an instance of that character. The stream of numbers in the second part of the injection is the 200 IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. , January 2011 ASCII hexadecimal encoding of the strin g â€Å"SHUTDOWN. † Therefore, when the query is interpreted by the database, it would result in the execution, by the database, of the SHUTDOWN command. References: [6] f. Deny Database service This attack used in the websites to issue a denial of service by shutting down the SQL Server. A powerful command recognized by SQL Server is SHUTDOWN WITH NOWAIT [19]. This causes the server to shutdown, immediately stopping the Windows service. After this command has been issued, the service must be manually restarted by the administrator. select password from user_info whereLoginId=';shutdown with nowait; –‘ and Password='0' The ‘–‘ character sequence is the ‘single line comment' sequence in Transact – SQL, and the ‘;' character denotes the end of one query and the beginning of another. If he has used the default sa account, or has acquired the required privileges, SQL server will shut down, and will require a restart in order to f unction again. This attack is used to stop the database service of a particular web application. Select * from user_info where LoginId=’1;xp_cmdshell ‘format c:/q /yes ‘; drop database mydb; –AND pass1 = 0 This command is used to format the C: drive used by the ttacker. 2. Related Work There are existing techniques that can be used to detect and prevent input manipulation vulnerabilities. 2. 1 Web Vulnerability Scanning Web vulnerability scanners crawl and scan for web vulnerabilities by using software agents. These tools perform attacks against web applications, usually in a black-box fashion, and detect vulnerabilities by observing the applications’ response to the attacks [18]. However, without exact knowledge about the internal structure of applications, a black-box approach might not have enough test cases to reveal existing vulnerabilities and also have alse positives. 2. 2 Intrusion Detection System (IDS) Valeur and colleagues [17] propose the use of an Intrusion Detection System (IDS) to detect SQLIA. Their IDS system is based on a machine learning technique that is trained using a set of typical application queries. The technique builds models of the typical queries and then monitors the application at runtime to identify queries that do not match the model in that it builds expected query models and then checks dynamically-generated queries for compliance with the model. Their technique, however, like most techniques based on learning, can generate large umber of false positive in the absence of an optimal training set. Su and Wassermann [8] propose a solution to prevent SQLIAs by analyzing the parse tree of the statement, generating custom validation code, and wrapping the vulnerable statement in the validation code. They conducted a study using five real world web applications and applied their SQLCHECK wrapper to each application. They found that their wrapper stopped all of the SQLIAs in their attack set without g enerating any false positives. While their wrapper was effective in preventing SQLIAs with modern attack structures, we hope to shift the focus rom the structure of the attacks and onto removing the SQLIVs. 2. 3 Combined Static and Dynamic Analysis. AMNESIA is a model-based technique that combines static analysis and runtime monitoring [1][7]. In its static phase, AMNESIA uses static analysis to build models of the different types of queries an application can legally generate at each point of access to the database. In its dynamic phase, AMNESIA intercepts all queries before they are sent to the database and checks each query against the statically built models. Queries that violate the model are identified as SQLIA’s and prevented from executing on the database.In their evaluation, the authors have shown that this technique performs well against SQLIA’s. The primary limitation of this technique is that its success is dependent on the accuracy of its static analysis f or building query models. Certain types of code obfuscation or query development techniques could make this step less precise and result in both false positives and false negatives Livshits and Lam [16] use static analysis techniques to detect vulnerabilities in software. The basic approach is to use information flow techniques to detect when tainted input has been used to construct an SQL query. These ueries are then flagged as SQLIA vulnerabilities. The authors demonstrate the viability of their technique by using this approach to find security vulnerabilities in a benchmark suite. The primary limitation of this approach is that it can detect only known patterns of SQLIA’s and, IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 because it uses a conservative analysis and has limited support for untainting operations, can generate a relatively high amount of false positives. Wassermann and Su propose an approach that uses stati c analysis combined with automated reasoning to verify that he SQL queries generated in the application layer cannot contain a tautology [9]. The primary drawback of this technique is that its scope is limited to detecting and preventing tautologies and cannot detect other types of attacks. 3. Proposed Technique This Technique is used to detect and prevent SQLIA’s with runtime monitoring. The solution insights behind the technique are that for each application, when the login page is redirected to our checking page, it was to detect and prevent SQL Injection attacks without stopping legitimate accesses. Moreover, this technique proved to be efficient, imposing only a low overhead on the Web pplications. The contribution of this work is as follows: A new automated technique for preventing SQLIA’s where no code modification required, Webservice which has the functions of db_2_XMLGenrerator and XPATH_ Validator such that it is an XML query language to select specific part s of an XML document. XPATH is simply the ability to traverse nodes from XML and obtain information. It is used for the temporary storage of sensitive data’s from the database, Active Guard model is used to detect and prevent SQL Injection attacks. Service Detector model allow the Authenticated or legitimate user to access the web applications.The SQLIA’s are captured by altered logical flow of the application. Innovative technique (figure:1) monitors dynamically generated queries with Active Guard model and Service Detector model at runtime and check them for compliance. If the Data Comparison violates the model then it represents potential SQLIA’s and prevented from executing on the database. This proposed technique consists of two filtration models to prevent SQLIA’S. 1) Active Guard filtration model 2) Service Detector filtration model. The steps are summarized and then describe them in more detail in following sections. a. Active Guard Filtration Mod elActive Guard Filtration Model in application layer build a Susceptibility detector to detect and prevent the Susceptibility characters or Meta characters to prevent the malicious attacks from accessing the data’s from database. b. Service Detector Filtration Model Service Detector Filtration Model in application layer validates user input from XPATH_Validator where the Sensitive data’s are stored from the Database at second 201 level filtration model. The user input fields compare with the data existed in XPATH_Validator if it is identical then the Authenticated /legitimate user is allowed to proceed. c. Web Service LayerWeb service builds two types of execution process that are DB_2_Xml generator and XPATH_ Validator. DB_2_Xml generator is used to create a separate temporary storage of Xml document from database where the Sensitive data’s are stored in XPATH_ Validator, The user input field from the Service Detector compare with the data existed in XPATH_ Val idator, if the data’s are similar XPATH_ Validator send a flag with the count iterator value = 1 to the Service Detector by signifying the user data is valid. Procedures Executed in Active Guard Function stripQuotes(ByVal strWords) stripQuotes = Replace(strWords, â€Å"‘†, â€Å"†Ã¢â‚¬ ) Return stripQuotesEnd Function Function killChars(ByVal strWords) Dim arr1 As New ArrayList arr1. Add(â€Å"select†) arr1. Add(â€Å"–â€Å") arr1. Add(â€Å"drop†) arr1. Add(â€Å";†) arr1. Add(â€Å"insert†) arr1. Add(â€Å"delete†) arr1. Add(â€Å"xp_†) arr1. Add(â€Å"‘†) Dim i As Integer For i = 0 To arr1. Count – 1 strWords = Replace(strWords, arr1. Item(i), â€Å"†, , , CompareMethod. Text) Next Return strWords End Function IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 202 Figure 2: proposed Architecture Procedures Executed in Service D etector navi. Compile(â€Å"/Main_Tag/Details[LoginId='† & userName & â€Å"‘ and Password=† & Password & â€Å"]†) _Public Sub Db_2_XML() adapt=New SqlDataAdapter(â€Å"select LoginId,Password from user_info†, cn) Dim nodes As XPathNodeIterator = navi. Select(expr) Dim count2 As Integer = nodes. Count. ToString() Return count2 dst = New DataSet(â€Å"Main_Tag†) End Function adapt. Fill(dst, â€Å"Details†) dst. WriteXml(Server. MapPath(â€Å"XML_DATAXML_D ATA. xml†)) End Sub Procedures Executed in Web Service _ Public Function XPath_XML_Validation(ByVal userName As String, ByVal Password As Integer) As Integer Dim xpathdoc As New XPathDocument(Server. MapPath(â€Å"XML_DATAX ML_DATA. xml†)) Dim navi As XPathNavigator = xpathdoc. CreateNavigator() Dim expr As XPathExpression = . Identify hotspot This step performs a simple scanning of the application code to identify hotspots. Each hotspot will be verified with the Active Server to remove the susceptibility character the sample code (figure: 2) states two hotspots with a single query execution. (In . NET based applications, interactions with the database occur through calls to specific methods in the System. Data. Sqlclient namespace, 1 such as Sqlcommand- . ExecuteReader (String)) the hotspot is instrumented with monitor code, which matches dynamically generated queries against query models. If a generated query is matched with Active Guard, then it is onsidered an attack. 3. 1 Comparison of Data at Runtime Monitoring When a Web application fails to properly sanitize the parameters, which are passed to, dynamically created SQL statements (even when using parameterization techniques) it is possible for an attacker to alter the construction of back-end SQL statements. IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 When an attacker is able to modify an SQL statement, the statement will execute with t he same rights as the application user; when using the SQL server to execute commands that interact with the operating system, the rocess 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 (Figure: 1) append 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_PATH Validator. Service Detector receive the validated user input from Active Guard and send through the protocol SOAP (Simple Obj ect 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 alue = 0 to Service Detector through the SOAP protocol then the illegitimate/invalid user is not Authenticated to access the web application. In figure 3: 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 XPATH document the instance Navigator is used to search by using cursor in the selected XML document.With in the XPATH validator, Compile is a method which is used to match the element with the existing document. The navigator will be created in the xpathdocument using select method result will be redirected to the XPATH 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 trings 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, 203 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 XPATH Authentication Technique does not allow directly to ccess database in database server. 4. EVALUATIONS The proposed technique is deployed and tried few trial runs on the web server. Table 1: SQLIA’S Prevention Accuracy SQL Injection Types Unprotected Protected 1. TAUTOLOGIES Not Prevented Prevented 2. PIGGY BACKED QUERIES Not Prevented Prevented 3. STORED PROCEDURE Not Prevented Prevented 4. ALTERNATIVE ENCODING Not Prevented Prevented 5. UNION Not Prevented Prevented Table 2: Execution Time comparison for proposed technique Total Number of Entries in Database Execution Time in Millisecond Existing Proposed Technique Technique 1000 1640000 46000 2000 1420000 93000 3000 1040000 6000 4000 1210000 62000 5000 1670000 78000 6000 1390000 107000 T he above given table 2 illustrate the execution time taken for the proposed technique with the existing technique. 4. 1 SQLIA Prevention Accuracy Both the protected and unprotected web Applications are tested using different types of SQLIA’s; namely use of Tautologies, Union, Piggy-Backed Queries, Inserting additional SQL statements, Second-order SQL injection and various other SQLIA s. Table 1 shows that the proposed technique prevented all types of SQLIA s in all cases. The proposed technique is thus a secure and robust solution to defend against SQLIA’sIJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 204 4. 2 Execution Time at Runtime Validation The runtime validation incurs some overhead in terms of execution time at both the Web Service Oriented XPATH Authentication Technique and SQL-Query based Validation Technique. Taken a sample website ETransaction measured the extra computation time at the query validation, th is delay has been amplified in the graph (figure: 4 and figure:5) to distinguish between the Time delays using bar chart shows that the data validation in XML_Validator performs better than query validation.In Query validation(figure:5) 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. Web Service Oriented XPATH Authentication Technique (figure: 4) states that 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 ompared with the sensitive data, which is temporarily stored in dataset. If it is malicious data, it will be prevented otherwise the legitimate data is allowed to access the Web application. 5. C ONCLUSION SQL Injection Attacks attempts to modify the parameters of a Web-based application in order to alter the SQL statements that are parsed to retrieve data from the database. Any procedure that constructs SQL statements could potentially be vulnerable, as the diverse nature of SQL and the methods available for constructing it provide a wealth of coding options. 1800000 Execution time in Milli Sec 1600000 1400000 1200000 000000 Proposed Technique Existing Technique 800000 600000 400000 200000 0 1000 2000 3000 4000 5000 6000 Total Number of Entries in Database Figure4: Execution Time comparison for proposed technique (data validation in X-path) with existing technique The primary form of SQL injection consists of direct insertion of code into parameters that are concatenated with SQL commands and executed. This technique is used to detect and prevent the SQLI flaw (Susceptibility characters & exploiting SQL commands) in Susceptibility Detector and prevent the Susceptibility att acker Web Service Oriented XPATH Authentication Technique hecks the user input with valid database which is stored separately in XPATH and do not 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 This proposed technique was able to suitably classify the attacks that performed on the applications without blocking legitimate accesses to the database (i. e. , the technique produced neither false positives nor false negatives). These results show that our technique represents a promising approach to countering SQLIA’s and motivate further work in this irection References [1] William G. J. Halfond and Alessandro Orso , â€Å"AMNESIA: Analysis and Monitoring for Neutralizing SQLInjection Attacks†, ASE’05, November 7–11, 2005 [2] William G. J. Hal fond and Alessandro Orso, â€Å"A Classification of SQL injection attacks and countermeasure s†,proc IEEE int’l Symp. Secure Software Engg. , Mar. 2006. IJCSNS International Journal of Computer Science and Network Security, VOL. 11 No. 1, January 2011 [3] Muthuprasanna, Ke Wei, Suraj Kothari, â€Å"Eliminating SQL Injection Attacks – A TransparentDefenceMechanism†, SQL Injection Attacks Prof. Jim Whitehead CMPS 183. Spring 2006, May 17, 2006 4] William G. J. Hal fond, Alessandro Orso, â€Å"WASP: Protecting Web Applications Using Positive Tainting and Syntax-Aware Evaluation IEEE Software Engineering, VOL. 34, NO. 1January/February 2008 [5] K. Beaver, â€Å"Achieving Sarbanes-Oxley compliance for Web applications†, http://www. spidynamics. com/support/whitepapers/, 2003 [6] C. Anley, â€Å"Advanced SQL Injection In SQL Server Applications,† White paper, Next Generation Security Software Ltd. , 2002. [7] W. G. J. Halfond and A. Orso, â€Å"Combining Static Analysis and Runtime Monitoring to Counter SQL Injection Attacks,† 3rd International Workshop on Dynamic Analysis, 2005, pp. – 7 [8] Z. Su and G. Wassermann, â€Å"The Essence of Command Injection Attacks in Web Applications,† 33rd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 2006, pp. 372-382. [9] G. Wassermann and Z. Su. An Analysis Framework for Security in Web Applications. In Proceedings of the FSE Workshop on Specification and Verification of componentBased Systems (SAVCBS 2004), pages 70–78, 2004. [10] P. Finnigan, â€Å"SQL Injection and Oracle – Parts 1 & 2,† Technical Report, Security Focus, November 2002. http://securityfocus. com/infocus/1644 [11] 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. as px. [12] E. M. Fayo, â€Å"Advanced SQL Injection in Oracle Databases,† Technical report, Argeniss Information Security, Black Hat Briefings, Black Hat USA, 2 005. [13] C. A. Mackay, â€Å"SQL Injection Attacks and Some Tips on How to Prevent them,† Technical report, The Code Project, January 2005. http://www. codeproject. com/cs/database/ qlInjectionAttacks. asp. [14] S. McDonald. SQL Injection: Modes of attack, defense, and why it matters. White paper, GovernmentSecurity. org, April 2002. http://www. governmentsecurity. rg/articles/SQLInjectionM odesofAttackDefenceandWhyItMatters. php [15] S. Labs. SQL Injection. White paper, SPI Dynamics, Inc. ,2002. http://www. spidynamics. com/assets/documents/Whitepaper SQLInjection. pdf. [16] 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. [17] F. Valeur and 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 Vulnerability Assessment (DIMVA), July 20 05. [18] Kals, S. Kirda, E. , Kruegel, C. , and Jovanovic, N. 2006. SecuBat: a web vulnerability scanner. In Proceedings of the 205 15th International Conference on World Wide Web. WWW '06. ACM Press, pp. 247-256. [19] Sql injection – HSC Guides – Web App Security Written by Ethical Hacker sunday, 17 February 2008. http://sqlinjections. blogspot. com/2009/04/sql-injection-hscguides-web-app. html. Prof. E. Ramaraj is presently working as a Technology Advisor, Madurai Kamaraj University, Madurai, Tamilnadu, India on lien from Director, computer centre at Alagappa university, Karaikudi. He has 22 years teaching experience and 8 years esearch experience. He has presented research papers in more than 50 national and international conferences and published more than 55 papers in national and international journals. His research areas include Data mining, software engineering, database and network security. B. Indrani received the B. Sc. degree in Computer Science, in 2002; t he M. Sc. degree in Computer Science and Information Technology, in 2004. She had completed M. Phil. in Computer Science. She worked as a Research Assistant in Smart and Secure Environment Lab under IIT, Madras. Her current research interests include Database Security.