A Classification of SQL Injection Attacks and …

1 A Classification of SQL Injection Attacksand CountermeasuresWilliam Halfond, Jeremy Viegas, and Alessandro OrsoCollege of ComputingGeorgia Institute of Injection Attacks pose a serious security threat to Web appli-cations: they allow attackers to obtain unrestricted access to thedatabases underlying the applications and to the potentially sensi-tive information these databases contain. Although researchers andpractitioners have proposed various methods to address the SQLinjection problem, current approaches either fail to address the fullscope of the problem or have limitations that prevent their use andadoption. Many researchers and practitioners are familiar with onlya subset of the wide range of techniques available to attackers whoare trying to take advantage of SQL Injection vulnerabilities. Asa consequence, many solutions proposed in the literature addressonly some of the issues related to SQL Injection .

2 To address thisproblem, we present an extensive review of the different types ofSQL Injection Attacks known to date. For each type of attack, weprovide descriptions and examples of how Attacks of that type couldbe performed. We also present and analyze existing detection andprevention techniques against SQL Injection Attacks . For each tech-nique, we discuss its strengths and weaknesses in addressing theentire range of SQL Injection INTRODUCTIONSQL Injection vulnerabilities have been described as one of themost serious threats for Web applications [3, 11]. Web applica-tions that are vulnerable to SQL Injection may allow an attacker togain complete access to their underlying databases. Because thesedatabases often contain sensitive consumer or user information, theresulting security violations can include identity theft, loss of con-fidential information, and fraud.

3 In some cases, attackers can evenuse an SQL Injection vulnerability to take control of and corrupt thesystem that hosts the Web application. Web applications that arevulnerable to SQL Injection Attacks (SQLIAs) are widespread astudy by Gartner Group on over 300 Internet Web sites has shownthat most of them could be vulnerable to SQLIAs. In fact, SQLIA shave successfully targeted high-profile victims such as Travelocity, , and Guess Injection refers to a class of code- Injection Attacks in whichdata provided by the user is included in an SQL query in such away that part of the user s input is treated as SQL code. By lever-Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page.

4 To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a 2006 these vulnerabilities, an attacker can submit SQL commandsdirectly to the database. These Attacks are a serious threat to anyWeb application that receives input from users and incorporates itinto SQL queries to an underlying database. Most Web applicationsused on the Internet or within enterprise systems work this way andcould therefore be vulnerable to SQL cause of SQL Injection vulnerabilities is relatively simpleand well understood: insufficient validation of user input. To ad-dress this problem, developers have proposed a range of codingguidelines ( , [18]) that promote defensive coding practices, suchas encoding user input and validation. A rigorous and systematicapplication of these techniques is an effective solution for prevent-ing SQL Injection vulnerabilities.

5 However, in practice, the appli-cation of such techniques is human-based and, thus, prone to , fixing legacy code-bases that might contain SQL in-jection vulnerabilities can be an extremely labor-intensive recently there has been a great deal of attention tothe problem of SQL Injection vulnerabilities, many proposed solu-tions fail to address the full scope of the problem. There are manytypes of SQLIAs and countless variations on these basic types. Re-searchers and practitioners are often unaware of the myriad of dif-ferent techniques that can be used to perform SQLIAs. Therefore,most of the solutions proposed detect or prevent only a subset ofthe possible SQLIAs. To address this problem, we present a com-prehensive survey of SQL Injection Attacks known to date. To com-pile the survey, we used information gathered from various sources,such as papers, Web sites, mailing lists, and experts in the area.

6 Foreach attack type considered, we give a characterization of the at-tack, illustrate its effect, and provide examples of how that type ofattack could be performed. This set of attack types is then usedto evaluate state of the art detection and prevention techniques andcompare their strengths and weaknesses. The results of this com-parison show the effectiveness of these rest of this paper is organized as follows: Section 2 providesbackground information on SQLIAs and related concepts. Sec-tion 4 defines and presents the different attack types. Sections 5and 6 review and evaluate current techniques against SQLIAs. Fi-nally, we provide summary and conclusions in Section ON SQLIASI ntuitively, anSQL Injection Attack (SQLIA)occurs when an at-tacker changes the intended effect of an SQL query by insertingnew SQL keywords or operators into the query.

7 This informal defi-nition is intended to include all of the variants of SQLIAs reportedin literature and presented in this paper. Interested readers can referto [35] for a more formal definition of SQLIAs. In the rest of thissection, we define two important characteristics of SQLIAs that weuse for describing Attacks : Injection mechanism and attack Injection MechanismsMalicious SQL statements can be introduced into a vulnerableapplication using many different input mechanisms. In this section,we explain the most common through user input: In this case, attackers inject SQLcommands by providing suitably crafted user input. A Web appli-cation can read user input in several ways based on the environmentin which the application is deployed. In most SQLIAs that targetWeb applications, user input typically comes from form submis-sions that are sent to the Web application via HTTPGETorPOST requests [14].

8 Web applications are generally able to access theuser input contained in these requests as they would access anyother variable in the through cookies: Cookies are files that contain stateinformation generated by Web applications and stored on the clientmachine. When a client returns to a Web application, cookies canbe used to restore the client s state information. Since the clienthas control over the storage of the cookie, a malicious client couldtamper with the cookie s contents. If a Web application uses thecookie s contents to build SQL queries, an attacker could easilysubmit an attack by embedding it in the cookie [8]. Injection through server variables: Server variables are a col-lection of variables that contain HTTP, network headers, and envi-ronmental variables. Web applications use these server variables ina variety of ways, such as logging usage statistics and identifyingbrowsing trends.

9 If these variables are logged to a database withoutsanitization, this could create an SQL Injection vulnerability [30].Because attackers can forge the values that are placed in HTTP andnetwork headers, they can exploit this vulnerability by placing anSQLIA directly into the headers. When the query to log the servervariable is issued to the database, the attack in the forged header isthen Injection : In second-order injections, attackers seedmalicious inputs into a system or database to indirectly trigger anSQLIA when that input is used at a later time. The objective ofthis kind of attack differs significantly from a regular ( , first-order) Injection attack. Second-order injections are not trying tocause the attack to occur when the malicious input initially reachesthe database. Instead, attackers rely on knowledge of where theinput will be subsequently used and craft their attack so that it oc-curs during that usage.

10 To clarify, we present a classic exampleof a second order Injection attack (taken from [1]). In the exam-ple, a user registers on a website using a seeded user name, suchas admin -- . The application properly escapes the singlequote in the input before storing it in the database, preventing itspotentially malicious effect. At this point, the user modifies his orher password, an operation that typically involves (1) checking thatthe user knows the current password and (2) changing the pass-word if the check is successful. To do this, the Web applicationmight construct an SQL command as follows:queryString="UPDATE users SET password= " + newPassword +" WHERE userName= " + userName + " AND password= " +oldPassword + " "newPasswordandoldPasswordare the new and old pass-words, respectively, anduserNameis the name of the user cur-rently logged-in ( , admin -- ).