SQLIPA: An Authentication Mechanism Against SQL ...

European Journal of Scientific Research ISSN 1450-216X Vol.38 No.4 (2009), pp 604-611 © EuroJournals Publishing, Inc. 2009 http://www.eurojournals.com/ejsr.htm

SQLIPA: An Authentication Mechanism Against SQL Injection Shaukat Ali Department of Computer Science, University of Peshawar, Peshawar N.W.F.P, Pakistan E-mail: [email protected] Tel: +923469015382 Azhar Rauf Department of Computer Science, University of Peshawar, Peshawar N.W.F.P, Pakistan E-mail: [email protected] Tel: +92919216732 Huma Javed Department of Computer Science, University of Peshawar, Peshawar N.W.F.P, Pakistan E-mail: [email protected] Tel: +92919216732 Abstract Web application has been developed with very rapid progress. Web applications use database at backend for storing data and SQL for insertion and retrieval of data. There are some malicious attacks which can deceive this SQL. These attacks are called SQL injection. To stop SQL injection many techniques have been proposed but they require large code modification and/or large extra time overhead. The work of this paper proposes a technique using hash values of user name and password, to improve the authentication process. We had built a prototype, SQL Injection Protector for Authentication (SQLIPA), for the evaluation of idea.

Keywords: Database security, SQL injection, Authentication

1. Introduction In Today’s world of ubiquities computing every person remains connected to the internet. In these situations the web security is very necessary and it is a challenging part of the web applications(A. Kiezun and Ernst 2009). A number of techniques are in use for securing the web applications. The most common way is the authentication process through the username and password. One of the major problems in the authentication process is the input validation checking (Boyd and Keromytis 2004; K. Wei and Kothari 2006; R. Ezumalai 2009). There are some major threads in web application security for example SQL injection and Buffer overflow which can break the web application security (Geer 2008).

SQLIPA: An Authentication Mechanism Against SQL Injection

605

SQL injection is too much vulnerable that it can bypass many traditional security layers like Firewall, encryption, and traditional intrusion detection systems(R. Ezumalai 2009). It can also bypass the database mechanisms of authentication and authorization (A. Kamra and Guy 2008) SQL injection can not only be used for violating the security by seeing the private data of the people but also can be used for bypassing the authentication of user which is a big flaw in the web applications. Major problem in the web applications vulnerabilities is the SQL injection. It is to be considered that SQL injection is an easy attack and every developer can easily do the SQL injection which is the most worrying aspect of the SQL injection (R. Ezumalai 2009). Login page is the most complicated web application which allows users to enter into the database after authenticating him. In this page, the user provides his identity like username and password. There might be some invalid input validations which can bypass the authentication process using some mechanism like SQL injection (Palmer 2007). Normally, web applications is a three tier architecture, the Application tier at the user side, Middle tier which converts the user queries into the SQL format, and the backend database server which stores the user data as well as the user’s authentication table. Whenever a user wants to enter into the web database through application tier, the user inputs his/her authentication information from a login form as shown in figure 1. Figure 1: Simple login form

The middle tier server will convert the input values of user name and password from user entry form into the format as shown in figure 2. Figure 2: Example of simple SQL query

Query_result = "SELECT * FROM User_account WHERE username = 'Username' AND password='password'

If result of the query is true then the user is authenticated otherwise, denied. But, there are some malicious attacks which can deceive the database server by entering malicious code through SQL injection which always return true results of the authentication query. For example the hacker enters the expression in the Username field like '' ' OR 1=1 – – ' ''. So, the middle tier will convert it into SQL query format as shown in figure 3. This deceives the authentication server. Figure 3: Example of SQL query having input violation

Query_result = "SELECT * FROM User_account WHERE name = ' ' OR 1=1 – – ' ' AND password= ' Password'

606

Shaukat Ali, Azhar Rauf and Huma Javed

