Using Positive Tainting and Syntax-Aware Evaluation

to Counter SQL Injection Attacks

William G.J. Halfond, Alessandro Orso, and Panagiotis Manolios

College of Computing – Georgia Institute of Technology
{whalfond, orso, manolios}@cc.gatech.edu

ABSTRACT commands are executed by the database, and the attack succeeds.
SQL injection attacks pose a serious threat to the security of Web Although this general mechanism is well understood, straightfor-
applications because they can give attackers unrestricted access to ward solutions based on defensive coding practices have been less
databases that contain sensitive information. In this paper, we pro- than successful for several reasons. First, it is difficult to imple-
pose a new, highly automated approach for protecting existing Web ment and enforce a rigorous defensive coding discipline. Second,
applications against SQL injection. Our approach has both concep- many solutions based on defensive coding address only a subset
tual and practical advantages over most existing techniques. From of the possible attacks. Finally, defensive coding is problematic
the conceptual standpoint, the approach is based on the novel idea in the case of legacy software because of the cost and complex-
of positive tainting and the concept of syntax-aware evaluation. ity of retrofitting existing code. Researchers have proposed a wide
From the practical standpoint, our technique is at the same time pre- range of alternative techniques to address SQLIAs, but many of
cise and efficient and has minimal deployment requirements. The these solutions have limitations that affect their effectiveness and
paper also describes WASP, a tool that implements our technique, practicality.
and a set of studies performed to evaluate our approach. In the stud- In this paper we propose a new, highly automated approach for
ies, we used our tool to protect several Web applications and then dynamic detection and prevention of SQLIAs. Intuitively, our ap-
subjected them to a large and varied set of attacks and legitimate proach works by identifying “trusted” strings in an application and
accesses. The evaluation was a complete success: WASP success- allowing only these trusted strings to be used to create certain parts
fully and efficiently stopped all of the attacks without generating of an SQL query, such as keywords or operators. The general mech-
any false positives. anism that we use to implement this approach is based on dynamic
tainting, which marks and tracks certain data in a program at run-
Categories and Subject Descriptors: D.2.0 [Software Engineer- time.
ing]: General—Protection mechanisms; The kind of dynamic tainting we use gives our approach several
important advantages over techniques based on different mecha-
General Terms: Security nisms. Many techniques rely on complex static analyses in order to
Keywords: SQL injection, dynamic tainting, runtime monitoring find potential vulnerabilities in code (e.g., [9, 15, 26]). These kinds
of conservative static analyses can generate high rates of false posi-
tives or may have scalability issues when applied to large, complex
1. INTRODUCTION applications. Our approach does not rely on complex static anal-
SQL injection attacks (SQLIAs) are one of the major security yses and is very efficient and precise. Other techniques involve
threats for Web applications [5]. Successful SQLIAs can give at- extensive human effort (e.g., [4, 18, 24]). They require developers
tackers access to and even control of the databases that underly to manually rewrite parts of their applications, build queries using
Web applications, which may contain sensitive or confidential in- special libraries, or mark all points in the code at which malicious
formation. Despite the potential severity of SQLIAs, many Web input could be introduced. In contrast, our approach is highly auto-
applications remain vulnerable to such attacks. mated and in most cases requires minimal or no developer interven-
In general, SQL injection vulnerabilities are caused by inade- tion. Lastly, several proposed techniques require the deployment of
quate input validation within an application. Attackers take ad- extensive infrastructure or involve complex configurations (e.g., [2,
vantage of these vulnerabilities by submitting input strings that 23, 25]). Our approach does not require additional infrastructure
contain specially-encoded database commands to the application. and can be deployed automatically.
When the application builds a query using these strings and sub- Compared to other existing techniques based on dynamic taint-
mits the query to its underlying database, the attacker’s embedded ing (e.g., [8, 20, 21]), our approach makes several conceptual and
practical improvements that take advantage of the specific char-
acteristics of SQLIAs. The first conceptual advantage of our ap-
proach is the use of positive tainting. Positive tainting identifies
Permission to make digital or hard copies of all or part of this work for and tracks trusted data, whereas traditional (“negative”) tainting fo-
personal or classroom use is granted without fee provided that copies are cuses on untrusted data. In the context of SQLIAs, there are sev-
not made or distributed for profit or commercial advantage and that copies eral reasons why positive tainting is more effective than negative
bear this notice and the full citation on the first page. To copy otherwise, to tainting. First, in Web applications, trusted data sources can be
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
more easily and accurately identified than untrusted data sources;
SIGSOFT’06/FSE-14, November 5–11, 2006, Portland, Oregon, USA. therefore, the use of positive tainting leads to increased automation.
Copyright 2006 ACM 1-59593-468-5/06/0011 ...$5.00.
 1. String login = getParameter("login");
Second, the two approaches differ significantly in how they are af- 2. String pin = getParameter("pin");
fected by incompleteness. With negative tainting, failure to identify 3. Statement stmt = connection.createStatement();
the complete set of untrusted data sources would result in false neg- 4. String query = "SELECT acct FROM users WHERE login=’";
5. query += login + "’ AND pin=" + pin;
atives, that is, successful undetected attacks. With positive tainting, 6. ResultSet result = stmt.executeQuery(query);
conversely, missing trusted data sources would result in false pos- 7. if (result != null)
itives, which are undesirable, but whose presence can be detected 8. displayAccount(result); // Show account
immediately and easily corrected. In fact, we expect that most false 9. else
10. sendAuthFailed(); // Authentication failed
positives would be detected during pre-release testing. The second
conceptual advantage of our approach is the use of flexible syntax- Figure 1: Excerpt of a Java servlet implementation.
aware evaluation, which gives developers a mechanism to regulate
the usage of string data based not only on its source, but also on its malicious commands into a vulnerable application [10]. In this sec-
syntactical role in a query string. In this way, developers can use tion we introduce an example application that contains an SQL in-
a wide range of external input sources to build queries, while pro- jection vulnerability and show how an attacker can leverage the vul-
tecting the application from possible attacks introduced via these nerability to perform an SQLIA. Note that the example represents
sources. an extremely simple kind of attack, and we present it for illustra-
The practical advantages of our approach are that it imposes a tive purposes only. Interested readers may refer to References [1]
low overhead on the application and has minimal deployment re- and [10] for further examples of the different types of SQLIAs.
quirements. Efficiency is achieved by using a specialized library, The code excerpt in Figure 1 represents the implementation of lo-
called MetaStrings, that accurately and efficiently assigns and tracks gin functionality that we can find in a typical Web application. This
trust markings at runtime. The only deployment requirements for type of login function would commonly be part of a Java servlet, a
our approach are that the Web application must be instrumented type of Java application that runs on a Web application server, and
and deployed with our MetaStrings library, which is done auto- whose execution is triggered by the submission of a URL from a
matically. The approach does not require any customized runtime user of the Web application. The servlet in the example uses the
system or additional infrastructure. input parameters login and pin to dynamically build an SQL
In this paper, we also present the results of an extensive empiri- query or command.1 The login and pin are checked against the
cal evaluation of the effectiveness and efficiency of our technique. credentials stored in the database. If they match, the correspond-
To perform this evaluation, we implemented our approach in a tool ing user’s account information is returned. Otherwise, a null set is
called WASP (Web Application SQL-injection Preventer) and eval- returned by the database and the authentication fails. The servlet
uated WASP on a set of seven Web applications of various types and then uses the response from the database to generate HTML pages
sizes. For each application, we protected it with WASP, targeted it that are sent back to the user’s browser by the the Web server.
with a large set of attacks and legitimate accesses, and assessed the Given the servlet code, if a user submits login and pin as
ability of our technique to detect and prevent attacks without stop- “doe” and “123,” the application dynamically builds the query:
ping legitimate accesses. The results of the evaluation are promis-
ing; our technique was able to stop all of the attacks without gener- SELECT acct FROM users WHERE login=’doe’ AND pin=123
ating false positives for any of the legitimate accesses. Moreover, If login and pin match the corresponding entry in the database,
our technique proved to be efficient, imposing only a low overhead doe’s account information is returned and then displayed by func-
on the Web applications. tion displayAccount(). If there is no match in the database,
The main contributions of this work are: function sendAuthFailed() displays an appropriate error mes-
sage. An application that uses this servlet is vulnerable to SQLIAs.
• A new, automated technique for preventing SQLIAs based on For example, if an attacker enters “admin’ --” as the user name
the novel concept of positive tainting and on flexible syntax- and any value as the pin (e.g., “0”), the resulting query is:
aware evaluation.
SELECT acct FROM users WHERE login=’admin’ -- ’ AND pin=0
• A mechanism to perform efficient dynamic tainting of Java
strings that precisely propagates trust markings while strings In SQL, “--” is the comment operator, and everything after it is
are manipulated at runtime. ignored. Therefore, when performing this query, the database sim-
• A tool that implements our SQLIA prevention technique for ply searches for an entry where login is equal to admin and
Java-based Web applications and has minimal deployment returns that database record. After the “successful” login, the func-
requirements. tion displayAccount() would therefore reveal the admin’s
• An empirical evaluation of the technique that shows its ef- account information to the attacker.
fectiveness and efficiency.

