FLAX: Systematic Discovery of Client-Side Validation Vulnerabilities in Rich Web Applications

FLAX: Systematic Discovery of Client-side Validation Vulnerabilities in Rich Web Applications

Prateek Saxena§ Steve Hanna§ Pongsin Poosankam‡§ Dawn Song§ {prateeks,sch,ppoosank,dawnsong}@eecs.berkeley.edu §University of California, Berkeley ‡Carnegie Mellon University

Abstract side component and a client-side component. The server- side component processes the user’s request and generates The complexity of the client-side components of web an HTML response that is sent back to the browser. The applications has exploded with the increase in popularity client-side code of the web application, typically written in of web 2.0 applications. Today, traditional desktop ap- JavaScript, is sent with the HTML response from the server. plications, such as document viewers, presentation tools The client-side component executes in the web browser and and chat applications are commonly available as online is responsible for processing input data and dynamically up- JavaScript applications. dating the view of web page on the client. We define a CSV Previous research on web vulnerabilities has primarily vulnerability as one which results from unsafe usage of un- concentrated on flaws in the server-side components of web trusted data in the client-side code of the web application. applications. This paper highlights a new class of vulnera- CSV vulnerabilities belong to the general class of in- bilities, which we term client-side validation (or CSV) vul- put validation vulnerabilities, but are different from tradi- nerabilities. CSV vulnerabilities arise from unsafe usage of tional web vulnerabilities like SQL injection [10, 35] and untrusted data in the client-side code of the web applica- reflected/stored cross-site scripting [18, 26, 37, 39]. For ex- tion that is typically written in JavaScript. In this paper, ample, one type of CSV vulnerability involves data that we demonstrate that they can result in a broad spectrum of enters the application through the browser’s cross-window attacks. Our work provides empirical evidence that CSV communication abstractions and is processed completely by vulnerabilities are not merely conceptual but are prevalent JavaScript code, without ever being sent back to the web in today’s web applications. server. Another type of CSV vulnerability is one where a We propose dynamic analysis techniques to systemati- web application sanitizes input data sufficiently before em- cally discover vulnerabilities of this class. The techniques bedding it in its initial HTML response, but does not sani- are light-weight, efficient, and have no false positives. tize the data sufficiently for its use in the JavaScript compo- We implemented our techniques in a prototype tool called nent. FLAX, which scales to real-world applications and has dis- CSV vulnerabilities are becoming increasingly likely covered 11 vulnerabilities in the wild so far. due to the growing complexity of JavaScript applications. Increasing demand for interactive performance of rich web 2.0 applications has led to rapid deployment of application 1 Introduction logic as client-side scripts. A significant fraction of the data processing in AJAX applications (such as Gmail, Google Docs, and Facebook) is done by JavaScript components. Input validation vulnerabilities constitute a majority of JavaScript has several dynamic features for code evaluation web vulnerabilities and have been widely studied in the and is highly permissive in allowing code and data to be past [4, 8, 24, 28, 30, 35, 42, 43]. However, previous vul- inter-mixed. As a result, attacks resulting from CSV vulner- nerability research has focused primarily on the server-side abilities often result in compromise of the web application’s components of web applications. This paper focuses on integrity. client-side validation (or CSV) vulnerabilities, a new class of vulnerabilities which result from bugs in the client-side Goals. As a first step towards finding CSV vulnerabil- code. ities, we aim to develop techniques that analyzes a web A typical Web 2.0 application has two parts: a server- application in an end-to-end manner. Since most existing works have targeted their analyses to server-side compo- if the analysis treats any use of untrusted data which has nents (written in PHP, Java, etc.), this paper develops com- been passed through a parsing/validation construct as safe, plementary techniques to discover vulnerabilities in client- it is likely to miss many bugs. Static analysis is another side code. In particular, we develop a framework for sys- approach [14, 17]; however static analysis tools do not di- tematic analysis of JavaScript1 code. Our objective is to rectly provide concrete exploit instances and require addi- build a tool for vulnerability discovery that does not require tional developer analysis to prune away false positives. developer annotations, has no false positives and is usable Recently, symbolic execution techniques have been used on real-world applications. for discovering and diagnosing vulnerabilities in server-side Challenges. The first challenge of holistic application anal- logic [9,23,25,42]. However, web applications pervasively ysis is in dealing with the complexity of JavaScript. Many use complicated operations on string and arrays data types, JavaScript programs use code evaluation constructs to dy- both of which raise difficulties for decision procedures in- namically generate code as well as to serialize strings into volved in symbolic execution techniques. The power and complex data structures (such as JSON arrays/objects). In expressiveness of string decision procedures today is lim- addition, the language supports myriad high-level opera- ited. Practical implementations of string decision proce- tions on complex data types, which makes the task of prac- dures presently do not deal with the generality of JavaScript tical analysis difficult. string constraints involving common operations (such as In JavaScript application code, we observe that parsing String.replace, regular expression match, concatena- operations are syntactically indistinguishable from validation and equality) expressed together over multi-variable, tion checks. This makes it infeasible for automated syn- variable-length inputs [9,20,23,25]. Other approaches have tactic analyses to reason about the sufficiency of validation been limited to a subset of input-transformation operations checks in isolation from the rest of the logic. Due to the in PHP [4]. The present limitations of symbolic execution convenience of their use in the language, developers tend tools has motivated the need for designing lighter-weight to treat strings as a universal type for exchange, both of techniques. code as well as data. Consequently, complex string op- Our Approach. We propose a dynamic analysis approach erations such as regular expression match and replace are to discover vulnerabilities in web applications called taint pervasively used both for parsing input and for performing enhanced blackbox fuzzing. Our technique is a hybrid ap- custom validation checks. proach that combines the features of dynamic taint analy- Third, in many web applications the client-side code pe- sis with those of automated random fuzzing. It remedies riodically sends data to a remote server for processing via the limitations of purely dynamic taint analysis (described browser interfaces such as XMLHttpRequest, and then above), by using random fuzz testing to generate test cases operates on the returned result. We call such a flow of data, that concretely demonstrate the presence of a CSV vulner- to a server and back, a reflected flow. Client-side analyses ability. This simple mechanism eliminates false alarms that face the inherent difficulty of dealing with hidden process- would result from a purely taint-based tool. ing on remote servers due to reflected flows. The number of test cases generated by vanilla blackbox Existing Approaches. Fuzzing or black-box testing is a fuzzing increases combinatorially with the size of the input. popular light-weight mechanism for testing applications. In our hybrid approach, we use character-level precise dy- However, black-box fuzzing does not scale well with a large namic taint information to prune the input search space sig- number of inputs and is often inefficient in exploration of nificantly. Dynamic taint information extracts knowledge the input space. A more directed approach used in the past of the type of sink operation involved in the vulnerability, in the context of server-side code analysis is based on dy- thereby making the subsequent blackbox fuzzing special- namic taint-tracking. Dynamic taint analysis is useful for ized for each sink type (or in other words, be sink-aware). identifying a flow of data from an untrusted source to a Taint enhanced blackbox fuzzing scales well because the critical operation. However, dynamic taint-tracking alone results of dynamic taint analysis are used to create inde- alone can not determine if the application sufficiently vali- pendent abstractions of the original application which are dates untrusted data before using it, especially when parsing small and take fewer inputs, and can be tested efficiently and validation checks are syntactically indistinguishable. If with sink-aware fuzzing. From our experiments (Section 5), an analysis tool treats all string operations on the input as we report a average reduction of 55% in the input sizes with parsing constructs, it will fail to identify validation checks the use of dynamic taint information. and will report false positives even for legitimate uses (as Summary of Results. We have built a complete implemen- shown by our experiments in Section 5). On the other hand, tation of our techniques into a prototype tool called FLAX. So far, FLAX has discovered 11 CSV vulnerabilities in 1Our JavaScript analysis techniques take a blackbox view of the server- side code currently, though in the future these could be be combined with our preliminary study of 40 popular real-world JavaScript- existing whitebox analyses of server-side components intensive programs in the wild, which includes several third- party iGoogle gadgets, web sites, AJAX applications and user data (such as from form fields or text areas) is treated third-party libraries. These vulnerabilities were unknown to as untrusted as well. Untrusted data could enter the client- us prior to the experiments. Our findings confirm that CSV side code of a web application in three ways. First, data vulnerabilities are not merely conceptual but are prevalent from an untrusted web attacker could be reflected in the in web applications today. Our experimental results also honest web server’s HTML response and subsequently read provide a quantitative measurement of the improvements for processing by the client side code. Second, untrusted taint enhanced blackbox fuzzing gains over vanilla dynamic data from other web sites could be injected via the browser’s taint analysis or random testing in our application. cross-window communication interfaces. These interfaces Summary of Contributions. This paper makes the follow- include HTML 5’s postMessage, URL fragment identi- ing contributions: fiers, and window/frame cross-domain properties. Finally, user data fed in through form fields and text areas is also 1. We introduce client-side validation vulnerabilities, a marked as untrusted. new class of bugs which result from unvalidated usage The first two untrusted sources are concerned with the of untrusted data in JavaScript code. We provide em- threat model where the attacker is a remote entity that has pirical evidence of these vulnerabilities in real-world knowledge of a CSV vulnerability in an honest (but buggy) applications. web application. The attacker’s goal is to remotely exploit a CSV vulnerability to execute arbitrary code, to poi- 2. We build a framework to systematically discover CSV son cookie data (possibly inject session identifiers), or to vulnerabilities called FLAX, which has found 11 pre- issue web application-specific commands on behalf of the viously unknown CSV bugs. Internally, FLAX simpli- user. The attack typically only involves enticing the user fies JavaScript semantics to an intermediate language into clicking a link of the attacker’s choice (such as in a that has a simple type system and a small number of reflected XSS attack). operations. This enables dynamic analyses employed in FLAX to be implemented in a robust and scalable We also consider the “user-as-an-attacker” threat model way. Additionally, FLAX is designed to analyze ap- where the user data is treated as untrusted. In general, user plications with reflected flows without the need for a data should not be interpreted as web application code. For server analysis component. instance, if user can inject scripts into the application, such a bug be used in conjunction with other vulnerabilities (such 3. FLAX employs taint enhanced blackbox fuzzing : a as a login-CSRF vulnerabilities) in which the victim user hybrid, dynamic analysis approach which combines is logged-in as the attacker while the application behavior the benefits of dynamic taint analysis and random is under attacker’s control [6]. In our view, FLAX should fuzzing. This technique is light-weight as compared to make developers aware of the existence of errors in this symbolic execution techniques, has no false positives threat model, even though the severity of resulting exploits and is scalable enough to use on real-world applica- is usually limited and varies significantly from application tions. to application. The problem this paper addresses is that of finding CSV 2 Problem Definition vulnerabilities in the target web application by generating concrete witness inputs. The problem of vulnerability dis- In this section, we outline our threat model, give exam- covery has two orthogonal challenges — exploring the en- ples of CSV vulnerabilities and conceptualize them as a tire functionality of the program, and finding an input that class, and define the problem of finding CSV vulnerabili- exposes a vulnerability in some explored functionality. In ties. this paper, we focus solely on the second challenge, assum- ing that our analysis would be driven by an external test 2.1 Threat Model and Problem Definition harness that explores the large space of the application’s functionality. Specifically, the input to our analysis is a web We define a CSV vulnerability as a programming bug application and an initial benign input. Our analysis aims which results from using untrusted data in a critical sink to find an exploit instance by systematically searching the operation without sufficient validation. A critical sink is a equivalence class of inputs that force the program execution point in the client-side code where data is used with spe- down the same path as the given benign input. cial privilege, such as in a code evaluation construct, or as Running Example. For ease of explanation and concrete- an application-specific command to a backend logic or as ness, we introduce a running example of a hypothetical cookie data. AJAX chat application. The example application consists In our analysis, any data which is controlled by an ex- of two windows. The main window, shown in Figure 1, ternal web principal is treated as untrusted. Additionally, asynchronously fetches chat messages from the backend 1: var chatURL = "http://www.example.com/"; 2: chatURL += "chat_child.html"; 3: var popup = window.open(chatURL); 4: ... 5: function sendChatData (msg) { 6: var StrData = "{\"username\": \"joe\", \"message\": \"" + msg + "\"}"; 7: popup.postMessage(StrData, chatURL); }

