SQL Injection Attack & Its Prevention

Transcription

1 e-issn Volume 2 Issue 6, June 2016 pp Scientific Journal Impact Factor : SQL Injection Attack & Its Prevention Amey Anil Patil L.B.H.S.S.T s Institute Of Computer Application S.N.341,Next to New English School,Govt. Colony Bandra(E) Abstract The SQL injection is perhaps one of the most common application layer attack techniques used by hackers now a days to steal important data from database in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. This attack takes the advantage of improper or poor coding of web application that allows the unauthorized user to stole, modify or destroy the data by injecting SQL commands. In this paper some of the approaches are discussed to detect and successfully avoid the SQL injecting attack. Keywords Injection attack, Injection detection, structured query language, Prevention tool assessment, Security, Database language I. INTRODUCTION SQL injection is the database equivalent of the remote arbitrary code execution vulnerability in an operating system or application. The potential impact of a successful SQL injection attack cannot be underestimated--depending on the database system and application configuration, it can be used by an attacker to cause data loss (as in this case), gain unauthorized access to data, or even execute arbitrary code on the host machine itself. Almost all the Web applications allow legitimate website visitors to submit and retrieve data to/from a database over the Internet using their preferred web browser. This allows hacker to pass SQL commands (statements) through a web application for execution by the backend database. If not sanitized properly, web applications may result in SQL Injection attacks that allow hackers to view information from the database and/or even wipe it out. II. HOW IT WORKS As the name suggest SQL injection works by injecting the SQL statements in the input fields provided to obtain input from the user. Any person with the little knowledge of SQL queries can manipulate and misuse the database by injecting malicious code. If take the example of product table where user inputs the product name to search the product detail. Now the respective query for this scenario can be as following Select * from Products where Product_name = '$ProductName' Now if the variables $ProductName is requested directly from the user s input, this can easily be compromised. Here Attacker can insert input as book' OR 1=1 Now the subsequent query will be generated as Select * from Products where Product_name = 'book' or 1=1. As the inputs of the web application are not properly sanitized, the use of the single quotes has turned the WHERE SQL command into a two-component All rights Reserved 349

2 where 1=1 part guarantees to be true regardless of what the first part contains and gives all details from table product. Now if we take the other scenario where database supports execution of multiple SQL statements separated by commas, we can also inject another SQL query. Let s say we can even drop the table. If hacker enters the string "book';delete * from Products;" then query becomes the following two queries SELECT * FROM PRODUCTS WHERE PRODUCT_NAME = 'BOOK' ; DROP TABLE PRODUCTS;'PREPARE YOUR PAPER BEFORE STYLING III. PREVENTION TECHNIQUES A) Prepared Statements (Parameterized Queries) The use of prepared statements is however all developers ought to 1st be educated a way to write information queries. They re easy to put in writing, and easier to know. Prepared statements are noting however wherever the SQL Command uses a parameter rather than injecting the values directly into the command. Parameterized queries force the developer to 1st outline all the SQL code, so pass in every parameter to the question later. This committal to writing vogue permits the information to differentiate between code and information, despite what user input is equipped. Prepared statements make sure that associate degree wrongdoer isn't ready to amendment the intent of a question, notwithstanding SQL commands are inserted by associate degree wrongdoer. Most of the languages support parameter queries. The subsequent e.g. shows a way to use Parameterized Queries in asp.net String commandtext = "SELECT * FROM Students "+ "WHERE City=@CityName"; SqlCommand cmd = new SqlCommand(commandText, conn); cmd.parameters.add=@cityname ",CityName); B) Use Stored Procedures Stored Procedures add an additional layer of abstraction in to the look of a package thus victimization keep Procedures is additionally one among the nice follow to avoid SQL injection since store procedure sometimes doesn't embrace unsafe dynamic SQL generation. Just in case of victimization store procedures SQL code for a keep procedure is outlined and keep within the information itself, then referred to as from the appliance. You can additionally use parameters for the shop procedures also will decrease the chance issue. The most advantage of using store procedure over easy SQL question is it may be written to validate any input that's sent to them to confirm the integrity of the information on the far side the straightforward constraints otherwise offered on the tables. Parameters may be checked for valid ranges and information may be cross checked with knowledge in different tables. C) Escaping all user supplied inputs:- This third technique is to flee user input before swing it in an exceedingly question.however, this technique is frail compared to victimization parameterized queries and that we cannot guarantee it'll stop all SQL Injection. The core basic behind operating of this method is that nearly all database management system supports one or additional character escaping schemes specific to sure forms of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection All rights Reserved 350

