International Journal of Scientific & Engineering Research Volume 3, Issue 3, March -2012 1
ISSN 2229-5518
Veera Venkateswaramma P
Abstract- The databases that underlie web applications were facing issues like, unauthorized access, so many security threats in recent years. Many software systems have evolved to include a Web-based component that makes them available to the public via the Internet and can expose them to a variety of Web-based attacks. One of these attacks is SQL injection, which can give attackers unrestricted access to the databases and has become frequent and serious threat to them. Successful injection attack can give attackers access to and even control of the databases that underlay Web applications, which may contain sensitive or confidential information. This paper presents a new highly automated approach for protecting Web applications against SQL injection that has both conceptual and practical advantages over most existing techniques. From a practical standpoint, our technique is precise and efficient, has minimal deployment requirements, and incurs a very low performance overhead in most cases. We have implemented this technique (Injection preventer), which we used to perform an empirical evaluation on a wide range of Web applications that we subjected to a large and varied set of attacks and legitimate accesses.
Keywords- SQL Injection, Security, Syntax- aware, Positive tainting, Character level tainting.
The security is an important aspect to the organizations which are developing web applications. It is a great challenge to the organizations to protect their valuable data against intruders, corruptions and malicious accesses [2].Actually the developers in the organizations are concentrating mostly on applications usability and functionality, rather than enforcing security standards. In general, SQL injection vulnerabilities are caused by inadequate input validation within an application [2].Input validation is a major security aspect if an attacker finds that an application makes attempt has been made to increase the efficiency of the above unfounded assumptions about the type, length, format, or techniques by a combinatorial approach for protecting web range of input data. The attacker can then supply a malicious application against SQL Injection attacks input that compromises an application. The external interfaces exposed by an application become the only source of attack besides the other interfaces network and host level entry points are secure. Since this injection attack is a major threat in web applications development that underlies databases which may breach the database security mechanism, Such as availability and issues like authorization, integration, and authentication. A SQL injection attack consists of
insertion or "injection" of a SQL query via the input data from the client to the application. A
successful SQL injection exploit can read sensitive data from the database, modify database data
(Insert/ Update/Delete), execute administration operations on
the database (such as shutdown the DBMS), recover the
content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL
injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. These attacks may bypass the security mechanisms like intrusion detection systems, firewall and cryptography. Attackers take advantage of these vulnerabilities by submitting input strings that contain specially-encoded database commands to the application. When the application builds a query using these strings and submits commands are executed by the database and the attack succeeds.
The most worsening part of these injection attacks is they are very easy to perform, even though developers of the applications have an idea about these attacks. The main concept is based on the idea is a malicious user counterfeits the data that a web application sends to the database focusing at modification of sql query which gets executed by DBMS software. The input validation issues can allow the hackers to gain access to the database systems. All most all technologies that use database system were facing these vulnerabilities due to these attacks [3]. So many techniques have been developed to counter these attacks, but they are lack of practicality and efficacy. Initially a technique was proposed as a solution to counter these injection attacks based on defense coding. This practice was not efficient due to these problems. They are 1) solutions based on defensive coding will address only a subset of possible attacks. 2) Legacy systems address another problem because of expense and complexity of making the existing code so that is compliant with defensive coding. 3) It is a great difficult to develop code based on defense code practices.
In this paper an attempt has been made to overcome the above difficulties and to improve the efficiency of above
IJSER © 2012
International Journal of Scientific & Engineering Research Volume 3, Issue 3, March -2012 2
ISSN 2229-5518
techniques by a conceptual approach for protecting web applications against sql injection attacks. It contains four sections namely section A. conceptual approach, section B. contains types of injection vulnerabilities, section C contains Mitigation. The rest of the paper section D. present‟s signature based approach and auditing of the database.
A. CONCEPTUAL APPROACH
Intuitively, our approach works by identifying “trusted” strings in an application and allowing only these trusted strings to be used to create certain parts of an SQL query, such as keywords or operators. The general mechanism that we use to implement this approach is based on dynamic tainting [4] which marks and tracks certain data in a program at runtime. The kind of dynamic tainting we use gives our approach several important advantages over techniques based on different mechanisms [5]. It involves positive Tainting, character level tainting, syntax-aware evaluation.
i. Positive Tainting: Positive tainting [5] differs from traditional tainting (hereafter, negative tainting) because it is based on the identification, marking, and tracking of trusted, rather than un-trusted data. This conceptual difference has significant implications for the effectiveness of our approach, in that it helps address problems caused by incompleteness in the identification of relevant data to be marked. In the case of negative tainting, incompleteness leads to trusting data that should not be trusted and, ultimately, to false negatives. Incompleteness may thus leave the application vulnerable to attacks and can be very difficult to detect, even after attacks actually occur, because they may go completely unnoticed. With positive tainting, incompleteness may lead to false positives, but it would never result in an SQLIA escaping detection. Moreover, as explained in the following, the false positives generated by our approach, if any, are likely to be detected and easily eliminated early during prerelease testing. Positive tainting uses a white-list, rather than a black-list, policy and follows the general principle of fail-safe defaults, as outlined by Saltzer and Schroeder [6]. In case of incompleteness, positive tainting fails in a way that maintains the security of the system. In the context of preventing SQLIAs, the conceptual advantages of positive tainting are especially significant. The way in which Web applications create SQL commands makes the identification of all un- trusted data especially problematic and, most importantly, the identification of most trusted data relatively straightforward. In general, it is difficult to guarantee that all potentially harmful data sources have been considered and even a single unidentified source could leave the application vulnerable to attacks. The situation is different for positive tainting because identifying trusted data in a Web application is often straightforward and always less error prone. In fact, in most cases, strings hard-coded in the application by developers
represent the complete set of trusted data for a Web application. To account for these cases, our technique provides developers with a mechanism for specifying sources of external data that should be trusted. The data sources can be of various types such as files, network connections, and server variables. Our approach uses this information to mark data that comes from these additional sources as trusted .In a typical scenario, we expect developers to specify most of the trusted sources before testing and deployment. In other words, false positives are likely to occur only for totally untested parts of applications. Therefore, even when developers fail to completely identify additional sources of trusted data beforehand, we expect these sources to be identified during normal testing and the set of trusted data to quickly converge to the complete set.
IJSER © 2012
International Journal of Scientific & Engineering Research Volume 3, Issue 3, March -2012 3
ISSN 2229-5518
Shows the sequence of tokens for the resulting query, together with the trust markings. Recall that “– –” is the SQL comment operator, so everything after this is identified by the parser as a literal. In this case, the Meta Checker would find that the last two tokens,‟ and , contain untrusted characters. It would therefore identify the query as an SQLIA.
This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into an SQL statement. These results in the potential manipulation of the statements performed on the database by the end-user of the application. The following line of code illustrates this vulnerability Statement = "SELECT * FROM users WHERE name = '" + username + "';" This SQL code is designed to pull up the records of the specified username from its table of users. However, if the "username" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the "username" variable as „or '1'='1 Or using comments to even block the rest of the query (there are three types of SQL comments): ' or '1'='1' --‟ „or '1'='1' ({„ ' or '1'='1' /*‟ Renders one of the following SQL statements by the parent language: SELECT * FROM users WHERE name = '' OR '1'='1'; SELECT * FROM users WHERE name = '' OR '1'='1' -- '; If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of '1'='1' is always true.
The following value of "username" in the statement below would cause the deletion of the "users" table as well as the selection of all data from the "userinfo" table (in essence revealing the information of every user), using an API that allows multiple statements: a‟; DROP TABLE users; SELECT * FROM userinfo WHERE ‟t‟ =„t‟ This input renders the final SQL statement as follows: SELECT * FROM users WHERE name = 'a‟; DROP TABLE users; SELECT * FROM userinfo WHERE ‟t‟ =„t‟; While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP's mysql_query(); function do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn't stop them from modifying queries.
is clear from this statement that the author intended a_variable to be a number correlating to the "id" field. However, if it is in fact a string then the end-user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to 1; DROP TABLE users Will drop (delete) the "users" table from the database, since the SQL would be rendered as follows: SELECT * FROM userinfo WHERE id=1; DROP TABLE users;
IJSER © 2012
International Journal of Scientific & Engineering Research Volume 3, Issue 3, March -2012 4
ISSN 2229-5518
ORM library in effect will generate parameterized SQL
statements from object-oriented code [9].
,mysql_real_escape_string ($Username),
mysql_real_escape_string ($Password)); mysql_query ($query); This function, i.e. mysql_real_escape_string (), calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r,
\, ', “and \x1a. This function must always (with few
exceptions) be used to make data safe before sending a query to MySQL. [10].
+pwd + "'";} 8. ResultSet tempSet = st.execute (queryString);
}……….. This step identifies the hotspot (6, 7, and 8) and it divides the hotspot in to tokens and it sends it to query validation phase.
modules contains all predefined keyword which are stored in database.
In this approach it provides a table which contains keywords present in the horizontal and vertical line and compares the incoming tokens with predefined values by applying this algorithm for identification. In the below sql statement there is a hotspot identified by analysis module which sends it to table to find and prevent attacks. Sql stmt = select * from clients where user = „“&ausername&”‟ and pwd
= „“&apwd&”; By applying the above algorithm the statement is divided into tokens and validates each token with predefined tokens using divide and conquer methodology [1]. The injection code is: .Select * from clients where user =
„username‟ and pwd = „anything or „1‟ = „1‟; The analysis module finds an injection takes place after (anything) this token to prevent injection attack.
This paper presents a systematic approach to prevent injection attacks and protect the web application against those attacks. Moreover from a conceptual standpoint; the approach is based on the idea of positive tainting and on the concept of
IJSER © 2012
International Journal of Scientific & Engineering Research Volume 3, Issue 3, March -2012 5
ISSN 2229-5518
syntax-aware evaluation. From a practical standpoint, our technique is precise and efficient, has minimal deployment requirements, and incurs a very low performance overhead in most cases. By using auditing to analyze the transactions to prevent malicious access and on the other hand Signature based approach is used to reduce the time taken to detect and prevent the attacks. Moreover empirical evaluation is performed on wide range of web applications and WASP which automates the task very easily.
[1]. Christina Yip Chung, "DEMIDS: A Misuse Detection System for Database Systems", Integrity and internal control information systems, Pages: 159 - 178, ACM, 2008.
[2]. David Geer (2008), "Malicious Bots Threaten Network
Security".
[3]. G.T. Buehrer, B.W. Weide, and P.A.G. Sivilotti, (2005) “Using Parse Tree Validation to Prevent SQL Injection Attacks,” Proc. Fifth Int‟l Workshop Software Eng. and Middleware, pp. 106-113.
[4]. J. Clause, W. Li, and A. Orso (2007) “Dytan: A Generic
Dynamic Taint Analysis Framework,” Proc. Int‟l
Symp.Software Testing and Analysis, pp. 196-206.
[5]. Marco Cova, Davide Balzarotti, Viktoria Felmetsger, and Giovanni vigna (2007), " Swaddler: An approach for the anamoly based character distribution models in the detection of SQL Injection attacks", Recent Advances in Intrusion Detection System, Pages 63-86.
[6]. Nguyen-tuong, S. Guarnieri, D. Greene, J.Shirley, and D. Evans (2005),” Automatically hardening web applications using Precise Tainting", In Twentieth IFIP Intl, Information security conference.
[7]. R.Ezumalai, G.Aghila (2009) “A Combinatorial Approach for Preventing SQL Injection Attacks” IEEE International Advance Computing Conference 2009.
[8]. S.W. Boyd and A.D. Keromytis (June 2004), “SQLrand:
Preventing SQL Injection Attacks,” Proc. Second Int‟l Conf.
Applied Cryptography and Network Security, pp. 292-302.
[9]. SruthiBandhakavi (ACM, 2007), "CANDID: Preventing
SQL Injection Attacks using Dynamic Candidate Evaluations".
[10]. W.G. J. Halfond and A. Orso (2005), "Combining Static Analysis and Runtime monitoring to counter SQL Injection attacks", 3rd International workshop on Dynamic Analysis, St. Louis, Missouri.
IJSER © 2012