ON SQL INJECTION PROTECTION METHODS AND TOOLS

layer on the database as security to prevent SQL injection attack. As stored procedure could be coded by programmer, so, this part is known as an injectable web application. Depending on specific database storage procedure there are different ways to attack. 5. Alternate encoding: most of the SQL injection mechanisms that use filters prohibit the use of quote (‘) in the SQL statement which can be used in constructing different kinds of malicious query requests to the database. In this case for an attacker to bypass such a filter he has to convert SQL query into alternative encoding such as hexadecimal, ASCII or Unicode. Converting SQL query into alternate encode enables them to carry out their attacks. For example "0; exec (0x73587574 64 5f177 6e), " and the result query is: SELECT accounts FROM login WHERE username=" AND password=0; exec (char (0x73687574646j776e)) The above example uses the char () function and ASCII hexadecimal encoding. The char () function takes hexadecimal encoding of character(s) and returns the actual character(s). The stream of numbers in the second part of the injection is ASCII hexadecimal encoding of the attack string. This encoded string is translated into the shutdown command by the database when it is executed. 6. Piggery-backend query attack: some of the database engines support stacked query by default. This feature creates opportunity for attacker to perform dangerous action in the database. In this case a valid query will be terminated by (;) and a malicious query is added. After processing the valid query, a malicious query is then executed, unlike in union query where a malicious query will be joined with a valid query and processed as a single joined query. For example: SELECT * FROM emp_name, ep_address, gender, from employee where emp_id=7; drop employee The above query will drop the employee table after displaying employee information. 7. Stored Procedure: Stored procedure is a part of database where programmers could set an extra abstract layer on the database as security to prevent SQL injection attack. As stored procedure could be coded by programmer, so, this part is known as an injectable web application. Depending on specific database storage procedure there are different ways to attack. 54 Muhammad Saidu Aliero et al. / Jurnal Teknologi (Sciences & Engineering) 77:13 (2015) 49–66 3.0 PROTECTION OF SQLIA Researchers have proposed various methods to handle problems of SQL injection attack. These methods start from development of best practice to automatic tool for detecting and preventing SQL injection attack. Each method comes with its own advantages and drawbacks, but none of the methods were able to solve the entire problem of SQL injection attack. 3.1 Defensive Coding Practice The main cause of SQL injection vulnerability is improper validation of user input. Input validation is a method by which programmers apply defense code practice to secure each static query manually. One of the objectives of defensive programming is to write secure queries so that it behaves in a predictable manner despite unexpected inputs or user actions. Below are some of the common ways by which programmer apply defensive coding in an application. Input type checking/Data type validation: sometimes programmers make simple mistakes by allowing input fields to accept different types of data without realizing that an attacker can take this opportunity to insert malicious input to database engine. SQL injection attacks can be performed by injecting commands into either a string or numeric parameter. Even a simple check of such inputs can prevent many attacks. For example, in the case of numeric inputs, i.e. if the field is a phone number, the programmer can simply reject any input that contains characters other than digits. This method however cannot guaranty that it will fully stop the SQL injection but it makes the process harder for the attacker. Encoding of inputs: sometimes an attacker issues SQL injection attack with a statement that always returns a value of true so that to the database engine interprets user input as SQL so that when backend database engine executes such a statement it allows the user to bypass authentication mechanisms or use meta-characters to perform an illegal query in order to trick the database engine into providing the attacker with some secret information about the backend database. Applying encoding practice such as hashing, encryption, conversion of input into ASCI format prevents attackers from tricking database engines. White listening/Positive pattern matching: there are two primary concepts of pattern matching, blacklist and white list. Blacklisting involves checking if the input contains unacceptable data while white listing checks if the input contains acceptable data. Programmer should establish input validation routines that filter bad input and allow good input. This approach is generally called positive validation. Identify all input: Parameterized query is a type of query which has some placeholders. In these queries instead of making dynamic queries by concatenating the parameters with SQL statement, it will replace the placeholders with the value of parameters at the runtime. 3.1. 1 Disadvantages of Defensive Coding Most programmers prefer to go straight ahead to secure their queries in application layer without realizing the effect when security mechanisms are exposed to attack or new queries are created in the future which force programmers to update each query manually. Below are the most common problems with defensive coding practice. Defensive coding practice is prone to human errors; it is very difficult to exactly and correctly apply to all sources of input. In fact most vulnerability found in web application is because of programmer’s mistake for not adding the security check or inappropriately applied [24]. White listing or blacklisting produce false positives especially when programmers decide to block SQL keywords such as “WHERE”, “SELECT” or operators such as “AND”, “OR” or single quote. This approach clearly results in a high rate of false positives because in many applications, SQL keywords can be part of a normal text entry, and SQL operators can be used to express formulas or even names (e.g., O’Brian, Randy, Orton). Using stored procedures or prepared statements to prevent SQLIA: Unfortunately, stored procedures and prepared statements can also be vulnerable to SQLIA unless developers carefully apply defensive coding guidelines. 3.2 Detection and Prevention Methods To overcome problems in defensive coding approach researcher proposed different methods to overcome the problem of defensive coding. This method can be categorized into static and dynamic methods. In static method programmers try to prevent SQL injection attack by identifying SQL injection vulnerability by specifying all injection parameters even before the application is used for the first time [22]. This method is mostly language specific while dynamic method usually employs the use of a combination of two or more methods. In defensive coding the difference is that security mechanisms are standalone software tools that work by intercepting HTTP requests and doing intermediate validation. Sometimes we might have hybrid tool that exercise both static and dynamic approach, of which a good example is AMNESIA [7]. This section provides an inside to the strengths and weaknesses of existing SQLI prevention tools. In [3] a method is proposed that uses static code analysis to detect SQL injection vulnerability and prevent attacker from exploiting such vulnerability in java web-based application. In this approach PQL was used as a syntactic model for queries library, 55 Muhammad Saidu Aliero et al. / Jurnal Teknologi (Sciences & Engineering) 77:13 (2015) 49–66 which allow users to define vulnerability patterns in a familiar Java-like syntax. Any piece of code that accepts input parameters from user and are passed to the backend database are marked tainted and tracked until it used in a sink. The advantage of this approach is that it enables detection of all potential security violations early, even without executing the application. However this approach requires source code application to carry out this function. In addition, it cannot detect unknown patterns of SQL injection attack. R-WASP tool is proposed in [4] to detect and prevent SQL injection attack. The tool intercepts dynamic queries entered by the user and breaks them into tokens of SQL keywords, operators and characters in order to track existing malicious input in the query. If all input tokens are found to be trusted then the query is considered to be safe and allowed processing by database engine. Otherwise action is performed as defined by the programmer. Using SQL keywords, operators, and characters to find the malicious input in a dynamic query is problematic in nature, as it is possible to have a valid query with delete or drop keywords DIGLOSSIA is method that prevents SQLIA by computing shadow values for the results of all string and character array operations that depend on user input [5]. In this approach programmer defines valid queries in the form of a tree-like structure to compare against dynamic queries entered by the user. When input query is sent to database the tool intercepts the query and tries to construct a tree like a dynamic query based on queries already defined by the programmer and also computes the shadow of the entered query storing it in the shadow value table indexed by the address of the memory location for the original value, performing both grammar and shadow checks using a dual parser. Using the dual parser to detect injected code is based on the idea that query strings can be parsed to either its original grammar, or the shadow grammar. If the tool cannot produce tree-like structure of query, the tool rejects the query and reports a code injection attack. Otherwise, it com