3 D) White List Input Validation White list validation is suitable for all input fields provided by the user. White list validation involves shaping precisely what's licensed, and by definition, everything else isn't licensed. If it's well-structured information, like dates, social insurance numbers, zip codes, addresses, etc. then the developer ought to be ready to outline a really robust validation pattern, typically supported regular expressions, for certificatory such input. If the input field comes from a set of choices, sort of a change posture list or radio buttons, then the input has to match precisely one in all the values offered to the user within the initial place. The foremost troublesome fields to validate are therefore known as 'free text' fields, like diary entries. However, even those varieties of fields is valid to some extent, you'll be able to a minimum of exclude all non-printable characters, and outline a most size for the input field. E) Least Privilege To minimize the potential harm of a prosperous SQL injection attack, you must minimize the privileges appointed to each information account in your surroundings. Don t assign DBA or admin sort access rights to your application accounts. we have a tendency to perceive that this can be simple, and everything simply works once you couple this manner, however it's terribly dangerous. Begin from the bottom up to see what access rights your application accounts need, instead of attempting to work out what access rights you wish to require away. Ensure that accounts that solely want browse access area unit solely granted browse access to the tables they have access to. If Associate in nursing account solely desires access to parts of a table, take into account making a read that limits access thereto portion of the information and distribution the account access to the read instead, instead of the underlying table. Rarely, if ever, grant produce or delete access to information accounts. IV. RELATED WORK Over years, many tools for detection and prevention of SQL Injection attacks have been developed. AMNESIA developed by Halfond and Orso in Extracting Data is a detection and prevention tool for SQL injection attack. It uses static analysis and runtime monitoring for the purpose. The tool builds a model of the legitimate queries at each hotspot i.e. where SQL queries are issued to database engine and monitors the application at runtime to ensure that all generated queries match the statically-generated model. In Adding or Modifying Data, a tool named CANDID is proposed for detecting SQL injection. The tool dynamically infers the programmer-intended query structure on any input, and detects attacks by comparing them against the intended query structure. In Performing Denial of Service, SQLRand uses instruction set randomization to detect and abort queries with injected code and every SQL keyword is joined with a random integer to mislead the attacker. The proposed technique in Evading Detection prevents SQLIA in stored procedures by combining static application code analysis with runtime validation. In the static part, a stored procedure parser is designed and it instruments the necessary statements in order to compare the original SQL statement structure to that including user inputs for every SQL statement which depends on user inputs. The technique abstracts the intended SQL query behavior in an application in the form of an SQL-graph and this graph is then validated against all the different user inputs at runtime to capture all malicious SQL queries, before they are sent for execution. Almost every solution given to detect or prevent SQL Injection attacks is either for application layer or for database layer. But none of them provide security at both application and database layers. Also very little emphasis is laid on preventing SQL Injection attacks in All rights Reserved 351

4 procedures. Although the mechanism of SQLIA is the same for both stored procedure and application layer program, the same detection technique could not be applied to stored procedures, because of limited programmability of stored procedures and the technique's usability and deployability. Many existing techniques, such as filtering, information-flow analysis, penetration testing, and defensive coding, can detect and prevent a subset not all of the vulnerabilities that lead to SQLIAs. V. PROPOSED WORK Here an efficient scheme for detecting and preventing SQL Injection attacks has been introduced. This scheme provides security from both the frontend as well as the backend of the application so that, if security is compromised at one end, the second end can still prevent SQL injection attacks. It consists of two modules: Frontend phase Backend phase. In the frontend phase, user input validation takes place. A list of several malicious known symbols or say anomaly tokens has been maintained. When a user provides an input in the input field, the validation process checks that input and matches it with the anomaly token list and if a match exists then it restricts further access by the attacker. At every illegal attempt a log entry will be saved in the database in which the date, time, page of the application on which illegal attempt was made and the IP address of the attacker got saved. The IP address can help us track the attacker in future if we want to. In this way one can prevent SQLIA (SQL Injection Attacks) through the frontend of the application as shown Fig 1.Front end prevention flowchart But if by any means the attacker gets the ability to compromise the frontend security even then he is not able to access the database because of the backend security phase. In the backend phase SQLIA has been prevented through database stored procedures. First the tool gets all the stored procedures that are in the database and then analyzes them one by one. The stored procedure code is searched for any hotspots i.e. the point in code where there is vulnerability means possibility of SQL injection. If the tool finds any of such hotspot in the code, it optimizes the code using Transact-SQL technique and updates it in the database. At present the All rights Reserved 352

5 works on MSSQL server but in future can be made to work with any server. For MSSQL, the tool searches the code for + i.e. concatenation symbol and i.e. single quote, because they make the code vulnerable and treat the input as a string, so the attacker can merge any malicious string with the parameters in the query. For example: Create procedure varchar(45) As varchar(max) = 'select * from users where username=' '' ' And password = ' + '' ' ' Exec (@sql) This example shows how a parameterized stored procedure can be exploited via an SQLIA. In this example, we assume that the query string constructed at lines 5, 6 and 7 of our example has been replaced by a call to the stored procedure defined. As we can see this stored procedure is vulnerable because the attacker can merge any malicious query with the username and password. For example: SELECT employees FROM users WHERE login= abc ; SHUTDOWN; -- OR pass= At this point, this attack works like a piggy-back attack. A malicious query gets executed, which results in a database shut down. This example shows that stored procedures can be vulnerable in the same way as traditional application code Identifying Injectable Parameters. But in Transact- SQL any malicious string or query cannot get merged with the parameters because there are no concatenation symbols as mentioned above. For example: Create procedure varchar(45) As select username, password from users where and password In this way, the backend phase can prevent SQL Injection attacks Fig 2.Back end prevention using stored All rights Reserved 353

6 VI. CONCLUSION SQL Injection Attacks is one of the most commonly used, easiest and serious threats to the security of database driven applications and therefore controlling the SQL injection on the web application and maintaining the end privacy is still a key challenge for the web developer. Thus this paper describes how the injection attack can be dangerous and exploit web application and how different protection mechanisms against SQL injection attack can be applied. VII. ACKNOWLEDGMENT The research presented in this paper would not have been possible without my college support. I take this opportunity to express my profound gratitude to all those who help me and gave me their valuable suggestions in the process of making the research. REFERENCES [1] W. G. Halfond, J. Viegas and A. Orso, A Classification of SQL Injection Attacks and Countermeasures, College of Computing Georgia Institute of Technology IEEE, 2006 [2] Atefeh Tajpour, Suhaimi Ibrahim, Mohammad Sharifi, Web Application Security by SQL Injection DetectionTools [3] [4] All rights Reserved 354