The rest of this paper is organized as follows. In Section 2, we 3. OUR APPROACH

introduce SQLIAs with an example that is used throughout the pa- Our approach is based on dynamic tainting, which has been widely
per. Sections 3 and 4 discuss the approach and its implementation. used to address security problems related to input validation. Tra-
Section 5 presents the results of our evaluation. We discuss related ditional dynamic tainting approaches mark certain untrusted data
work in Section 6 and conclude in Section 7. (typically, user input) as tainted, track the flow of tainted data at
runtime, and prevent this data from being used in potentially harm-
ful ways. Our approach makes several conceptual and practical im-
2. SQL INJECTION ATTACKS provements over traditional dynamic-tainting approaches by tak-
Intuitively, an SQL Injection Attack (SQLIA) occurs when an ing advantage of the characteristics of SQLIAs. First, unlike any
attacker changes the developer’s intended structure of an SQL com- existing dynamic tainting techniques that we are aware of, our ap-
mand by inserting new SQL keywords or operators. (Su and Wasser-
mann provide a formal definition of SQLIAs in [24].) SQLIAs 1
For simplicity, in the rest of this paper we use the terms query and
leverage a wide range of mechanisms and input channels to inject command interchangeably.
proach is based on the novel concept of positive tainting—the iden- veloped in this way, which includes the applications used in our
tification and marking of trusted instead of untrusted data. Sec- empirical evaluation, our approach accurately and automatically
ond, our approach performs accurate taint propagation by pre- identifies all SQLIAs and generates no false positives; our basic ap-
cisely tracking trust markings at the character level. Third, it per- proach, as explained in the following sections, automatically marks
forms syntax-aware evaluation of query strings before they are sent as trusted all hard-coded strings in the code and then ensures that
to the database and blocks all queries whose non-literal parts (i.e., all SQL keywords and operators are built using trusted data.
SQL keywords and operators) contain one or more characters with- In some cases, this basic approach is not enough because de-
out trust markings. Finally, our approach has minimal deployment velopers can also use external query fragments—partial SQL com-
requirements, which makes it both practical and portable. The fol- mands coming from external input sources—to build queries. Be-
lowing sections discuss the key features of our approach in detail. cause these string fragments are not hard-coded in the application,
they would not be part of the initial set of trusted data identified
3.1 Positive Tainting by our approach, and the approach would generate false-positives
Positive tainting differs from traditional tainting (hereafter, neg- when the string fragments are used in a query. To account for
ative tainting) because it is based on the identification, marking, these cases, our technique provides developers with a mechanism
and tracking of trusted, rather than untrusted, data. This concep- to specify additional sources of external data that should be trusted.
tual difference has significant implications for the effectiveness of The data sources can be of various types, such as files, network con-
our approach, in that it helps address problems caused by incom- nections, and server variables. Our approach uses this information
pleteness in the identification of relevant data to be marked. Incom- to mark data coming from these additional sources as trusted.
pleteness, which is one of the major challenges when implementing In a typical scenario, we expect developers to specify most of the
a security technique based on dynamic tainting, has very different trusted sources beforehand. However, some of these sources might
consequences in negative and positive tainting. In the case of neg- be overlooked until after a false positive is reported, in which case
ative tainting, incompleteness leads to trusting data that should not developers would add the omitted data source to the list of trusted
be trusted and, ultimately, to false negatives. Incompleteness may sources. In this process, the set of trusted data sources grows mono-
thus leave the application vulnerable to attacks and can be very tonically and eventually converges to a complete set that produces
difficult to detect even after attacks occur. With positive tainting, no false positives. It is important to note that false positives that
incompleteness may lead to false positives, but never results in an occur after deployment would be due to the use of external data
SQLIA escaping detection. Moreover, as explained below, the false sources that have never been used during in-house testing. In other
positives generated by our approach are likely to be detected and words, false positives are likely to occur only for totally untested
easily eliminated early, during pre-release testing. Positive taint- parts of the application. Therefore, even when developers fail to
ing follows the general principle of fail-safe defaults as outlined by completely identify and mark additional sources of trusted input
Saltzer and Schroeder in [22]: in case of incompleteness, positive beforehand, we expect these sources to be identified during nor-
tainting fails in a way that maintains the security of the system. mal testing of the application, and the set of trusted data to quickly
In the context of preventing SQLIAs, these conceptual advan- converge to the complete set.
tages of positive tainting are especially significant. The way in
which Web applications create SQL commands makes the iden- 3.2 Accurate Taint Propagation
tification of all untrusted data especially problematic and, most im- Taint propagation consists of tracking taint markings associated
portantly, the identification of all trusted data relatively straightfor- with the data while the data is used and manipulated at runtime.
ward. Web applications are deployed in many different configura- When tainting is used for security-related applications, it is es-
tions and interface with a wide range of external systems. There- pecially important for the propagation to be accurate. Inaccurate
fore, there are often many potential external untrusted sources of propagation can undermine the effectiveness of a technique by as-
input to be considered for these applications, and enumerating all sociating incorrect markings to data, which would cause the data
of them is inherently difficult and error-prone. For example, de- to be mishandled. In our approach, we provide a mechanism to ac-
velopers initially assumed that only direct user input needed to be curately mark and propagate taint information by (1) tracking taint
marked as tainted. Subsequent exploits demonstrated that addi- markings at a low level of granularity and (2) precisely accounting
tional input sources, such as browser cookies and uploaded files, for the effect of functions that operate on the tainted data.
also needed to be considered. However, accounting for these ad-
ditional input sources did not completely solve the problem either.
Character-level tainting. We track taint information at the
character level rather than at the string level. We do this because,
Attackers soon realized the possibility of leveraging local server
for building SQL queries, strings are constantly broken into sub-
variables and the database itself as injection sources [1]. In general,
strings, manipulated, and combined. By associating taint informa-
it is difficult to guarantee that all potentially harmful data sources
tion to single characters, our approach can precisely model the ef-
have been considered, and even a single unidentified source could
fect of these string operations.
leave the application vulnerable to attacks.
The situation is different for positive tainting because identifying Accounting for string manipulations. To accurately main-
trusted data in a Web application is often straightforward, and al- tain character-level taint information, we must identify all relevant
ways less error prone. In fact, in most cases, strings hard-coded in string operations and account for their effect on the taint markings
the application by developers represent the complete set of trusted (i.e., we must enforce complete mediation of all string operations).
data for a Web application.2 The reason for this is that it is com- Our approach achieves this goal by taking advantage of the encap-
mon practice for developers to build SQL commands by combining sulation offered by object-oriented languages, and in particular by
hard-coded strings that contain SQL keywords or operators with Java, in which all string manipulations are performed using a small
user-provided numeric or string literals. For Web applications de- set of classes and methods. Our approach extends all such classes
2 and methods by adding functionality to update taint markings based
We assume that developers are trustworthy. An attack encoded by on the methods’ semantics.
a developer would not be an SQLIA but a form of back-door attack,
which is not the problem addressed in this paper.
 We discuss the language specific details of our implementation B UGZILLA (http://www.bugzilla.org) is an example
of the taint markings and their propagation in Section 4. of a Web application for which developers might wish to spec-
ify a custom trust marking and policy. In B UGZILLA, parts of
3.3 Syntax-Aware Evaluation queries used within the application are retrieved from a database
when needed. Of particular concern to developers, in this scenario,
Besides ensuring that taint markings are correctly created and
is the potential for second-order injection attacks [1] (i.e., attacks
maintained during execution, our approach must be able to use the
that inject into a database malicious strings that result in an SQLIA
taint markings to distinguish legitimate from malicious queries. An
only when they are later retrieved and used to build SQL queries).
approach that simply forbids the use of untrusted data in SQL com-
In the case of B UGZILLA, the only sub-queries that should origi-
mands is not a viable solution because it would flag any query that
nate from the database are specific predicates that form a query’s
contains user input as an SQLIA, leading to many false positives.
WHERE clause. Using our technique, developers could first create
To address this shortcoming, researchers have introduced the con-
a custom trust marking and associate it with the database’s data
cept of declassification, which permits the use of tainted input as
source. Then, they could define a custom trust policy that speci-
long as it has been processed by a sanitizing function. (A sanitiz-
fies that data with such custom trust marking are legal only if they
ing function is typically a filter that performs operations such as
match a specific pattern, such as the following:
regular expression matching or sub-string replacement.) The idea
of declassification is based on the assumption that sanitizing func- (id|severity)=’\w+’ ((AND|OR) (id|severity)=’\w+’)*
tions are able to eliminate or neutralize harmful parts of the input When applied to sub-queries originating from the database, this
and make the data safe. However, in practice, there is no guaran- policy would allow them to be used only to build conditional clauses
tee that the checks performed by a sanitizing function are adequate. that involve the id or severity fields and whose parts are con-
Tainting approaches based on declassification could therefore gen- nected using the AND or OR keywords.
erate false negatives if they mark as trusted supposedly-sanitized
data that is in fact still harmful. Moreover, these approaches may 3.4 Minimal Deployment Requirements
also generate false positives in cases where unsanitized, but per- Most existing approaches based on dynamic tainting require the
fectly legal input is used within a query. use of customized runtime systems and/or impose a considerable
Syntax-aware evaluation does not depend on any (potentially un- overhead on the protected applications (see Section 6). On the con-
safe) assumptions about the effectiveness of sanitizing functions trary, our approach has minimal deployment requirements and is
used by developers. It also allows for the use of untrusted input efficient, which makes it practical for usage in real settings. The
data in an SQL query as long as the use of such data does not cause use of our technique does not necessitate a customized runtime sys-
an SQLIA. The key feature of syntax-aware evaluation is that it tem. It requires only minor, localized instrumentation of the appli-
considers the context in which trusted and untrusted data is used cation to (1) enable the usage of our modified string library and (2)
to make sure that all parts of a query other than string or numeric insert the calls that perform syntax-aware evaluation of a query be-
literals (e.g., SQL keywords and operators) consist only of trusted fore the query is sent to the database. The protected application is
characters. As long as untrusted data is confined to literals, we are then deployed as any normal Web application, except that the de-
guaranteed that no SQLIA can be performed. Conversely, if this ployment must include our string library. Both instrumentation and
property is not satisfied (e.g., if an SQL operator contains charac- deployment are fully automated. We discuss deployment require-
ters not marked as trusted), we can assume that the operator has ments and overhead of the approach in greater detail in Sections 4.5
been injected by an attacker and block the query. and 5.3.
Our technique performs syntax-aware evaluation of a query string
immediately before the string is sent to the database to be executed.
To evaluate the query string, the technique first uses an SQL parser 4. IMPLEMENTATION
to break the string into a sequence of tokens that correspond to To evaluate our approach, we developed a prototype tool called
SQL keywords, operators, and literals. The technique then iter- WASP (Web Application SQL Injection Preventer) that is written
ates through the tokens and checks whether tokens (i.e., substrings) in Java and implements our technique for Java-based Web appli-
other than literals contain only trusted data. If all of the tokens cations. We chose to target Java because it is a commonly-used
pass this check, the query is considered safe and allowed to exe- language for developing Web applications. Moreover, we already
cute. As discussed in Section 3.1, this approach can also handle have a significant amount of analysis and experimental infrastruc-
cases where developers use external query fragments to build SQL ture for Java applications. We expect our approach to be applicable
commands. In these cases, developers would specify which exter- to other languages as well.
nal data sources must be trusted, and our technique would mark and Figure 2 shows the high-level architecture of WASP. As the fig-
treat data coming from these sources accordingly. ure shows, WASP consists of a library (MetaStrings) and two core
This default approach, which (1) considers only two kinds of modules (STRING INITIALIZER AND INSTRUMENTER and STRING
data (trusted and untrusted) and (2) allows only trusted data to form CHECKER ). The MetaStrings library provides functionality for as-
SQL keywords and operators, is adequate for most Web applica- signing trust markings to strings and precisely propagating the mark-
tions. For example, it can handle applications where parts of a ings at runtime. Module STRING INITIALIZER AND INSTRUMENTER
query are stored in external files or database records that were cre- instruments Web applications to enable the use of the MetaStrings
ated by the developers. Nevertheless, to provide greater flexibility library and add calls to the STRING CHECKER module. Module
and support a wide range of development practices, our technique STRING CHECKER performs syntax-aware evaluation of query strings
also allows developers to associate custom trust markings to differ- right before the strings are sent to the database.
ent data sources and provide custom trust policies that specify the In the next sections, we discuss WASP’s modules in more detail.
legal ways in which data with certain trust markings can be used. We use the sample code introduced in Section 2 to provide illustra-
Trust policies are functions that take as input a sequence of SQL to- tive examples of various implementation aspects.
kens and perform some type of check based on the trust markings
associated with the tokens.
 Developer
Additional Trust
Policies

WASP
String
Additional Checker
Trusted Sources MetaStrings
and Markings library

SQLIA

String Initializer Protected Legitimate Query

Web
and Web Database
Application
Instrumenter Application

Data
URL HTML

Users
Figure 2: High-level overview of the approach and tool.
4.1 The MetaStrings Library classes also provide methods for setting and querying the metadata
MetaStrings is our library of classes that mimic and extend the associated with a string’s characters.
behavior of Java’s standard string classes (i.e., Character, Stri- The use of MetaStrings has the following benefits: (1) it allows
ng, StringBuilder, and StringBuffer).3 For each string for associating trust markings at the granularity level of single char-
class C, MetaStrings provides a “meta” version of the class, MetaC, acters; (2) it accurately maintains and propagates trust markings;
that has the same functionality as C, but allows for associating (3) it is defined completely at the application level and therefore
metadata with each character in a string and tracking the metadata does not require a customized runtime system; (4) its usage requires
as the string is manipulated at runtime. only minimal and automatically performed changes to the applica-
The MetaStrings library takes advantage of the object-oriented tion’s bytecode; and (5) it imposes a low execution overhead on the
features of the Java language to provide complete mediation of Web application (See Section 5.3).
string operations that could affect string values and their associ- The main limitations of the current implementation of the MetaS-
ated trust markings. Encapsulation and information hiding guaran- trings library are related to the handling of primitive types, native
tee that the internal representation of a string class is accessed only methods, and reflection. MetaStrings cannot currently assign trust
through the class’s interface. Polymorphism and dynamic binding markings to primitive types, so it cannot mark char values. Be-
let us add functionality to a string class by (1) creating a subclass cause we do not instrument native methods, if a string class is
that overrides all methods of the original class and (2) replacing in- passed as an argument to a native method, the trust marking associ-
stantiations of the original class with instantiations of the subclass. ated with the string might not be correct after the call. In the case of
As an example, Figure 3 shows an intuitive view of the MetaS- hard-coded strings created through reflection (by invoking a string
trings class that corresponds to Java’s String class. As the figure constructor by name), our instrumenter for MetaStrings would not
shows, MetaString extends class String, has the same inter- recognize the constructors and would not change these instantia-
nal representation, and provides the same methods. MetaString tions to instantiations of the corresponding meta classes. However,
also contains additional data structures for storing metadata and as- the MetaStrings library can handle most other uses of reflection,
sociating the metadata with characters in the string. Each method of such as invocation of string methods by name.
class MetaString overrides the corresponding method in Stri- In practice, these limitations are of limited relevance because
ng, providing the same functionality as the original method, but they represent programming practices that are not normally used
also updating the metadata based on the method’s semantics. For to build SQL commands (e.g., representing strings using primitive
example, a call to method substring(2,4) on an object str of char values). Moreover, during instrumentation of a Web applica-
class MetaString would return a new MetaString that con- tion, we identify and report these potentially problematic situations
tains the second and third characters of str and the correspond- to the developers.
ing metadata. In addition to the overridden methods, MetaStrings
4.2 Initialization of Trusted Strings
3 To implement positive tainting, WASP must be able to identify
For simplicity, hereafter we use the term string to refer to all
string-related classes and objects in Java. and mark trusted strings. There are three categories of strings that
 String method of a newly-created StringBuilder object. WASP must
replace these string objects with their corresponding MetaStrings
[ f ][ o ][ o ]...[ r ] objects so that they can maintain and propagate the trust markings
of the strings on which they operate. To do this, WASP scans the
bytecode for instructions that create new instances of the string
method1 classes used to perform string manipulation and modifies each such
... instruction so that it creates an instance of the corresponding MetaS-
method n trings class instead. In this case, WASP does not associate any trust
markings with the newly-created MetaStrings objects. These ob-
jects are not trusted per se, and they become marked only if the
actual values assigned to them during execution are marked.
Figure 5 shows the instrumentation added by WASP for implicitly-
created strings. The Java source code corresponds to line 5 in our
MetaString example servlet. The StringBuilder object at offset 28 in the
original bytecode is added by the Java compiler when translating
[ f ][ o ][ o ]...[ r ] (inherited) the string concatenation operator (“+”). WASP replaces the instanti-
ation at offset 28 with the instantiation of a MetaStringBuilder
method 1
class and then changes the subsequent invocation of the constructor
... at offset 37 so that it matches the newly instantiated class. Because
method n MetaStringBuilder extends StringBuilder, the subse-
... quent calls to the append method invoke the correct method in the
setMetadata
MetaStringBuilder class.
Metadata getMetadata
markAll Strings from External Sources. To use query fragments com-
Update Policies
... ing from external (trusted) sources, developers must list these sources
in a configuration file that WASP processes before instrumenting the
Figure 3: Intuitive view of a MetaStrings library class. application. The specified sources can be of different types, such
as files (specified by name), network connections (specified by host
WASP must consider: hard-coded strings, strings implicitly created
and port), and databases (specified by database name, table, field,
by Java, and strings originating from external sources. In the fol- or combination thereof). For each source, developers can either
lowing sections, we explain how strings from each category are specify a custom trust marking or use the default trust marking (the
identified and marked. same used for hard-coded strings). WASP uses the information in
the configuration file to instrument the external trusted sources ac-
Hard-Coded Strings. The identification of hard-coded strings cording to their type.
in an application’s bytecode is a fairly straightforward process. In To illustrate this process, we describe the instrumentation that
Java, hard-coded strings are represented using String objects that WASP performs for trusted strings coming from a file. In the con-
are created automatically by the Java Virtual Machine (JVM) when figuration file, the developer specifies the name of the file (e.g.,
string literals are loaded onto the stack. (The JVM is a stack-based foo.txt) as a trusted source of strings. Based on this informa-
interpreter.) Therefore, to identify hard-coded strings, WASP sim- tion, WASP scans the bytecode for all instantiations of new file ob-
ply scans the bytecode and identifies all load instructions whose jects (i.e., File, FileInputStream, FileReader) and adds
operand is a string constant. WASP then instruments the code by instrumentation that checks the name of the file being accessed. At
adding, after each of these load instructions, code that creates an runtime, if the name of the file matches the name(s) specified by
instance of a MetaString class using the hard-coded string as the developer (foo.txt in this case), the file object is added to an
an initialization parameter. Finally, because hard-coded strings are internal list of currently trusted file objects. WASP also instruments
completely trusted, WASP adds to the code a call to the method of all calls to methods of file-stream objects that return strings, such as
the newly created MetaString object that marks all characters BufferedReader’s readLine method. At runtime, the added
as trusted. At runtime, polymorphism and dynamic binding allow code checks to see whether the object on which the method is called
this instance of the MetaString object to be used in any place where is in the list of currently trusted file objects. If so, it marks the gen-
the original String object would have been used. erated strings with the trust marking specified by the developer for
Figure 4 shows an example of this bytecode transformation. The the corresponding source.
Java code at the top of the figure corresponds to line 4 of our servlet We use a similar strategy to mark network connections. In this
example (see Figure 1), which creates one of the hard-coded strings case, instead of matching file names at runtime, we match host-
in the servlet. Underneath, we show the original bytecode (left), names and ports. The interaction with databases is more compli-
and the modified bytecode (right). The modified bytecode contains cated and requires WASP not only to match the initiating connec-
additional instructions that (1) load a new MetaString object on tion, but also to trace tables and fields through instantiations of the
the stack, (2) call the MetaString constructor using the previous Statement and ResultSet objects created when querying the
string as a parameter, and (3) call the method markAll, which database.
assigns the given trust marking to all characters in the string.
Instrumentation Optimization. Our current instrumentation
Implicitly-Created Strings. In Java programs, the creation of approach is conservative and may generate unneeded instrumenta-
some string objects is implicitly added to the bytecode by the com- tion. We could limit the amount of instrumentation inserted in the
piler. For example, Java compilers typically translate the string code by leveraging static information about the program. For exam-
concatenation operator (“+”) into a sequence of calls to the append ple, data-flow analysis could identify strings that are not involved
 Source Code: 4. String query = "SELECT acct FROM users WHERE login=’";
Original Bytecode Modified Bytecode
24a. new MetaString
24b. dup
24c. ldc "SELECT acct FROM users WHERE login=’"
24. ldc "SELECT acct FROM users WHERE login=’"
24e. invokespecial MetaString.<init>:(LString)V
24d. iconst_1
24e. invokevirtual MetaString.markAll:(I)V

Figure 4: Instrumentation for hard-coded strings.

Source Code: 5. query += login + "’ AND pin=" + pin;

Original Bytecode Modified Bytecode
28. new MetaStringBuilder
28. new StringBuilder 31. dup
31. dup 32. aload 4
32. aload 4 34. invokestatic String.valueOf:(LObject)LString;
34. invokestatic String.valueOf:(Object)LString; 37. invokespecial MetaStringBuilder.<init>:(LString;)V
37. invokespecial StringBuilder.<init>:(LString;)V 40. aload_1
40. aload_1 41. invokevirtual StringBuilder.append:(LString;)LStringBuilder;
41. invokevirtual StringBuilder. 44a. new MetaString
append:(LString;)LStringBuilder; 44b. dup
44. ldc "’ AND pin=" 44c. ldc "’ AND pin="
46. invokevirtual StringBuilder. 44e. invokespecial MetaString.<init>:(LString)V
append:(LString;)LStringBuilder; 44d. iconst_1
49. aload_2 44e. invokevirtual MetaString.markAll:(I)V
50. invokevirtual StringBuilder. 46. invokevirtual StringBuilder.append:(LString;)LStringBuilder;
append:(LString;)LStringBuilder; 49. aload_2
53. invokevirtual StringBuilder.toString:()LString; 50. invokevirtual StringBuilder.append:(LString;)LStringBuilder;
53. invokevirtual StringBuilder.toString:()LString;

Figure 5: Instrumentation for implicitly-created strings.

with the construction of query strings and thus do not need to be cific methods and classes in the JDBC library (http://java.
instrumented. Another example involves cases where static analy- sun.com/products/jdbc/). Therefore, these points can be
sis could determine that the filename associated with a file object identified through a simple matching of method signatures. Af-
is never one of the developer-specified trusted filenames, that ob- ter identifying the database interaction points, WASP inserts a call
ject would not need to be instrumented. Analogous optimizations to the syntax-aware evaluation function, MetaChecker, imme-
could be implemented for other external sources. We did not in- diately before each interaction point. MetaChecker takes the
corporate any of these optimizations in the current tool because we MetaStrings object that contains the query about to be executed as
were mostly interested in having an initial prototype to assess our a parameter.
technique. However, we are planning to implement them in future When invoked, MetaChecker processes the SQL string about
work to further reduce runtime overhead. to be sent to the database as discussed in Section 3.3. First, it tok-
enizes the string using an SQL parser. Ideally, WASP would use a
4.3 Handling False Positives database parser that recognizes the exact same dialect of SQL that
As discussed in Section 3, sources of trusted data that are not is used by the database. This would guarantee that WASP interprets
specified by the developers beforehand would cause WASP to gen- the query in the same way as the database and would prevent attacks
erate false positives. To assist the developers in identifying data based on alternate encodings [1]—attacks that obfuscate keywords
sources that they initially overlooked, WASP provides a special mode and operators to elude signature-based checks. Our current imple-
of operation, called “learning mode”, that would typically be used mentation includes parsers for SQL-92 (ANSI) and PostgreSQL.
during in-house testing. When in learning mode, WASP adds an After tokenizing the query string, MetaChecker enforces the de-
additional unique taint marking to each string in the application. fault trust policy by iterating through the tokens that correspond to
Each marking consists of an ID that maps to the fully qualified class keywords and operators and examining their trust markings. If any
name, method signature, and bytecode offset of the instruction that of these tokens contains characters that are not marked as trusted,
instantiated the corresponding string. the query is blocked and reported.
If WASP detects an SQLIA while in learning mode, it uses the If developers specified additional trust policies, MetaChecker
markings associated with the untrusted SQL keywords and opera- invokes the corresponding checking function(s) to ensure that the
tors in the query to report the instantiation point of the correspond- query complies with them. In our current implementation, trust
ing string(s). If the SQLIA is actually a false positive, knowing the policies are developer-defined functions that take the list of SQL
position in the code of the offending string(s) would help develop- tokens as input, perform some type of check on them based on
ers correct omissions in the set of trusted inputs. their trust markings, and return a true or false value depending
on the outcome of the check. Trust policies can implement func-
4.4 Syntax-Aware Evaluation tionality that ranges from simple pattern matching to sophisticated
The STRING CHECKER module performs syntax-aware evalua- checks that use externally-supplied contextual information. If all
tion of query strings and is invoked right before the strings are sent custom trust policies return a positive outcome, WASP allows the
to the database. To add calls to the STRING CHECKER module, query to be executed on the database. Otherwise, it classifies the
WASP first identifies all of the database interaction points: points query as an SQLIA, blocks it, and reports it.
in the application where query strings are issued to an underlying
database. In Java, all calls to the database are performed via spe-
 SELECT acct FROM users WHERE login = ’ doe ’ AND pin = 123 Table 1: Subject programs for the empirical study.
Subject LOC DBIs Servlets Params
Figure 6: Example query 1 after parsing by runtime monitor. Checkers 5,421 5 18 (61) 44 (44)
Office Talk 4,543 40 7 (64) 13 (14)
Employee Directory 5,658 23 7 (10) 25 (34)
SELECT acct FROM users WHERE login = ’ admin ’ -- ’ AND pin=0
Bookstore 16,959 71 8 (28) 36 (42)
Events 7,242 31 7 (13) 36 (46)
Figure 7: Example query 2 after parsing by runtime monitor. Classifieds 10,949 34 6 (14) 18 (26)
Portal 16,453 67 3 (28) 39 (46)

We illustrate how the default policy for syntax-aware evaluation

works using our example servlet and the legitimate and malicious 5. EVALUATION
query examples from Section 2. For the servlet there are no external
The goal of our empirical evaluation is to assess the effective-
sources of strings or additional trust policies, so WASP only marks
ness and efficiency of the approach presented in this paper when
the hard-coded strings as trusted, and only the default trust policy
applied to a testbed of Web applications. In the evaluation, we used
is applied. Figure 6 shows the sequence of tokens in the legitimate
our implementation of WASP and investigated the following three
query as they would be parsed by MetaChecker. In the figure,
research questions:
SQL keywords and operators are surrounded by boxes. The figure
RQ1: What percentage of attacks can WASP detect and prevent
also shows the trust markings associated with the strings, where
that would otherwise go undetected and reach the database?
an underlined character is a character with full trust markings. Be-
RQ2: What percentage of legitimate accesses does WASP iden-
cause the default trust policy is that all keyword and operator tokens
tify as SQLIAs and prevent from executing on the database?
must have originated from trusted strings, MetaChecker simply
RQ3: How much runtime overhead does WASP impose?
checks whether all these tokens are comprised of trusted charac-
The first two questions deal with the effectiveness of the technique:
ters. The query in Figure 6 conforms to the trust policy and is thus
RQ1 addresses the false negative rate of the technique, and RQ2
allowed to execute on the database.
addresses the false positive rate. RQ3 deals with the efficiency of
Consider the malicious query, where the attacker submits “admin’
the proposed technique. The following sections discuss our exper-
−−” as the login and “0” as the pin. Figure 7 shows the sequence
iment setup, protocol, and results.
of tokens for the resulting query together with the trust markings.
Recall that −− is the SQL comment operator, so everything af- 5.1 Experiment Setup
ter this is identified by the parser as a literal. In this case, the
Our experiments are based on an evaluation framework that we
MetaChecker would find that the last two tokens, ’ and −− developed and has been used by us and other researchers in previ-
contain untrusted characters. It would therefore classify the query ous work [9, 24]. The framework provides a testbed that consists
as an SQLIA and prevent it from executing. of several Web applications, a logging infrastructure, and a large
set of test inputs containing both legitimate accesses and SQLIAs.
4.5 Deployment Requirements In the next two sections we summarize the relevant details of the
Using WASP to protect a Web application requires the devel- framework.
oper to run an instrumented version of the application. There are
two general implementation strategies that we can follow for the 5.1.1 Subjects
instrumentation: off-line or on-line. Off-line instrumentation in- Our set of subjects consists of seven Web applications that accept
struments the application statically and deploys the instrumented user input via Web forms and use it to build queries to an underlying
version of the application. On-line instrumentation deploys an un- database. Five of the seven applications are commercial applica-
modified application and instruments the code at load time (i.e., tions that we obtained from GotoCode (http://www.gotocode.
when classes are loaded by the JVM). This latter option allows com/): Employee Directory, Bookstore, Events, Classifieds, and
for a great deal of flexibility and can be implemented by leverag- Portal. The other two, Checkers and OfficeTalk, are applications
ing the new instrumentation package introduced in Java 5 (http: developed by students that have been used in previous related stud-
//java.sun.com/j2se/1.5.0/). ies [7].
Unfortunately, the current implementation of the Java 5 instru- For each subject, Table 1 provides the size in terms of lines of
mentation package is still incomplete and does not yet provide some code (LOC) and the number of database interaction points (DBIs).
key features needed by WASP. In particular, it does not allow for To be able to perform our studies in an automated fashion and
clearing the final flag in the string library classes, which pre- collect a larger number of data points, we considered only those
vents the MetaStrings library from extending them. Because of this servlets that can be accessed directly, without complex interactions
limitation, for now we have chosen to rely on off-line instrumenta- with the application. Therefore, we did not include in the evalua-
tion and to splice into the Java library a version of the string classes tion servlets that require the presence of specific session data (i.e.,
in which the final flag has been cleared. cookies containing specific information) to be accessed. Column
Overall, the deployment requirements for our approach are fairly Servlets reports, for each application, the number of servlets con-
lightweight. The modification of the Java library is performed only sidered and, in parentheses, the total number of servlets. Column
once, in a fully automated way, and takes just a few seconds. No Params reports the number of injectable parameters in the acces-
modification of the Java Virtual Machine is required. The instru- sible servlets, with the total number of parameters in parentheses.
mentation of a Web application is also performed automatically. Non-injectable parameters are state parameters whose purpose is to
Given the original application, WASP creates a deployment archive maintain state, and which are not used to build queries.
that contains the instrumented application, the MetaStrings library,
and the string checker module. At this point, the archive can be 5.1.2 Test Input Generation
deployed like any other Web application. WASP can therefore be For each application in the testbed, there are two sets of inputs:
easily and transparently incorporated into an existing build process. LEGIT, which consists of legitimate inputs for the application, and
ATTACK, which consists of SQLIAs. The inputs were generated
independently by a Master’s level student with experience in devel- Table 2: Results for effectiveness in SQLIAs prevention (RQ1).
oping commercial penetration testing tools for Web applications. Successful Attacks
Test inputs were not generated for non-accessible servlets and for Subject Total # Original WASP Protected
state parameters. Attacks Web Apps Web Apps
To create the ATTACK set, the student first built a set of po- Checkers 4,431 922 0
tential attack strings by surveying different sources: exploits devel- Office Talk 5,888 499 0
oped by professional penetration-testing teams to take advantage of Empl. Dir. 6,398 2,066 0
SQL-injection vulnerabilities; online vulnerability reports, such as Bookstore 6,154 1,999 0
US-CERT (http://www.us-cert.gov/) and CERT/CC Ad- Events 6,207 2,141 0
visories (http://www.cert.org/advisories/); and infor- Classifieds 5,968 1,973 0
mation extracted from several security-related mailing lists. The Portal 6,403 3,016 0
resulting set of attack strings contained 30 unique attacks that had
been used against applications similar to the ones in the testbed.
All types of attacks reported in the literature [10] were represented Table 3: Results for false positives (RQ2).
in this set except for multi-phase attacks such as overly-descriptive Subject # Legitimate Accesses False Positives
error messages and second-order injections. Since multi-phase at- Checkers 1,359 0
tacks require human intervention and interpretation, we omitted
Office Talk 424 0
them to keep our testbed fully automated. The student then gen-
Empl. Dir. 658 0
erated a complete set of inputs for each servlet’s injectable parame-
Bookstore 607 0
ters using values from the set of initial attack strings and legitimate
Events 900 0
values. The resulting ATTACK set contained a broad range of po-
tential SQLIAs. Classifieds 574 0
The LEGIT set was created in a similar fashion. However, in- Portal 1,080 0
stead of using attack strings to generate sets of parameters, the
student used legitimate values. To create “interesting” legitimate
values, we asked the student to create inputs that would stress and running GNU/Linux 2.4. The server was a dual-processor Pentium
possibly break naı̈ve SQLIA detection techniques (e.g., techniques D, 3.0Ghz, with 2GB of memory, running GNU/Linux 2.6.
based on simple identification of keywords or special characters in Table 4 shows the results of this study. For each subject, the
the input). The result was a set of legitimate inputs that contained table reports the number of inputs in the LEGIT set (# Inputs); the
SQL keywords, operators, and troublesome characters, such as sin- average time per database access (Avg Access Time); the average
gle quotes and comment operators. time overhead per access (Avg Overhead); and the average time
overhead as a percentage (% Overhead). In the table, all absolute
5.2 Experiment Protocol times are expressed in milliseconds.
To address the first two research questions, we ran the ATTACK
and LEGIT input sets against the testbed applications and assessed 5.3 Discussion of Results
WASP ’s effectiveness in stopping attacks without blocking legiti- Overall, the results of our studies indicate that WASP is an ef-
mate accesses. For RQ1, we ran all of the inputs in the ATTACK fective technique for preventing SQLIAs. In our evaluation, WASP
set and tracked the result of each attack. The results for RQ1 are was able to correctly identify all SQLIAs without generating any
summarized in Table 2. The second column reports the total num- false positives. In total, WASP stopped 12,616 viable SQLIAs and
ber of attacks in the LEGIT set for each application. The next two correctly allowed 5,602 legitimate accesses to the applications.
columns report the number of attacks that were successful on the In most cases, the runtime average imposed by WASP was very
original web applications and on the web applications protected low. For the seven applications, the average overhead was 5ms
by WASP. (Many of the applications performed input validation of (6%). For most Web applications, this cost is low enough that it
some sort and were able to block a subset of the attacks.) For RQ2, would be dominated by the cost of the network and database ac-
we ran all of the inputs in the LEGIT set and checked how many cesses. One application, Portal, incurred an overhead considerably
of these legitimate accesses WASP allowed to execute. The results higher than the other applications (but still negligible in absolute
for this second study are summarized in Table 3. The table shows terms). We determined that the higher overhead was due to the fact
the number of legitimate accesses WASP allowed to execute (# Le- that Portal generates a very large number of string-based lookup
gitimate Accesses) and the number of accesses blocked by WASP tables. Although these strings are not used to build queries, WASP
(False Positives). associates trust markings to them and propagates these markings at
To address RQ3, we computed the overhead imposed by WASP runtime. The optimizations discussed in Section 4.2 would elimi-
on the subjects. To do this, we measured the times required to nate this issue and reduce the overhead considerably.
run all of the inputs in the LEGIT set against instrumented and The main threat to the external validity of our results is that the
uninstrumented versions of each application and compared these set of applications and attacks considered in the studies may not be
two times. To avoid problems of imprecision in the timing mea- representative of real world applications and attacks. However, all
surements, we measured the time required to run the entire LEGIT but two of the considered applications are commercial applications,
set and then divided it by the number of test inputs to get a per- and all have been used in other related studies. Also, to generate
access average time. Also, to account for possible external fac- our set of attacks, we employed the services of a Master’s level
tors beyond our control, such as network traffic, we repeated these student who had experience with SQLIAs, penetration testing, and
measurements 100 times for each application and averaged the re- Web scanners, but was not familiar with our technique. Finally, the
sults. The study was performed on two machines, a client and a attack strings used by the student as a basis for the generation of
server. The client was a Pentium 4, 2.4Ghz, with 1GB memory, the attacks were based on real-world SQLIAs.
 ators contain this token before sending the query to the database.
Table 4: Results for overhead measurements (RQ3). Because the SQL keywords and operators injected by an attacker
Subject # Inputs Avg Access Avg % Overhead
Time (ms) Overhead (ms) would not contain this token, they would be easily recognized as
Checkers 1,359 122 5 5% attacks. The drawbacks of this approach are that the secret token
Office Talk 424 56 1 2% could be guessed, so making the approach ineffective, and that the
Empl. Dir. 658 63 3 5% approach requires the deployment of a special proxy server.
Bookstore 607 70 4 6% Model-based approaches against SQLIAs include AMNESIA [9],
Events 900 70 1 1% SQL-Check [24], and SQLGuard [3]. AMNESIA, previously de-
Classifieds 574 70 3 5% veloped by two of the authors, combines static analysis and runtime
Portal 1,080 83 16 19%
monitoring to detect SQLIAs. The approach uses static analysis to
build models of the different types of queries an application can
generate and dynamic analysis to intercept and check the query
6. RELATED WORK strings generated at runtime against the model. Non-conforming
queries are identified as SQLIAs. Problems with this approach are
The use of dynamic tainting to prevent SQLIAs has been in-
that it is dependent on the precision and efficiency of its underlying
vestigated by several researchers. The two approaches most sim-
static analysis, which may not scale to large applications. Our new
ilar to ours are those by Nguyen-Tuong and colleagues [20] and
technique takes a purely dynamic approach to preventing SQLIAs,
Pietraszek and Berghe [21]. Similar to them, we track taint infor-
thereby eliminating scalability and precision problems. In [24], Su
mation at the character level and use a syntax-aware evaluation to
and Wassermann present a formal definition of SQLIAs and pro-
examine tainted input. However, our approach differs from theirs in
pose a sound and complete (under certain assumptions) algorithm
several important aspects. First, our approach is based on the novel
that can identify all SQLIAs by using an augmented grammar and
concept of positive tainting, which is an inherently safer way of
by distinguishing untrusted inputs from the rest of the strings by
identifying trusted data (see Section 3.1). Second, we improve on
means of a marking mechanism. The main weakness of this ap-
the idea of syntax-aware evaluation by (1) using a database parser
proach is that it requires the manual intervention of the developer to
to interpret the query string before it is executed, thereby ensuring
identify and annotate untrusted sources of input, which introduces
that our approach can handle attacks based on alternate encodings,
incompleteness problems and may lead to false negatives. Our use
and (2) providing a flexible mechanism that allows different trust
of positive tainting eliminates this problem while providing similar
policies to be associated with different input sources. Finally, a
guarantees in terms of effectiveness. SQLGuard [3] is an approach
practical advantage of our approach is that it has more lightweight
similar to SQLCheck. The main difference is that SQLGuard builds
deployment requirements. Their approaches require the use of a
its models on the fly by requiring developers to call a special func-
customized PHP runtime interpreter, which adversely affects the
tion and to pass to the function the query string before user input is
portability of the approaches.
added.
Other dynamic tainting approaches more loosely related to our
Other approaches against SQLIAs rely purely on static analy-
approach are those by Haldar, Chandra, and Franz [8] and Mar-
sis [13, 14, 15, 27]. These approaches scan the application and
tin, Livshits, and Lam [17]. Although they also propose dynamic
leverage information flow analysis or heuristics to detect code that
tainting approaches for Java-based applications, their techniques
could be vulnerable to SQLIAs. Because of the inherently impre-
differ significantly from ours. First, they track taint information at
cise nature of the static analysis they use, these techniques can
the level of granularity of strings, which introduces imprecision in
generate false positives. Moreover, since they rely on declassifi-
modeling string operations. Second, they use declassification rules,
cation rules to transform untrusted input into safe input, they can
instead of syntax-aware evaluation, to assess whether a query string
also generate false negatives. Wassermann and Su propose a tech-
contains an attack. Declassification rules assume that sanitizing
nique [26] that combines static analysis and automated reasoning
functions are always effective, which is an unsafe assumption and
to detect whether an application can generate queries that contain
may leave the application vulnerable to attacks—in many cases, at-
tautologies. This technique is limited, by definition, in the types of
tack strings can pass through sanitizing functions and still be harm-
SQLIAs that it can detect.
ful. Another dynamic tainting approach, proposed by Newsome
Finally, researchers have also focused on ways to directly im-
and Song [19], focuses on tainting at a level that is too low to be
prove the code of an application and eliminate vulnerabilities. De-
used for detecting SQLIAs and has a very high execution overhead.
fensive coding best practices [11] have been proposed as a way
Researchers also proposed dynamic techniques against SQLIAs
to eliminate SQL injection vulnerabilities. These coding practices
that do not rely on tainting. These techniques include Intrusion
have limited effectiveness because they mostly rely on the abil-
Detection Systems (IDS) and automated penetration testing tools.
ity and training of the developer. Moreover, there are many well-
Scott and Sharp propose Security Gateway [23], which uses develo-
known ways to evade certain types of defensive-coding practices,
per-provided rules to filter Web traffic, identify attacks, and ap-
including “pseudo-remedies” such as stored procedures and pre-
ply preventive transformations to potentially malicious inputs. The
pared statements (e.g., [1, 16, 11]). Researchers have also de-
success of this approach depends on the ability of developers to
veloped special libraries that can be used to safely create SQL
write accurate and meaningful filtering rules. Similarly, Valeur and
queries [4, 18]. These approaches, although highly effective, re-
colleagues [25] developed an IDS that uses machine learning to
quire developers to learn new APIs for developing queries, are very
distinguish legitimate and malicious queries. Their approach, like
expensive to apply on legacy code, and sometimes limit the expres-
most learning-based techniques, is limited by the quality of the IDS
siveness of SQL. Finally, JDBC-Checker [6, 7] is a static analysis
training set. Machine learning was also used in WAVES [12], an
tool that detects potential type mismatches in dynamically gener-
automated penetration testing tool that probes websites for vulner-
ated queries. Although it was not intended to prevent SQLIAs,
ability to SQLIAs. Like all testing tools, WAVES cannot provide
JDBC-Checker can be effective against SQLIAs that leverage vul-
any guarantees of completeness. SQLrand [2] appends a random
nerabilities due to type-mismatches, but will not be able to prevent
token to SQL keywords and operators in the application code. A
other kinds of SQLIAs.
proxy server then checks to make sure that all keywords and oper-
7. CONCLUSION Intl. Conference on Software Engineering (ICSE 04), pages
645–654, May 2004.
We presented a novel, highly automated approach for detecting
[8] V. Haldar, D. Chandra, and M. Franz. Dynamic Taint Propagation
and preventing SQL injection attacks in Web applications. Our ba-
for Java. In Proc. of the 21st Annual Computer Security Applications
sic approach consists of (1) identifying trusted data sources and Conference, pages 303–311, Dec. 2005.
marking data coming from these sources as trusted, (2) using dy- [9] W. G. Halfond and A. Orso. AMNESIA: Analysis and Monitoring
namic tainting to track trusted data at runtime, and (3) allowing for NEutralizing SQL-Injection Attacks. In Proc. of the IEEE and
only trusted data to become SQL keywords or operators in query ACM Intl. Conference on Automated Software Engineering (ASE
strings. Unlike previous approaches based on dynamic tainting, 2005), pages 174–183, Long Beach, CA, USA, Nov. 2005.
our technique is based on positive tainting, which explicitly iden- [10] W. G. Halfond, J. Viegas, and A. Orso. A Classification of
SQL-Injection Attacks and Countermeasures. In Proc. of the Intl.
tifies trusted (rather than untrusted) data in the program. In this
Symposium on Secure Software Engineering, Mar. 2006.
way, we eliminate the problem of false negatives that may result [11] M. Howard and D. LeBlanc. Writing Secure Code. Microsoft Press,
from the incomplete identification of all untrusted data sources. Redmond, Washington, Second Edition, 2003.
False positives, while possible in some cases, can typically be eas- [12] Y. Huang, S. Huang, T. Lin, and C. Tsai. Web Application Security
ily eliminated during testing. Our approach also provides practical Assessment by Fault Injection and Behavior Monitoring. In Proc. of
advantages over the many existing techniques whose application the 12th Intl. World Wide Web Conference (WWW 03), pages
requires customized and complex runtime environments. The ap- 148–159, May 2003.
proach is defined at the application level, requires no modification [13] Y. Huang, F. Yu, C. Hang, C. H. Tsai, D. T. Lee, and S. Y. Kuo.
Securing Web Application Code by Static Analysis and Runtime
of the runtime system, and imposes a low execution overhead.
Protection. In Proc. of the 13th Intl. World Wide Web Conference
We have evaluated our approach by developing a prototype tool, (WWW 04), pages 40–52, May 2004.
WASP , and using the tool to protect several applications when sub- [14] N. Jovanovic, C. Kruegel, and E. Kirda. Pixy: A Static Analysis Tool
jected to a large and varied set of attacks and legitimate accesses. for Detecting Web Application Vulnerabilities. In 2006 IEEE
WASP successfully and efficiently stopped over 12,000 attacks with- Symposium on Security and Privacy, May 2006.
out generating any false positives. Both our tool and experimental [15] V. B. Livshits and M. S. Lam. Finding Security Vulnerabilities in
infrastructure are available to other researchers. Java Applications with Static Analysis. In Proceedings of the 14th
We have three immediate goals for future work. The first goal Usenix Security Symposium, Aug. 2005.
[16] O. Maor and A. Shulman. SQL Injection Signatures Evasion. White
is to further improve the efficiency of the technique. To this end,
paper, Imperva, Apr. 2004. http://www.imperva.com/
we will use static analysis to reduce the amount of instrumenta- application defense center/white papers/
tion required by the approach. The second goal is to implement the sql injection signatures evasion.html.
approach for binary applications, by leveraging a binary instrumen- [17] M. Martin, B. Livshits, and M. S. Lam. Finding Application Errors
tation framework and defining a version of the MetaStrings library and Security Flaws Using PQL: a Program Query Language. In
that works at the binary level. Finally, we plan to evaluate our tech- OOPSLA ’05: Proc. of the 20th Annual ACM SIGPLAN Conference
nique in a completely realistic context, by protecting one of the on Object Oriented Programming Systems Languages and
Applications, pages 365–383, Oct. 2005.
Web applications running at Georgia Tech with WASP and assess-
[18] R. McClure and I. Krüger. SQL DOM: Compile Time Checking of
ing the effectiveness of WASP in stopping real attacks directed at Dynamic SQL Statements. In Proc. of the 27th Intl. Conference on
the application while allowing legitimate accesses. Software Engineering (ICSE 05), pages 88–96, May 2005.
[19] J. Newsome and D. Song. Dynamic Taint Analysis for Automatic
Acknowledgments Detection, Analysis, and Signature Generation of Exploits on
This work was supported by NSF awards CCR-0306372 and CCF- Commodity Software. In Proc. of the 12th Annual Network and
Distributed System Security Symposium (NDSS 05), Feb. 2005.
0438871 to Georgia Tech and by the Department of Homeland Se-
[20] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans.
curity and US Air Force under Contract No. FA8750-05-2-0214. Automatically Hardening Web Applications Using Precise Tainting.
Any opinions expressed in this paper are those of the authors and In Twentieth IFIP Intl. Information Security Conference (SEC 2005),
do not necessarily reflect the views of the US Air Force. May 2005.
[21] T. Pietraszek and C. V. Berghe. Defending Against Injection Attacks
8. REFERENCES through Context-Sensitive String Evaluation. In Proc. of Recent
[1] C. Anley. Advanced SQL Injection In SQL Server Applications. Advances in Intrusion Detection (RAID2005), Sep. 2005.
White paper, Next Generation Security Software Ltd., 2002.
[22] J. Saltzer and M. Schroeder. The Protection of Information in
[2] S. W. Boyd and A. D. Keromytis. SQLrand: Preventing SQL Computer Systems. In Proceedings of the IEEE, Sep 1975.
Injection Attacks. In Proc. of the 2nd Applied Cryptography and [23] D. Scott and R. Sharp. Abstracting Application-level Web Security.
Network Security Conf. (ACNS ’04), pages 292–302, Jun. 2004.
In Proc. of the 11th Intl. Conference on the World Wide Web (WWW
[3] G. T. Buehrer, B. W. Weide, and P. A. G. Sivilotti. Using Parse Tree 2002), pages 396–407, May 2002.
Validation to Prevent SQL Injection Attacks. In Proc. of the 5th Intl. [24] Z. Su and G. Wassermann. The Essence of Command Injection
Workshop on Software Engineering and Middleware (SEM ’05),
Attacks in Web Applications. In The 33rd Annual Symposium on
pages 106–113, Sep. 2005.
Principles of Programming Languages, pages 372–382, Jan. 2006.
[4] W. R. Cook and S. Rai. Safe Query Objects: Statically Typed
[25] F. Valeur, D. Mutz, and G. Vigna. A Learning-Based Approach to
Objects as Remotely Executable Queries. In Proc. of the 27th Intl.
the Detection of SQL Attacks. In Proc. of the Conference on
Conference on Software Engineering (ICSE 2005), pages 97–106,
Detection of Intrusions and Malware and Vulnerability Assessment
May 2005. (DIMVA), Vienna, Austria, Jul. 2005.
[5] T. O. Foundation. Top ten most critical web application
[26] G. Wassermann and Z. Su. An Analysis Framework for Security in
vulnerabilities, 2005. http: Web Applications. In Proc. of the FSE Workshop on Specification
//www.owasp.org/documentation/topten.html. and Verification of Component-Based Systems (SAVCBS 2004),
[6] C. Gould, Z. Su, and P. Devanbu. JDBC Checker: A Static Analysis pages 70–78, Oct. 2004.
Tool for SQL/JDBC Applications. In Proc. of the 26th Intl. [27] Y. Xie and A. Aiken. Static Detection of Security Vulnerabilities in
Conference on Software Engineering (ICSE 04) – Formal Demos, Scripting Languages. In Proceedings of the 15th USENIX Security
pages 697–698, May 2004.
Symposium, July 2006.
[7] C. Gould, Z. Su, and P. Devanbu. Static Checking of Dynamically
Generated Queries in Database Applications. In Proc. of the 26th