Figure 1. An example of a chat application’s JavaScript code for the main window, which fetches messages from the backend server at http://example.com/

server. Another window receives these messages from the structs (such as eval). This class of attacks is commonly main window and displays them, the code for which is referred to as DOM-based XSS [27,29]. An example of this shown in Figure 2. The communication between the two attack is shown in Figure 2 on line 19. In the example, the windows is layered on postMessage2, which is a string- display child window uses eval to serialize the input string based message passing mechanism proposed for inclusion from a JSON format, without validating for its expected in HTML 5. The application code in the display window structure. Such attacks are prevalent today because popular has two sources of untrusted data — the data received via data exchange interfaces, such as JSON, were speciﬁcally postMessage that could be sent by any browser win- designed for use with the eval constructs. In Section 5, dow, and the event.origin property, which is the origin we outline additional phishing attacks in iGoogle gadgets (port, protocol and domain) of the sender. layered on such XSS vulnerabilities, to illustrate that a wide range of nefarious goals can be achieved once the applica- 2.2 Attacks resulting from CSV Vulnerabilities tion integrity is compromised.

While some the vulnerabilities described below have Command injection. Many AJAX applications use un- been discussed in previous research literature by leverag- trusted data to construct URL parameters dynamically, ing other web vulnerabilities, in this section we show that which are then used to direct XMLHttpRequest requests they can result from CSV vulnerabilities as well. to a backend server. Several of these URL parameters function as application-specific commands. For instance, the Origin Mis-attribution. Certain cross-domain commu- chat application in the example sends a confirmation com- nication primitives such as postMessage are designed mand to a backend script on lines 29-31. The backend to facilitate sender authentication. Applications using server script may take other application commands (such postMessage are responsible for validating the authen- as adding friends, creating a chat room, and deleting his- ticity of the domain sending the message. The example in tory) similarly from HTTP URL parameters. If the HTTP Figure 2 illustrates such an attack on line 13. The vulnera- request URL is dynamically constructed by the application bility arises because the application checks the domain field in JavaScript code (as done on line 30) using untrusted data of the origin parameter insufficiently, though the protocol without validation, the attacker could inject new application sub-field is correctly validated. The failed check allows any commands by inserting extra URL parameters. These pa- domain name containing “example”, including an attacker’s rameters could then be interpreted as application commands domain hosted at “evilexample.com”, to send messages. As by the server-side scripts. Since the victim user is already a result, the vulnerable code naively trusts the received data authenticated, command injection allows the attacker to per- even though the data is controlled by an untrusted principal. form unintended actions on behalf of the user. For instance, In the running example, for instance, an untrusted attacker the attacker could send ’hi & call=addfriend&name=evil’ can send chat messages to victim users on behalf of benign as the message which could result in adding the attacker to users. the buddy list of the victim user. Code injection. Code injection is possible because JavaScript can dynamically evaluate both HTML and Cookie-sink vulnerabilities. Web applications often use script code using various DOM methods (such as cookies to store session data, user’s history and preferences. document.write) as well as JavaScript native con- These cookies may be updated and used in the client-side code. If an attacker can control the value written to a cookie 2 In the postMessage interface design, the browser is responsible by exploiting a CSV vulnerability, she may fix the values of for attributing each message with the domain, port, and protocol of the sender principal and making it available as the “origin” string property of the session identifiers (which may result in a session fixation the message event [7,40] attack) or corrupt the user’s preferences and history data. 1:function ParseOriginURL (url) { 17:// Parse JSON into an array object 2: var re=/(.*?):\/\/(.*?)\.com/; 18:function ParseData (DataStr) { 3: var matches = re.exec(url); 19: eval (DataStr); 4: return matches; 20:} 5:} 21:function receiveMessage(event) { 6: 22: var O = ParseOriginURL(event.origin); 7:function ValidateOriginURL (matches) 23: if (ValidateOriginURL (O)) { 8:{ 24: var DataStr = ’var new_msg =(’ + 9: if(!matches) return false; 25: event.data + ’);’; 10: if(!/https?/.test(matches[1])) 26: ParseData(DataStr); 11: return false; 27: display_message(new_msg); 12: var checkDomRegExp = /example/; 29: var backserv = new XMLHttpRequest(); ...; 13: if(!checkDomRegExp.test (matches[2])) { 30: backserv.open("GET","http://example.com/srv.php? 14: return false; } call=confirmrcv&msg="+new_msg["message"]); 15: return true; // All Checks Ok 31: backserv.send();} ... } ... 16:} 32: window.addEventListener("message", receiveMessage,...);

Figure 2. An example vulnerable chat application’s JavaScript code for a child message display win• dow, which takes chat messages from the main window via postMessage. The vulnerable child mes• sage window code processes the received message in four steps, as shown in the receiveMessage function. First, it parses the principal domain of the message sender. Next, it tries to check if the ori• gin’s port and domain are “http” or “https” and “example.com” respectively. If the checks succeed, the popup parses the JSON [3] string data into an array object and ﬁnally, invokes a function for displaying received messages. In lines 29•31, the child window sends conﬁrmation of the message reception to a backend server script.

analysis. Dynamic taint analysis identifies all uses of untrusted data in critical sinks. This analysis identifies two pieces of information about each potentially dangerous data flow: the type of critical sink, and, the fractional part of the input that is influences the data used in the critical sink. Specifically, we extract the range of input characters IS that on which data arguments of a sink operation S are directly dependent. All statements that operate on data that is di- Figure 3. Approach Overview rectly dependent on IS , including path conditions, are ex- tracted into an executable slice of the original application 3 Approach which we term as an acceptor slice (denoted as AS ). AS is termed so because it is a stand-alone program that accepts In this section, we present the key design points of our all inputs in the equivalence class of I, in the sense that they approach and explain our rationale for employing a hybrid execute the same program path as I up to the sink point S. dynamic analysis technique into FLAX. As the second step, we fuzz each AS to find an input that exploits a bug. Our fuzzing is sink-aware because it uses 3.1 Approach and Architectural Overview the details of the sink node exposed by the taint analysis step. Fuzz testing on AS semantically simulates fuzzing on Figure 3 gives a high-level view of our approach – the the original application program. Using an acceptor slice to boxed, shaded part represents the primary technical contri- link the two high-level steps has two advantages: bution of this work. The input to our analysis is an ini- • Program size reduction. AS can be executed as a pro- tial benign input and the target application itself. The tech- gram on its own, but is significantly smaller in size nique explores the equivalence class of inputs that execute than the original application. From our experiments in the same program path as the initial benign input and finds a Section 5, AS is typically smaller than the executed in- flow of untrusted data into a critical sink without sufficient struction sequence by a factor of 1000. Thus, fuzzing validation. on a concise acceptor slice instead of the original com- Approach. In the first step, we execute the application with plex application is a practical improvement. It avoids the initial input I and perform character-level dynamic taint application restart, decouples the two high-level steps, and allows testing of multiple sinks to proceed in par- robust platform for simplified implementation of dy- allel. namic taint analysis and other analyses.

• Fuzzing search space reduction. Sink-aware fuzzing • Aliasing. There are numerous ways in which two dif- focuses only on IS for each AS , rather than the entire ferent syntactic expressions can refer to the same ob- input. Additionally, our sink-aware fuzzer has custom ject at runtime. This arises because of the dynamic fea- rules for each type of critical sink because each sink tures of JavaScript, such as reflection, prototype-based results in different kinds of attacks and requires a dif- inheritance, complex scoping rules, function overload- ferent attack vector. As an example, it distinguishes ing, as well as due to numerous exposed interfaces to eval sinks(which allow injection of JavaScript code) access DOM elements. Reasoning about such a di- from DOM sinks(which allow HTML injection). Our verse set of syntactic variations is difficult. Previous sink-aware fuzzing employs input mutation strategies static analysis techniques applied to this problem area that are based on grammars such as the HTML syntax, required complex points-to analyses [14, 17]. JavaScript syntax, or URL syntax grammars. This forms one of the main motivations for designing 3.2 Technical Challenges and Design Points FLAX as a dynamic analysis tool. FLAX dynamically translates JavaScript operations to JASIL, and by de- One of our contributions is to design a framework that sign each operand (an object, variable or data element) simplifies JavaScript analysis and explicitly models re- in JASIL is identified by its allocated storage address. flected flows and path constraints. We explain each of these With appropriate instrumentation of the JavaScript in- design points in detail below. terpreter, we identify element accesses regardless of the syntactic complexity of the access pattern used in Modeling Path Constraints. The running example in the references. Figure 2 shows how validation checks manifest as conditional checks, affecting the choice of execution path in the Dealing with reflected flows. In this paper, we consider program. Saner, an example of previous work that pre- data flows of two kinds: direct and reflected. A direct flow cisely analyzes server-side code, has considered only input- is one where there is a direct data dependency between a transformation functions as sanitization operations in its dy- source operation and a critical sink operation in script code. namic analysis, thereby ignoring branch conditions [4]. Our Dynamic taint analysis identifies such flows as potentially techniques improve on Saner’s by explicitly modelling path dangerous. A reflected flow occurs when data is sent by the constraints, thereby enabling FLAX to capture the valida- JavaScript application to a backend server for processing tion checks as branch conditions, as shown in the running and the returned results are used in further computation on example in the AS . the client. Our dynamic taint analysis identifies untrusted Simplifying JavaScript. There are two key problems in data propagation across a reflected flow using a common- designing analyses for JavaScript code. substring based content matching algorithm3. During a re- • Rich data types and complex operations. JavaScript flected flow, data could be transformed on the server. The supports complex data types such as string and ar- exact data transformation/sanitization on the server is hid- ray, with a variety of native operations on them. The den from the client-side analysis. To address this, we com- ECMA-262 specification defines over 50 operations on positionally test the client-side code in two steps. First, we string and array data types alone [1]. JavaScript anal- test the client-side code independently of the server-side ysis becomes complex because there are several syn- code by generating candidate inputs that make simple as- tactic constructs that can perform the same semantic sumptions about the transformations occurring in reflected operations. As a simple indicative example, there are flows. Subsequently, it verifies the assumption by running several ways to split a string on a given separator (such the candidate attack concretely, and reports a vulnerability as by using String.split, String.match, String.indexOf, if the concrete test succeeds. and String.substring). In our approach, we canonicalize JavaScript opera- 4 Design and Implementation tions and data references into a simplified intermediate form amenable for analysis, which we call JASIL We describe our algorithm for detecting vulnerabilities (JAvascript Simplified Instruction Language). JASIL and present details about the implementation of our proto- has a simpler type system and a smaller set of instruc- type tool FLAX. tions which are sufficient to faithfully express the se- 3It is possible to combine client-side taint tracking with taint tracking mantics of higher-level operations relevant to the ap- on the server; however, in present work we take a blackbox view of the plications we study. As a result, JASIL serves as a web server. HTTP Request/Response Tainting 2 JASIL Web Server Browser Trace

XMLHttp Request/Response 1

5 Fuzzing 4 Candidate Sink-Aware 3 Veriﬁcation Acceptor Inputs Random Testing

Figure 4. System Architecture for FLAX

4.1 Algorithm

Figure 4 shows the architectural overview of our taint Input: T : Trace enhanced blackbox fuzzing algorithm. The pseudocode of Output: V : AttackString List the algorithm is described in Figure 5. At a high level, it type Flow : { consists of 5 steps: var Sink, Source : Int List, 1. Dynamic trace generation and conversion to JASIL. var TaintedInsList : Int List, Run the application concretely in our instrumented var InputOffset : (Int,Int) List web browser to record an execution trace in JASIL }; form. var FlowList : Flow List; FlowList = CalculateFlows (T ); 2. Dynamic taint analysis. Perform dynamic taint analy- var Candidates = InputString List; sis on the JASIL trace to identify uses of external data var V = InputString List; in critical sinks. For each such potentially dangerous foreach F in FlowList do data flow into a sink S, our analysis computes the part AS = GenAutomaton(F, T ); of the untrusted input (IS ) which flows into the critical Candidates = Fuzz ( AS sink. ,max length, max iters); foreach C in Candidates do 3. Generate an acceptor slice. For each sink S and the CT = ExecuteOnInput(C) given associated information about S from the previ- var Result = V erifyAttack(T , CT ) ous step, the analysis extracts an executable slice, S , A if Result then as defined in Section 3.1. V.append([F, CT .input]); 4. Sink-aware Random testing. Apply random fuzzing to end check if sufficient validation has been performed along end the path to a given sink operation. For a given AS , end our fuzzer generates random inputs according to sink- return V; specific rules and custom attack vectors. 5. Verification of candidate inputs. Randomized testing Figure 5. Algorithm for FLAX of AS generates candidate vulnerability inputs assum- ing a model of the transformation operations on the x: τ ::= v: τ (Assignment, Type Conversion) x: τ ::= ∗ (v : Ref(τ)) (Dereference) x: Int ::= v1 : Int op v1 : Int (Arithmetic) x: Bool ::= v1 : τ op v1 : τ (Relational) x: Bool ::= v1 : Bool op v1 : Bool (Logical) x : PC ::= if (testvar : Bool) then (c : Int) else (c : Int) (Control Flow) x: String ::= substring(s : String, startpos : Int, len : Int) (String Ops) x: String ::= concat(s1 : String,s2: String) (String Ops) x: String ::= fromArray(s1 : Ref(τ)) (String Ops) x: String ::= convert(s1 : String) (String Ops) x: Char ∗ κ ::= convert(i : Int) (Character Ops) x: Int ::= convert(i : Char ∗ κ) (Character Ops) x: τ ::= F (i1 : τ, . . ., in : τ) (Uninterpreted Function Call)

Figure 6. Simpliﬁed operations supported in JASIL intermediate representation

τ := η | β[η] | Bool | Null | Undef | P C ful to the semantics of the operations as implemented η := Int | β therein. In our work, we lower all the native string oper- β := Ref(τ) | String(κ) | Char(κ) ations, array operations, integer operations, regular expres- κ := UTF 8 | UTF 7 | . . . sion based operations, global object functions, DOM functions, and the operations on native window objects. Low- Figure 7. Type system of JASIL intermediate ering to JASIL simplifies analyses. For instance, consider representation a String.replace operation in JavaScript. Intuitively, a replace operation retains some parts of its input string in its output while transforming the other parts with specified server that may occur in reflected flow. This final step strings. An execution of the replace operation can be re- verifies that the assumptions hold, by testing the at- placed by a series of substring operations followed by a final tacks concretely on the web application and checking concatenation of substrings. With JASIL, subsequent dy- that the attack succeeds by using a browser-based ora- namic taint analysis is greatly simplified because the taint- cle. ing engine only needs to reason about simple operations like substring extraction and concatenation. In addition to lowering semantics of complex operations, 4.2 JASIL JASIL explicitly models procedure call/return semantics, parameter evaluation, parameter passing, and object cre- To simplify further analysis, we lower the semantics of ation and destruction. Property look-ups on JavaScript ob- the JavaScript language to a simplified intermediate repre- jects and accesses to native objects such as the DOM or sentation which we call JASIL. JASIL is designed to have window objects are converted to operations on a functional a simple type system with a minimal number of operations map in JASIL (denoted by β[η] in its type system). This on the defined data types. A brief summary of its type sys- canonicalization of references makes further analysis eas- tem and categories of operations are outlined in Figure 7 ier. and Figure 6 respectively. JavaScript interpreters already In JASIL, each object, variable or data element is iden- perform some amount of semantic lowering in converting tified by its allocated storage address, which obviates the to internal bytecode. However, the semantics of typical need to reason about most forms of aliasing. As one exam- JavaScript bytecode are not substantially simpler, because ple of how this simplification allows robust reasoning, con- most of the complexity is hidden in the implementation of sider the case of prototype-based inheritance in JavaScript. the rich native operations that the interpreter’s runtime sup- In JavaScript, whenever an object O is created, the ob- ports. ject inherits all the properties of a prototype object corre- JASIL has a substantially smaller set of operations, sponding to the constructor function, accessible through the shown in Figure 6. In our design, we have found JASIL .prototype property of the function (functions are first- to be sufficient to express the operational semantics of a class types in JavaScript and behave like normal objects). subset of JavaScript commonly used in real applications. The prototype object of the constructor function could in Our design is implemented using WebKit’s JavaScript in- turn inherit from other prototype objects depending on how terpreter, the core of the Safari web browser, and is faith- they are created. When a reference O.f is resolved, the field Critical Flow Sinks Resulting Exploit Sources eval(), window.execScript(), window.setInterval(), Script injection window.setTimeout() document.URL document.write(...), document.writeln(...), document.URLUnencoded document.body.innerHtml, document.cookie document.location.* document.forms[0].action, HTML code injection document.referrer.* document.create(), document.execCommand(), window.location.* document.body.*, window.attachEvent(), event.data document.attachEvent() event.origin document.cookie Session fixation attacks textbox.value XMLHttpRequest.open(,url,), Command Injection and forms.value document.forms[*].action, parameter injection

Figure 8. (Left) Sources of untrusted data. (Right) Critical sinks and corresponding exploits that may result if untrusted data is used without proper validation.

f is first looked up in the object O. If it is not found, it is character-level precise. looked up in the prototype object of O and in the subsequent We list the taint sources and sinks used by default in objects of the prototype chain. Thus, determining which FLAX in Figure 8. FLAX models only direct data de- object is referenced by O statically requires a complex alias pendencies for this step; additional control dependencies analysis. In simplifying to JASIL, we instrumented the in- for path conditions are introduced during AS construction. terpreter to record the address identifier for each variable It performs taint-tracking offline on the JASIL execution used after the reference resolution process (including the trace, which reduces the intrusiveness of the instrumen- scope and prototype chain traversals) is completed. There- tation by not requiring transformation of the interpreter’s fore, further analysis does not need any further reasoning core semantics to support taint-tracking. In our experience, about prototypes or scopes. this has resulted in a more robust implementation than our To collect a JASIL trace of a web application for analy- previous work on online taint-tracking [29]. Taint propa- sis we instrumented the browser’s JavaScript interpreter to gation rules are straight-forward — assignment and arith- translate the bytecode executed at runtime to JASIL. This metic operations taint the destination operand if one of required extensive instrumentation of the JavaScript inter- the input operands is tainted, while preserving character- preter, bytecode compiler and runtime, resulting in a patch level precision. The JASIL string concatenation and of 6032 lines of C++ code to the vanilla WebKit browser. To substring operations result in a merge and slicing oper- facilitate recovering JavaScript source form from the JASIL ation over the ranges of tainted data in the input operands, representation, auxiliary information mapping the dynamic respectively. The convert operation, which imple- allocation addresses to native object types is embedded as ments character-to-integer and integer-to-character con- metadata in the JASIL trace. version, typically results from simplifying JavaScript en- code/decode operations (such as decodeURI). Taint prop- 4.3 Dynamic taint analysis agation rules for convert are similar: the output is tainted if the input is tainted. Other native functions that are not explicitly modeled are treated as uninterpreted transfer func- Character-level precise modeling of string operation se- tions, acting merely to transfer taint from input parameters mantics. JavaScript applications are array- and string- cen- to output parameters in a conservative way. tric; lowering of JavaScript to JASIL is a key factor in reasoning about complex string operations in our target appli- Tracking data in reflected flow. During this anal- cations. Dynamic taint analysis has been used with suc- ysis data may be sent to a backend server via the cess in several security applications outside of the realm of XMLHttpRequest object. We approximate taint propa- JavaScript applications [31, 32, 43]. For JavaScript, Vogt gation across such network data flows by using an exact et al. have previously developed taint-tracking techniques substring match algorithm, which is a simplified form of to detect confidentiality attacks resulting from cross-site black-box taint inference techniques proposed in the previ- scripting vulnerabilities [39]. In contrast to their work, our ous literature [33, 34]. We record all tainted data sent in techniques model the semantics of string operations and are a reflected flow, and perform a longest common substring function acceptor (input) {

var path_constraints = true; http://evilexample.com/ /(.*?):\/\/(.*?)\.com/ var re = /(.*?):\/\/(.*?)\.com/; var matched = re.exec(input); if (matched == null) { path_constraints = path_constraints & false; exec } if (!path_constraints) return false; var domain = matched[2]; http evilexample var valid = /example/.test(domain); http:// path_constraints = path_constraints & valid; evilexample. com if (!path_constraints) return false; var port = matched[1]; /https?/ test test /example/ valid = /https?/.test(port); path_constraints = path_constraints & valid; if (!path_constraints) return false; return true; True True }

Figure 9. (Left) Acceptor Slice showing validation and parsing operations on event.origin ﬁeld in the running example. (Right) Execution of the Acceptor Slice on a candidate attack input, namely http://evilexample.com/

match on the data returned. Any matches that are above a pendencies, i.e., all path constraints, conditions of which threshold length are marked as tainted, and the associated are directly data dependent on IS . Path constraints are con- taint metadata is propagated to the reflected data. This tech- ditional checks corresponding to each branch point which nique has proved sufficient for the AJAX applications in our force the execution to take the same path as IS . Data val- experiments. ues which are not directly data dependent (marked tainted) Implicit Sinks. Certain source operations do not have ex- in the original execution, are replaced with their concrete plicit sink operations. For instance, in our running exam- constant values observed during the program execution. ple (Figure 2) the event.origin field has no explicit Acceptor Slice for the Running Example. The instruc- sink. However, this field must be sanitized before any use tions operating on the event.origin in the running ex- of event.data. We model this case of implicit depen- ample that influences the implicit eval sink is shown in dence between two fields by introducing an implicit sink Figure 9. It shows the AS for the the event.origin node for event.origin at any use of event.data field of our example, after certain optimizations, like dead- in critical sink operation. This has the effect that for code elimination. This program models all the validation any use of event.data, the path constraint checks on checks performed on that field, until its use in the implicit event.origin are implicitly included in the acceptor sink node at eval. slice. 4.5 Sink•aware fuzzing 4.4 Acceptor Slice Construction This step in our analysis performs randomized testing on After dynamic taint analysis identifies a sink point, each AS . Note that each critical sink operation can result FLAX extracts a dynamic executable slice from the pro- in a different kind of vulnerability. Therefore, it is useful gram, by walking backwards from the critical sink to the to target each sink node (S) with a set of specialized at- source of untrusted data. In order to fuzz the slice, the tack vectors. For instance, an unchecked flow that writes to JASIL slice is converted back to a stand-alone JavaScript the innerHTML property of a DOM element can result in function. This results in an executable function that retains HTML code injection and our fuzzer attempts to inject an the operations on IS , and returns true for any input that HTML tag into such a sink. For eval sink, our testing tar- executes the same path as the original run. The slicing op- gets the injection of JavaScript code. We incorporate a large eration captures (a) data dependencies, i.e., all operations corpus of publicly available attack vectors for XSS [19] in directly processing IS and (b) a limited form of control de- our fuzzing. While testing for an attack input that causes AS to re- gadget in its page. To explore each application’s function- turn true, our fuzzer utilizes the aforementioned attack vec- ality, we entered data into text boxes, clicked buttons and tors and a grammar-aware strategy. Starting with the initial hyperlinks, simulating the behavior of a normal user. benign input, the fuzzer employs a mutation-based strategy Google gadgets constitute the largest fraction of our to transform, prepend and appends language nonterminals. study because they are representative of third-party appli- For each choice, the fuzzer first selects terminal characters cations popular among internet users today. Most gadgets based on the knowledge of surrounding text (such as HTML are reported to have thousands of users with one of the vul- tags, JavaScript nonterminals) and finally resorts to random nerable gadgets having over 1,350,000 users, as per the data characters if the grammar-aware strategy fails to find a vul- available from the iGoogle gadget directory on December nerability. 17th 2009 [2]. The other AJAX applications consist of so- To check if a candidate attack input succeeds we use a cial networking sites, chat applications and utility libraries browser-based oracle. Each candidate input is executed in which are examples of the trend towards increasing code AS and the test oracle determines if the specific attack vec- sharing via third-party libraries. All tests were performed tor is evaluated or not. If executed, the attack is verified as using our FLAX framework running on a Ubuntu 8.04 plat- being a concrete attack instance. For instance, in our run- form with a 2.2 GHz, 32-bit Intel dual-core processor and 2 ning example, the event.origin acceptor slice returns GB of RAM. true for any URL principal which is not a subdomain of http://example.com4. Our fuzzer tries string muta- 5.2 Experimental Results tions of the original domain http://example.com and quickly discovers that there are other domains that circum- FLAX finds several distinct taint sinks in the applica- vent the validation checks. tions, only a small fraction of which are deemed vulnerable by the tool. Column 2 and 3 of Table 1 reports the number 5 Evaluation of distinct sinks and number of vulnerabilities reported by FLAX respectively. The use of character-level precise taint Our primary objective was to determine if taint enhanced tracking in FLAX prunes a significant fraction of the input blackbox fuzzing is scalable enough to be used on real- in several cases for further testing. To quantitatively mea- world applications to discover vulnerabilities. As a second sure this saving we observe the average sizes of the orig- objective, we aim to quantitatively measure the benefits of inal input and the reduced input size in the acceptor slices taint enhanced blackbox fuzzing over vanilla taint-tracking (used for subsequent fuzzing), which is reported in columns and purely random testing. In our experiments, FLAX dis- 4 and 5 of Table 1 respectively. We measure the reduction covered 11 previously unknown vulnerabilities in real ap- in the acceptor size, which results in substantial practical plications and our results show that our design of taint en- efficiencies in subsequent black-box fuzzing. We find that hanced blackbox fuzzing offers significant practical gains the acceptor slices are small enough to often enable manual over vanilla taint-tracking and fuzzing. We also investigated analysis for a human analyst. Columns 6 and 7 report the the security implications of the vulnerabilities by construct- size of dynamic execution trace and the average size of the 5 ing proof-of-concept exploits and we discuss their varying acceptor slices respectively . The last two columns in Ta- severity in this section. ble 1 show the number of test cases it takes to find the first vulnerability in each application and the kinds of vulnerability found. 5.1 Test Subjects

We selected a set of 40 web applications consisting of 5.2.1 Prevalence of CSV vulnerabilities iGoogle gadgets and other AJAX applications for our ex- Of the 18 applications that FLAX observes a dangerous periments. Of these, FLAX observed untrusted data flows flow, it found a total of 11 vulnerabilities (reported in the into critical sinks for only 18 of the cases, consisting of 13 third column of Table 1). The vulnerabilities are evidence iGoogle gadgets and 5 web applications. We report detailed of a broad range of attack possibilities, as conceptualized results for only these 18 applications in Table 1. We tested in Section 2, though code injection vulnerabilities were the each subject application manually to explore its functional- highest majority. FLAX reported 8 code injection vulnera- ity, giving benign inputs to seed our automated testing. For bilities, 1 origin mis-attribution vulnerability, 1 cookie-sink instance, all of the iGoogle gadgets were tested by visiting the benign URL used by the iGoogle web page to embed the 5In our implementation, the acceptor slices are converted back to JavaScript form for further analysis: the size of acceptor slices increased 4Recall that the running example acceptor does not have an explicit as a result of this conversion by a factor of 4 at most in our implementation, sink, therefore only return true on success and false otherwise. as compared to the numbers reported in column 7 Name # of Verified Size of Size of Trace Size Avg. size # of Tests Vulnerability Type Taint Sinks Vuln. Total Inputs Acceptor (# of insns) of AS to Find Inputs 1st Vuln. Plaxo 178 0 119 60 557,442 36 - - Academia 1 1 334 21 156,621 286 16 Origin Mis-attribution Facebook Chat 44 0 127 127 6,460,591 1,151 - - ParseURI 1 1 78 62 55,179 638 6 Code injection AjaxIM 20 2 28 28 223,504 517 93 Code injection , Application Command Injection AskAWord 3 1 26 26 59,480 611 93 Cookie Sink Block Notes 1 1 474 96 11,539 766 28 Code injection Birthday Reminder 6 0 632 246 2,178,927 664 - - Calorie Watcher 3 0 681 20 449,214 733 - - Expenses Manager 6 0 1,137 65 522,788 1,454 - - MyListy 1 1 578 47 17,054 1,468 4 Code injection Notes LP 5 0 740 30 144,829 3,327 - - Progress Bar 151 0 496 264 118,108 475 - - Simple Calculator 1 1 27 27 72,475 4 93 Code injection Todo List 1 0 632 40 647,849 1,181 - - TVGuide 2 1 586 66 24,144,843 188 8,366 Code injection Word Monkey 1 1 26 26 237,837 99 93 Code injection Zip Code Gas 5 1 412 69 410,951 248 2 Code injection

Table 1. Applications for which FLAX observed untrusted data ﬂow into critical sinks. The top 5 subject applications are websites and the rest are iGoogle gadgets.

vulnerability and 1 application command injection vulnera- alyzed employed sufficient validation – for instance, Face- bility. We confirmed that all vulnerabilities reported are true book Chat application correctly validates the origin prop- positives by manually inspecting the JavaScript code and erty of every postMessage event it received in the exe- concretely evaluating them with exploit inputs. The sever- cution. Several other applications validate the structure of ity of the vulnerabilities varied by application and source of the input before using it in a JavaScript eval statement or untrusted input, which we discuss in section 5.2.3. strip dangerous characters before using it in HTML code evaluation sinks. 5.2.2 Effectiveness Efficiency of sink-aware fuzzing. Table 1 (column 8) We quantitatively measure the benefits of taint enhanced shows the number of test cases FLAX generated before it blackbox fuzzing over vanilla taint-tracking and random found the vulnerability for the cases it deems unsafe. Part fuzzing from our experimental results. of the reason for the small number of cases on average, is that our fuzzing leverages knowledge for the sink opera- False Positives Comparison. The second column in Ta- tions. Column 4 of the Table 1 shows that the size of the ble 1 shows the number of distinct flows of untrusted data original inputs for most applications are in the range of 100- into critical sink operations observed; only a fraction of 1000 characters. Slicing on the tainted data prunes away a these are true positives. Each of these distinct flows is an in- significant portion of the input space, as seen from column stance where a conservative taint-based tool would report a 5 of Table 1. We report an average reduction of over 55% vulnerability. In contrast, the subsequent step of sink-aware from the original input size to the sizes of test inputs used fuzzing in FLAX eliminates the spurious alarms, and a vul- in acceptor slices. nerability is reported (column 3 of Table 1) only when a Further, the average size of an acceptor slice (reported witness input is found. It should be noted that FLAX can in column 7 of Table 1) is smaller than the original execu- have false negatives and could have missed bugs, but com- tion trace by approximately 3 orders of magnitude. These pleteness is not an objective for FLAX. reductions in test program size for sink-aware fuzzing allow We manually analyzed the taint sinks reported as safe sink-aware fuzzing to work with much smaller abstractions by FLAX and, to the best of our ability, found them to be of the original application, thereby significantly improving true negatives. For instance, we determined that most of the the efficiency of this step. sinks reported for the Plaxo case were due to code which output the length of the untrusted input to the DOM, which Qualitative comparison to other approaches. Figure 10 executed repeatedly each time the user typed a character in shows one of the several examples that FLAX gener- the text box. Many of the true negatives we manually an- ates which can not be directly expressed to the languages function automatom_hard(input) { (AjaxIM), and one URL parsing library’s demonstration //input = ’{"action":"","val":""}’; page. We manually verified that all of these were true pos- must_match = ’{]:],]:]}’; re1 =/\\(?:["\\\/bfnrt]|u[0-9a-fA-F]{4})/g; itives and resulted in script execution in the context of the re2 =/"[ˆ"\\\n\r]*"|true|false|null| vulnerable domains, when the untrusted source was set with -?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g; a malicious value. Four of the code injection vulnerabilities re3 = /(?:ˆ|:|,)(?:\s*\[)+/g; were exploitable when remote attackers entice the user into rep1 = input.replace(re1, "@"); rep2 = rep1.replace(re2, "]"); clicking a link of an attacker’s choice. The affected web rep3 = rep2.replace(re3,""); applications were also available as iGoogle gadgets and we if(rep3 == must_match) { return true; } discuss an a gadget overwriting attack using the CSV vul- return false; nerabilities below. The remaining 4 code injection vulnera- } bilities were self-XSS vulnerabilities as the untrusted input Figure 10. An example of a acceptor slice source was user-input from a form field, a text box, or a text which uses complex string operations for in• area. As explained in section 2.1, these vulnerabilities do put validation, which is not directly express• not directly empower a remote attacker without additional ible to the off•the•shelf string decision proce• social engineering (such as enticing users into copy-and- dures available today. pasting text). All gadget developers we were directly able to communicate with positively acknowledged the concern and agreed to patch the vulnerabilities. Gadget Overwriting Attacks. In a gadget overwriting at- supported by off-the-shelf existing string decision proce- tack, a remote attacker compromises a gadget and replaces dures [21,25], which FLAX deems as safe. We believe that it with the content of its choice. We assume the attacker even human analysis for such cases is tedious and error- is an entity which controls a web-site and has the ability to prone. entice the victim user into clicking a malicious link. We describe a gadget overwriting attack with an example of how 5.2.3 Security Implication Evaluation and Examples it can be used to create a phishing attack layered on the gadget’s CSV vulnerability. In a gadget overwriting attack, the To gain insight into their severity we further analyzed the victim clicks an untrusted link, just as in a reflected XSS vulnerabilities reported by FLAX and created proof-of- attack, and sees a page such as the one shown in Figure 11 concept exploits for a few of them to validate the threat. in his browser. The URL bar of the page points to the le- All vulnerabilities were disclosed to the developers either gitimate iGoogle web site, but the gadget has been compro- through direct communication or through CERT. mised and displays attacker’s contents: in this example, a Origin Mis-attribution in Facebook Connect. FLAX phishing login box which tempts the user to give away his reported an origin mis-attribution vulnerability for credentials for Google. If the user enters his credentials, academia.edu, a popular academic collaboration and they are sent to the attacker rather than Google or the gad- document sharing web site used by several academic get’s web site. The attack mechanics are as follows. First, universities. FLAX reported that the application was vul- the victim visits the attacker’s link which points to the vulnerable due to a missing validation check on the origin nerable gadget domain (typically hosted at a subdomain of property of a received postMessage event. We manually gmodules.com). The link exploits a code injection CSV vul- created a proof-of-concept exploit which demonstrates that nerability in the gadget and the attack payload is executed in any remote attacker could inject arbitrary script code into the context of the gadget’s domain. The attacker’s payload the vulnerable web application. On further analysis, we then spawns a new window which points to the full iGoogle found that the vulnerability existed in the code for Face- web page (http://www.google.com/ig) containing book Connect library, which was used by academia.edu as several gadgets including the vulnerable gadget in separate well as several other web applications. We disclosed the iframes. Lastly, the attacker’s payload replaces the con- vulnerability to Facebook developers on December 15th tent of the vulnerable gadget’s iframe in the new window 2009 and they released a patch for the vulnerability within with contents of its choice. This cross-window scripting is 6 hours of the disclosure. permitted by browser’s same-origin policy because the at- Code Injection. FLAX reported 8 code injection vulnera- tacker’s payload and the gadget’s iframe principal are the bilities (DOM-based XSS) in our target applications, where same. untrusted values were written to code evaluation constructs We point out that Google/IG is designed such that each in JavaScript (such as eval, innerHTML). One DOM- iGoogle gadget runs as a separate security principal hosted based XSS vulnerability was found on each of the follow- at a subdomain of http://gmodules.com. This mitigation ing: 6 distinct iGoogle gadgets, an AJAX chat application prevents an attacker who compromises a gadget from hav- Figure 11. A gadget overwriting attack layered on a CSV vulnerability. The user clicks on an untrusted link which shows the iGoogle web page with an overwritten iGoogle gadget. The URL bar continues to point to the iGoogle web page.

ing any access to the sensitive data of the google.com do- sponse without any client-side or server-side validation. We main. In the past, Barth et al. described a related attack, subsequently informed the developers about the cookie at- called a gadget hijacking attack, which allows attackers6 to tribute injection and the reflected XSS vulnerability through steal sensitive data by navigating the gadget frame to a mali- the cookie channel, and the developers patched the vulner- cious site [7]. Barth et al. proposed new browser frame nav- ability on the same day. igation policies to prevent these attacks. Gadget overwriting attacks resulting from CSV vulnerabilities in vulnerable Application Command Injection. One vulnerability re- gadgets can also allow attacker to achieve the same attack ported by FLAX for AjaxIM chat application indicated that objectives as those remedied by the defenses proposed by such bugs can result in practice. FLAX reported that un- Barth et al. [7]. trusted data from an input text box could be used to inject application commands. AjaxIM uses untrusted data to con- Cookie-sink Vulnerabilities. FLAX reported a cookie cor- struct a URL that directs application-specific commands to ruption vulnerability in one of AskAWord iGoogle gad- its backend server using XMLHttpRequest. These com- gets which provide the AskAWord.com dictionary and spell mands include adding/deleting chat rooms, adding/deleting checker service. FLAX reported that the cookie data could friends and changing the user’s profiles. FLAX dis- be corrupted with arbitrary data and additional cookie at- covered a vulnerability where an unsanitized input from tributes could be injected, which is a low severity vulnera- an input-box is used to construct the URL that sends a bility. However, on further analysis, we found that the gad- GET request command to join a chat room. An attacker get used the cookie to store the user’s history of previous can exploit this vulnerability by injecting new parame- searches which was echoed back on the server’s HTML re- ters (key-value pairs) to the URL. A benign command request URL to join a chat room named ‘friends’ in AjaxIM 6A gadget attacker described by Barth et al. requires the privilege that the integrator embeds a gadget of the attacker choice, which is different is of the form ajaxim.php?call=joinroom&room=friends. from the attacker model in a gadget overwriting attack We confirmed that by providing a room name as ‘friends&call=addbuddy&buddy=evil’ results in overrid- runtime defense against web attacks [18, 29, 32, 35, 37, 38, ing the value of the call command from ‘joinroom’ to a 43]. However, applying these to discover attacks is difficult command that adds an untrusted user (called “evil”) to the because reasoning about validation checks is important for victim’s friend list. precision. Certain tools such as PHPTaint [38] approximate The severity of this vulnerability is very limited as it does this by implicitly clearing the taint when data is sanitized not allow a remote attacker to exploit the bug without addi- using a built-in sanitization routine. tional social engineering. However, we informed the devel- Directed random testing. Our taint enhanced blackbox opers and they acknowledged the concern agreeing to fix fuzzing technique shares some of the benefits of a related the vulnerability. technique called taint-based directed whitebox fuzzing [15]. Both techniques use taint information to narrow down the 6 Related Work space of inputs that are relevant; however, our technique uses the knowledge of the sink to perform a directed blackbox analysis for the vulnerability as opposed to their white- CSV vulnerabilities constitute attack categories that have box analysis due to the limitation of current decision proce- similar counterparts in server-side application logic and dures in our application domain. Techniques developed in browser implementations — this has driven a majority of this paper are related to dynamic symbolic execution based the research on web vulnerabilities to analysis of server-side approaches [11,12,16,21] which use decision procedures to logic written in languages such as PHP. First, we discuss the explore the program space of the application. As discussed techniques employed in these and compare it our taint en- earlier, automated decision procedures for theory of strings hanced blackbox fuzzing. Next, we compare the benefits of today do not support the expressiveness to directly solve our approach with purely taint-based analysis approaches, practical constraints we observe in real JavaScript applica- and other semi-random testing based approaches. Finally, tions. In comparison, our taint enhanced blackbox fuzzing we discuss the recent frameworks proposed for analysis of algorithm is a lighter-weight mechanism which, in prac- JavaScript applications. tice, efficiently combines the benefits of taint-based anal- Server-side vulnerabilities. XSS, SQL injection, directory yses with randomized testing to overcome the limitations of traversal, cross-site request forgery and command injection decision-procedure based tools. have been the most important kind of web vulnerabilities in JavaScript analysis frameworks. Several works have re- the last few years [36]. Techniques including static anal- cently applied static analysis on JavaScript applications [14, yses [22, 24], model checking [28], mixed static-dynamic 17]. In contrast, we demonstrate the practical effectiveness analyses [4], as well as decision procedure based automated of a complimentary dynamic analysis technique and we ex- analyses [21,25] have been developed for server-side appli- plain the benefits of our analyses over their static counter- cations written in PHP and Java. Of these techniques, only parts. GateKeeper enforces a different set of policies us- a few works have aimed to precisely analyze custom valida- ing static techniques which may lead to false positives. Re- tion routines. Balzarotti et al. were the first to identify that cent frameworks for dynamic analyses [44] have been pro- the use of custom sanitization could be an important source posed for source-level instrumentation for JavaScript; how- of both false positives and negatives for analysis tools in ever, source-level transformations are much harder to rea- their work on Saner [4]. The proposed approach used static son about in practice due to the complexity of the JavaScript techniques for reasoning about multiple paths effectively. language. However, the sanitization analysis was limited to a subset of string functions and ignored validation checks that manifest Browser vulnerabilities. CSV vulnerabilities are related as conditional constraints on the execution path. Though an to, but significantly different from browser vulnerabili- area of active research, the more recent string decision pro- ties [5, 7, 13, 41]. Research on these vulnerabilities has cedures do not yet support the full generality of constraints largely focused on better designs of interfaces that could be we practically observed in our JavaScript subject applica- used securely by mutually untrusted principals. In this pa- tions [9, 21, 25]. per, we showed how web application developers use these abstractions, such as inter-frame communication interfaces, Dynamic taint analysis approaches. Vogt et al. have de- in an insecure way. veloped taint-analysis techniques for JavaScript to study the problem of confidentiality attacks resulting from XSS vulnerabilities [39]. In addition to the features provided by 7 Conclusion their work, our taint-tracking techniques are character-level precise and accurately model the semantics of string oper- This paper presents a new class of vulnerabilities, which ations as our application domain requires such precision. we call CSV vulnerabilities. We proposed a hybrid ap- Purely dynamic taint-based approaches have been used for proach to automatically test JavaScript applications for the presence of these vulnerabilities. We implemented our ap- [8] P. Bisht and V. N. Venkatakrishnan. XSS-GUARD: precise proach in a prototype tool called FLAX. FLAX has discov- dynamic prevention of cross-site scripting attacks. In 5th ered several real-world bugs in the wild, which suggests that GI International Conference on Detection of Intrusions & such tools are valuable resources for security analysts and Malware, and Vulnerability Assessment, 2008. developers of rich web applications today. Results from [9] N. Bjorner, N. Tillmann, and A. Voronkov. Path feasibility analysis for string-manipulating programs. In TACAS ’09: running FLAX provide key insight into the prevalence of Proceedings of the 15th International Conference on Tools this class of CSV vulnerabilities with empirical examples, and Algorithms for the Construction and Analysis of Sys- and point out several implicit assumptions and program- tems, 2009. ming errors that JavaScript developers today make. [10] S. W. Boyd and A. D. Keromytis. SQLrand: Preventing SQL injection attacks. In Proceedings of the 2nd Applied Cryp- tography and Network Security (ACNS) Conference, pages 8 Acknowledgments 292–302, 2004. [11] C. Cadar, D. Dunbar, and D. R. Engler. Klee: Unassisted We thank Adam Barth, Stephen McCamant, Adrian Met- and automatic generation of high-coverage tests for complex tler, Joel Weinberger, Matthew Finifter, Devdatta Akhawe, systems programs. In OSDI, 2008. Juan Caballero and Min Gyung Kang for helpful feedback [12] C. Cadar, V. Ganesh, P. M. Pawlowski, D. L. Dill, and D. R. on the paper at various stages. We are also thankful to our Engler. EXE: Automatically generating inputs of death. In CCS, 2006. anonymous reviewers for suggesting improvements to our [13] S. Chen, D. Ross, and Y.-M. Wang. An analysis of browser work. This work is being done while Pongsin Poosankam domain-isolation bugs and a light-weight transparent de- is a visiting student researcher at University of California, fense mechanism. In Proceedings of the 14th ACM con- Berkeley. This material is based upon work partially sup- ference on Computer and Communications Security, pages ported by the National Science Foundation under Grants 2–11, New York, NY, USA, 2007. ACM. No. 0311808, No. 0448452, No. 0627511, and CCF- [14] R. Chugh, J. A. Meister, R. Jhala, and S. Lerner. Staged 0424422, by the Air Force Office of Scientific Research information flow for JavaScript. In PLDI, 2009. under Grant No. 22178970-4170, and by the Army Re- [15] V. Ganesh, T. Leek, and M. Rinard. Taint-based directed whitebox fuzzing. In Proceedings of the 2009 IEEE 31st search Office under Grant No. DAAD19-02-1-0389. Any International Conference on Software Engineering, 2009. opinions, findings, and conclusions or recommendations ex- [16] P. Godefroid, N. Klarlund, and K. Sen. DART: directed au- pressed in this material are those of the authors and do not tomated random testing. In PLDI, 2005. necessarily reflect the views of the National Science Foun- [17] S. Guarnieri and B. Livshits. Gatekeeper: mostly static en- dation, the Air Force Office of Scientific Research, or the forcement of security and reliability policies for JavaScript Army Research Office. code. In Proceedings of the Usenix Security Symposium, Aug. 2009. [18] M. V. Gundy and H. Chen. Noncespaces: Using randomiza- References tion to enforce information flow tracking and thwart cross- site scripting attacks. In NDSS, 2009. [1] Ecmascript language specification, 3rd edition. [19] R. Hansen. XSS cheat sheet. http://ha.ckers.org/ http://www.ecma-international.org/ xss.html. [20] P. Hooimeijer and W. Weimer. A decision procedure for sub- publications/standards/Ecma-262.htm. set constraints over regular languages. In ACM SIGPLAN [2] iGoogle Gadget Directory. http://www.google.com/ Conference on Programming Language Design and Imple- ig/. mentation (PLDI), pages 188–198, June 2009. [3] Introducing JSON. http://www.json.org/. [21] P. Hooimeijer and W. Weimer. A decision procedure for [4] D. Balzarotti, M. Cova, V. Felmetsger, N. Jovanovic, subset constraints over regular languages. In PLDI, 2009. E. Kirda, C. Kruegel, and G. Vigna. Saner: Composing [22] Y. Huang, F. Yu, C. Hang, C. Tsai, D. Lee, and S. Kuo. Se- Static and Dynamic Analysis to Validate Sanitization in Web curing web application code by static analysis and runtime Applications. In Proceedings of the IEEE Symposium on Se- protection. The 13th International Conference on World curity and Privacy, Oakland, CA, May 2008. Wide Web, 2004. [5] A. Barth, J. Caballero, and D. Song. Secure content sniff- [23] S. Jha, S. A. Seshia, and R. Limaye. On the computa- ing for web browsers or how to stop papers from reviewing tional complexity of satisfiability solving for string theories. themselves. In Proceedings of the 30th IEEE Symposium on CoRR, abs/0903.2825, 2009. Security and Privacy, Oakland, CA, May 2009. [24] N. Jovanovic, C. Krugel,¨ and E. Kirda. Pixy: A static anal- [6] A. Barth, C. Jackson, and J. C. Mitchell. Robust defenses ysis tool for detecting web application vulnerabilities (short for cross-site request forgery. In CCS, 2008. paper). In IEEE Symposium on Security and Privacy, 2006. [7] A. Barth, C. Jackson, and J. C. Mitchell. Securing frame [25] A. Kiezun,˙ V. Ganesh, P. J. Guo, P. Hooimeijer, and M. D. communication in browsers. In Proceedings of the 17th Ernst. HAMPI: A solver for string constraints. In Proceed- USENIX Security Symposium (USENIX Security 2008), ings of the International Symposium on Software Testing and 2008. Analysis, 2009. [26] E. Kirda, C. Kruegel, G. Vigna, and N. Jovanovic. Noxes: [43] W. Xu, S. Bhatkar, and R. Sekar. Taint-enhanced policy en- a client-side solution for mitigating cross-site scripting at- forcement: A practical approach to defeat a wide range of tacks. In Proceedings of the ACM Symposium on Applied attacks. In Proceedings of the USENIX Security Symposium, Computing, 2006. 2006. [27] A. Klein. DOM based cross site scripting or XSS of the [44] D. Yu, A. Chander, N. Islam, and I. Serikov. JavaScript in- third kind. Technical report, Web Application Security Con- strumentation for browser security. In Proceedings of the sortium, 2005. ACM SIGPLAN-SIGACT symposium on Principles of pro- [28] M. Martin and M. S. Lam. Automatic generation of XSS and gramming languages, 2007. SQL injection attacks with goal-directed model checking. In 17th USENIX Security Symposium, 2008. [29] Y. Nadji, P. Saxena, and D. Song. Document structure integrity: A robust basis for cross-site scripting defense. In NDSS, 2009. [30] S. Nanda, L.-C. Lam, and T. Chiueh. Dynamic multi- process information flow tracking for web application security. In Proceedings of the 8th ACM/IFIP/USENIX international conference on Middleware companion, 2007. [31] J. Newsome and D. Song. Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software. In Proceedings of the Net- work and Distributed System Security Symposium (NDSS), 2005. [32] A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans. Automatically hardening web applications using precise tainting. 20th IFIP International Information Secu- rity Conference, 2005. [33] R. Sekar. An efficient black-box technique for defeating web application attacks. In NDSS, 2009. [34] E. Stinson and J. C. Mitchell. Characterizing bots’ remote control behavior. In Botnet Detection, volume 36, pages 45– 64. 2008. [35] Z. Su and G. Wassermann. The essence of command injection attacks in web applications. In Proceedings of the ACM SIGPLAN-SIGACT symposium on Principles of Pro- gramming Languages, 2006. [36] Symantec Corp. Symantec internet security threat report. Technical report, Apr. 2008. [37] M. Ter Louw and V. N. Venkatakrishnan. BluePrint: Ro- bust Prevention of Cross-site Scripting Attacks for Existing Browsers. In Proceedings of the IEEE Symposium on Secu- rity and Privacy, 2009. [38] W. Venema. Taint support for PHP. http://wiki.php. net/rfc/taint, 2007. [39] P. Vogt, F. Nentwich, N. Jovanovic, E. Kirda, C. Kruegel, and G. Vigna. Cross-Site Scripting Prevention with Dy- namic Data Tainting and Static Analysis. In Proceeding of the Network and Distributed System Security Symposium (NDSS), Feb. 2007. [40] W3C. HTML 5 specification. http://www.w3.org/ TR/html5/. [41] H. J. Wang, X. Fan, J. Howell, and C. Jackson. Protection and communication abstractions for web browsers in mashu- pos. In SOSP, 2007. [42] G. Wassermann, D. Yu, A. Chander, D. Dhurjati, H. Ina- mura, and Z. Su. Dynamic test input generation for web applications. In ISSTA ’08: Proceedings of the 2008 international symposium on Software testing and analysis, 2008.