Analyzing the above query, the result is always true for variable Query_result. It is because malicious code has been used in the query. Here, in this query the mark ( ' ) tells the SQL parser that the user name string is finished and " OR 1=1 " statement is appended to the statement which always results in true. The (– –) is comment mark in the SQL which tells the parser that the statement is finished and the password will not be checked. So, the result of the whole query will return true for Query_result variable which authenticates the user without checking password. Many techniques have been proposed for controlling SQL injection, for example, dynamic monitoring tools (Su and Wassermann 2006; Halfond and Orso 2008; Pietraszek and Berghe 2005). Each of these techniques have some advantages and disadvantages. Major problems with these techniques are either high code modifications or it takes large extra time overhead. This paper presents a new technique for protecting database against SQL injection which uses stored procedures of DBMS for the authentication of users to the database. Here, the hash values for user name and password along with user name and password are used for authentication. These hash values for user name and password are generated automatically when the user enters into database. A user is authenticated by using user name, password and hash values for user name and password. The time overhead of the approach is too small and is 1.3 ms. The paper is structured as follows: Section 2 discuses definition and background. Section 3 describes related work. Section 4 is focused on proposed authentication technique and section 5 is about the architecture of the proposed technique. Section 6 discuses the methodology. Section 7 evaluates and show results. Finally section 8 concludes the work done.

2. Definition and Background When the malicious code is entered into the database along with legitimate SQL query such attacks are called SQL injection attacks (SQLIAs). In SQL injection the hacker changes the logic, semantic or syntax of a legitimate query by injecting some SQL keywords and/or operators into statement. SQL injection has many different forms (Halfond and Orso 2005). When malicious code is entered by a user and it is parsed as an SQL statement, such attack is termed as SQL injection. The login form as shown in the figure 1 is used to get the user name and password from the user. The user name field can take alphanumeric characters, periods, underscore and dashes character. Password field normally takes some extra values other than alphanumeric characters. It may support some special characters like %, $, | or # etc as well. The user name and password can be transformed by the application layer server in the code as shown in figure 4. The database has a table which stores all the user names, passwords in addition to the roles based on user name and password. Figure 4: Authentication code example //This example is given in PHP. //first, extract the input values from the login form $username = $_POST[' username ']; $password = $_POST[' password ']; //query DB for a user with username/password $result = mysql_query( "select * from User_account where username = '$username' AND password = '$password' "); If ($result) { // Declare authenticated user // Extract userrole } Else { // Invalid User name or password } //set a cookie for the user with their role setcookie("userrole", $role);


607

The code shown in figure 4 performs the following tasks. First, it sends a query to the database for user authentication. This query returns true if the user is authenticated, otherwise false. If user is authenticated its role is extracted from the table. If the user in not a valid user then the “else” part is executed and the user is declared as un-authenticated. The “else part” will not be executed in case of any input violations. The code shown in figure 4 shows that user name and password are vulnerable locations for SQL injection attacks. If an attacker simply enters " ' OR 1=1 – –AND " in the user name field the application layer server transforms the code into the form as shown in figure 5. Figure 5: Example of Input Violation //This example is given in PHP. //first, extract the input values from the login form $username = $_POST [' username ']; $password = $_POST [' password ']; //query DB for a user with username/password $result = mysql_query( "select * from User_account where username = '$username' AND password = '$password' "); // the above code will become like following $result = mysql_query( "select * from users where username = ' ' OR 1=1 – – AND password = 'Password' "); If ($result) { // Declare authenticated user // Extract userrole } Else { // Invalid User name or password } //set a cookie for the user with their role setcookie("userrole", $role);

The single quotation mark ( ' ) in user name input values tells the SQL parser that the sequence of the character, of the user name column has been closed. The fragment "OR 1=1" is interpreted as always true. The hyphens symbol (– –) is comments operator in SQL which indicates the end of SQL command. In case of execution of the code given in Figure 5 the query will always return true value. The variable “$result” will always be true and the user is accepted as a legitimate user. Normally, the code returns the role of the first user in the User_account table in case of the above mentioned input violation.

3. Related Work Various techniques have been proposed for controlling SQL injection attacks, for example, AMNESIA (Analysis and Monitoring for Neutralizing SQL-Injection attacks) (Halfond and Orso 2005). In AMNESIA , the authors are using runtime checking of the query and declare it valid or malicious. AMNESIA checks query in different steps. In the first step it identifies the “hotspot”. Hotspots are application code which issues SQL query to database. Second, it forms a model for legitimate query in the form of NDFA (Non-Deterministic Finite Automata). Finally, as a request comes it checks the query with NDFA and declares it legitimate or malicious.

608


MeiJunjin (MeiJunjin) is using an approach for the detection of SQL injection vulnerabilities. The above mentioned author has used static, dynamic and automatic testing method for the detection of SQL injection vulnerabilities. The approach traces user queries to vulnerable location. Buehrer et al(G.T. Buehrer and Sivilotti 2005) is using a parse tree, data structure, for the validation of query. In this technique the authors have used a parse tree as a model and every query entering to database is checked against that tree. After checking with parse tree the query is either declared valid or malicious. Specification based approach has been proposed by Kemalis et al(Kemalis and Tzouramanis 2008). In this technique they specify a model for SQL statements. The model is based on a set of rules. The SQL statements are intercepted to the model. After lexical analysis and syntactical verification of the query either declares it valid or invalid. It keeps the log file of the whole process which will facilitate the administrator. William et al(Halfond and Orso 2005) proposed a mechanism in which they prevent SQL injection using static analysis. In this mechanism, they create NDFA (Non-Deterministic Finite Automata) of hotspot and performs depth first search for traversing of hotspots. They find out suspicious statement using these NDFAs. It generates an alarm when suspicious activity is found. An anomaly based approach has been introduced by Cava et al (M. Cova and Vigna 2007) for the detection of volition of web application. They use “Swaddler” for the analysis of the internal state of web applications. They call Swaddler for finding the relationship of critical points of the application. After finding the internal state and relationship between critical points, the Swaddler is able to identify attacks that attempt to bring violation of the intended workflow of a web application. Ezumalai et al(R. Ezumalai 2009) used a signature based approach for the protection of SQL injection. In this approach they used three modules to detect security issues. A monitoring module which takes input from web application and sent to analysis module. An analysis module which finds out the hotspots from application, it uses Hirschberg algorithm(Hirschberg 1975). Hirschberg algorithm is a string comparison algorithm which works on divide and conquer rule. It stores all the keywords in the specifications module.

4. Proposed Technique This paper proposes a new technique, SQL Injection Protector for Authentication (SQLIPA), for preventing database against SQL injection. In the propoed approach there is a need for two extra columns in User_account table. The first one is for the hash values of user name and other one for the hash values of password. The hash values are calculated for user name and password when a user account is created for the first time and stores it in the User_account table. Whenever user wants to login to database his/her identity is checked using user name and password and its hash values. These hash values are calculated at runtime using store procedure when user wants to login into the database. Normally, whenever user enters his/her user name and password in the user name and password fields, the query at the back end server will be created as shown in figure 2. The query given in figure 2 can easily be deceived using SQL injection because this query is static and created every time during the authentication process. For example, if some one enters user name as " 'OR 1 = 1 – – " and password as "Password" then the query of figure 2 will become as shown in figure 3. The query shown in figure 3 always results in true, as tautology is used in the code. Thus, the authentication process can easily be bypassed through SQL injection. In the proposed technique first the hash values of user name and password are calculated at runtime and checked with stored hash values in the User_account table. During the authentication the query shown in figure 3 will change in to the query shown in figure 6.


609

Figure 6: Example of query using hash values

Query_result = SELECT * FROM User_account WHERE Username_Hash_value = "Username_Hash_value" AND Password_Hash_value = "Password_Hash_value" AND Username = ' ' OR 1=1 – – AND password = ' Password '

In case or the query shown in figure 6 if a hacker enters the SQL injection query still he/she cannot bypass the authentication process. The advantage of the proposed technique is that the hackers do not know about the hash values of user name and password. So, it is not possible for the hacker to bypass the authentication process through the general SQL injection techniques. The SQL injection attacks can only be done on codes which are entered through user entry form but the hash values are calculated at run time at backend before creating SELECT query to the underling database therefore the hacker cannot calculate the hash values as it dynamic at runtime.

5. Architecture Architecture of the proposed technique consists of three components. These are User Login Interface, SQL Injection Protector for Authentication (SQLIPA) and User_account table as shown in figure 7. Figure 7: architecture of SQL Injection Protector for Authentication (SQLIPA)

Here, User Login Interface is just the user entry form for user name and password. User_account is the table which stores user accounts data. Main component of the architecture is SQL Injection Protector for Authentication (SQLIPA). It is the component which generates the hash values of user name and password for the first time during the creation of user account.and every time when an existing user wants to login into database. Subcomponents of the SQL Injection Protector for Authentication (SQLIPA) are “User Name Hash Value” and “Password Hash value”. User Name Hash Value generates hash of user name and Password Hash value generates hash value for password.

610


6. Methodology A prototype named SQL Injection Protector for Authentication (SQLIPA) has been developed for evaluating the proposed technique. The system have been implemented using Microsoft SQL sever 2005 as a DBMS. Two store procedures with name Create_user_account and User_authentication have been used. Create_user_account store procedure is used when a new user account is created for the first time. It calculates the hash values of user name and password and stores into the User_account table. The User_authentication store procedure is used for checking user authentication using user name, password and their hash values. It executes every time when a user wants to login into database using user name and password. The User_authentication store procedure generates hash values every time on the fly when user logins into database.

7. Testing and Results The proposed technique has been test on a table having different number of user records. For testing proposes a dummy data table has been taken. The table was populated with records of 200, 400, 600, 800, 1000 and 1200 and was tested whose results are shown in figure 8. Figure 8: Analysis results of the SQLIPA

Here, if some one looks at the graph as shown in figure 8, it is linear. Thus, it shows that the SQIPA takes equal amount of time for any amount of data in User_account table. The time overhead of the proposed solution is that it takes 1.3 ms of extra time overhead to protect database against SQL injection which is almost negligible fraction of time and has no significance compared to securing the authentication process.

8. Conclusion The proposed approach presents a new technique SQLIPA to secure the authentication process of the database. SQLIPA uses user name, password and their hash values for authentication process. The SQLIPA is tested on sample data of different records in User_account table. It takes very little time overhead of 1.3 ms for authentication process.


611

References [1] [2]

[3]

[4]

[5] [6] [7]

[8] [9] [10]

[11] [12]

[13] [14] [15] [16]

[17]

A. Kamra , E. Bertino. and Guy ( 2008). Mechanisms for Database Intrusion Detection and Response. Data security & privacy. Vancouver, Canada, ACM: pp. 31-36. A. Kiezun, P. J. Guo., K.Jayaraman and M. D. Ernst ( 2009). Automatic Creation of SQL Injection and Cross-Site Scripting Attacks. International Conference on Software Engineering. Vancouver, Canada, IEEE: pp. 199-209. Boyd, S. W. and A. D. Keromytis (2004). SQLrand: Preventing SQL Injection Attacks. 2nd Applied Cryptography and Network Security (ACNS) Conference Yellow Mountain, Chine: pp. 292-302 G.T. Buehrer, B. W. Weide. and P. A. G. Sivilotti ( 2005). Using parse tree validation to prevent SQL injection attacks. Proceedings of the 5th international workshop on Software engineering and middleware. Lisbon, Portugal, ACM: pp. 106-113 Geer, D. (2008). "Malicious Bots Threaten Network Security." IEEE 38: pp.18-20. Halfond, W. G. J. and A. Orso (2005). AMNESIA: analysis and monitoring for NEutralizing SQL-injection attacks. . ASE’05. Long Beach, California, USA. Halfond, W. G. J. and A. Orso (2005). Combining Static Analysis and Runtime Monitoring to Counter SQL-Injection Attacks. Workshop on Dynamic Analysis (WODA 2005). St. Louis, MO, USA, ACM: pp. 1 - 7. Halfond, W. G. J. and A. Orso (2008). "WASP: Protecting Web Applications Using Positive Tainting and Syntax-Aware Evaluation." IEEE 34(01): pp. 65-81. Hirschberg, D. S. (1975). "A linear space algorithm for computing maximal common subsequences." A.C.M 18(06): pp. 341-343. K. Wei, M. Muthuprasanna. and S. Kothari (2006). Preventing SQL Injection Attacks in Stored Procedures. Australian Software Engineering Conference (ASWEC’06) Australia, IEEE: pp. 191 - 198 Kemalis, K. and T. Tzouramanis (2008). SQL-IDS: a specification-based approach for SQLinjection detection. SAC’08. Fortaleza, Ceará, Brazil, ACM: pp. 2153 2158. M. Cova, D. Balzarotti., V. Felmetsger, and G. Vigna (2007). Swaddler: An Approach for the Anomaly-based Detection of State Violations in Web Applications. Recent Advances in Intrusion Detection (RAID). Gold Coast, Australia, pp. 63 - 86. MeiJunjin (2009). An approach for SQL injection vulnerability detection. Sixth International Conference on Information Technology: New Generations: pp. 1411-1414. Palmer, S. (2007). Web application vulnerabilities detect, exploit, prevent, Syngress. Pietraszek, T. and C. V. Berghe ( 2005). Defending against Injection Attacks through ContextSensitive String Evaluation. Recent Advances in Intrusion Detection (RAID2005). R. Ezumalai, G. A. (2009). Combinatorial Approach for Preventing SQL Injection Attacks. 2009 IEEE International Advance Computing Conference (IACC 2009). Patiala, India: pp. 1212-1217. Su, Z. and G. Wassermann (2006). The Essence of Command Injection Attacks in Web Applications. POPL. Charleston, South Carolina, USA, ACM: pp. 372 - 382