Information-Flow Security for a Core of JavaScript

Daniel Hedin Andrei Sabelfeld Chalmers University of Technology, Gothenburg, Sweden

Abstract—Tracking information flow in dynamic languages Securing mashups is subject to currently ongoing research remains an important and intricate problem. This paper makes efforts. A recent survey of the area [38] identifies a number substantial headway toward understanding the main challenges of approaches ranging from isolation of components to their and resolving them. We identify language constructs that constitute a core of JavaScript: objects, higher-order functions, full integration. The focus of this paper is tight yet secure exceptions, and dynamic code evaluation. The core is powerful integration for scenarios when isolation is too restrictive and enough to naturally encode native constructs as arrays, as well full integration is insecure. In particular, we are interested as functionalities of JavaScript’s API from the document object in applications where access-control policies fall short and model (DOM) related to document tree manipulation and event where fine-grained information-flow control is desired. processing. As the main contribution, we develop a dynamic type system that guarantees information-flow security for this Scenarios: To illustrate such applications, consider the language. following scenarios. The scenarios are modeled on existing web pages, reflecting pervasive usage of advertising and statistics services on today’s web. I.INTRODUCTION Online advertisement: The first scenario is that of online Tracking information flow in dynamic languages remains shopping. The online shopping code includes a third-party an important and intricate problem. The goal of this paper extension for dynamically generated ads. As items are put in is understanding the fundamentals of challenges for tracking the shopping cart, contextually dependent ads are displayed information flow in dynamic languages and making substan- to the user. The ads are tightly integrated in the shopping tial headway to resolving them. We believe that with these cart, mixing items with discount information, offers from challenges addressed, our work opens up opportunities for the merchant, and ads from cooperating third parties. This practical security of dynamic applications that are hard to is achieved by programmatic manipulation by JavaScript of secure with existing approaches. the nodes in the document object model (DOM) tree, a tree Motivation: Modern web applications make increasingly representation of the underlying document. This results in intensive use of service composition. A particularly thriving a highly dynamic information flow, where secret and public service composition technique is client-side script inclusion. information is mixed in the same linear structure. It allows straightforward integration of services, often pro- User tracking: The second scenario is that of a login to vided by third parties, in so called web mashups. Popular a bank. It illustrates event handling in terms of a keypad examples of integrated services are Google Maps for vi- for entering a shared secret. The keypad is part of an sualizing data on interactive maps and Google Analytics application that contains third-party code for creating click for collecting statistics of web site usage. Extreme cases of heat maps. Such third-party code is common on many web third-party script inclusion can be found on sensitive web sites. Consequently, the position of the clicks must be kept sites like barclays.es, expedia.com, scrive.se, komplett.se, secret from the heat map generator, since the positions of the and webhallen.se, where the scripts are embedded at top clicks encode information about what is entered via the key level, often on the same page where the user enters lo- pad. This implies that information flow through JavaScript gin credentials. With user credentials at hand, integrated event handlers must be secured. client scripts have unrestricted power to engage in inter- These scenarios motivate fine-grained security that is more action with the hosting service. A directory for mashups at permissive than full isolation (as provided by, e.g., iframes) programmableweb.com contains more than 6000 registered and at the same time more secure than full integration (as mashups and more than 5000 registered content provider provided by script inclusion with no additional measures). API’s. Hence, our objective is to provide a solid foundation for The state of the art in web mashup security calls for information-flow control to protect the user from malicious improvement. The same-origin policy (SOP), enforced by scripts run in a browser. To this end, the paper delivers the most browsers today, is intended to restrict access between following contributions. scripts from different Internet domains. SOP offers an all- Contributions: We identify a language that constitutes a core or-nothing choice when including a script: either isolation, of JavaScript and includes the following constructs: objects, when the script is loaded in an iframe, or full integration, higher-order functions, exceptions, and dynamic code eval- when the script is included in the document via a script tag. uation. We argue that the choice of the core captures the essence of the language, and allows us to concentrate on The challenge is identifying a subset of the standard that the fundamental challenges for securing information flow captures the core of JavaScript from an information-flow in dynamic languages (Section II). While we address the perspective, i.e., where the left-out features are either ex- major challenge of handling dynamic language constructs, pressible in the core, or where their inclusion does not reveal we also resolve minor challenges associated with JavaScript. new information-flow challenges. We identify the core of the The semantics of the language closely follows the ECMA- language to be: objects, higher-order functions, exceptions, 262 standard (v.5) [18] on the language constructs from the and eval. In addition, we show that the well-known problems core. associated with the JavaScript variable handling and the with We develop a dynamic type system for information-flow construct can be handled via a faithful modeling in terms of security for the core language (Section III) and establish objects. that the type system enforces a security policy of noninter- ference [11], [22], that prohibits information leaks from the B. Security challenges program’s secret sources to the program’s public sinks (Sec- Before presenting the security challenges, we briefly recap tion IV). Corner cases of the soundness proof are formalized standard information-flow terminology [15]. Traditionally, in the proof assistant Coq [12]. We have implemented the information flow analyses distinguish between explicit and type system and performed a proof-of-concept indicative implicit flows. study of permissiveness using the scenarios above. Explicit flows amount to directly copying information, We show that the core is powerful enough to naturally e.g., via an explicit assignment like l = h;, where the value of encode native constructs as arrays, as well as functional- a secret (or high) variable h is copied into a public (or low) ities of JavaScript’s DOM API related to document tree variable l. High and low represent security levels. We assume manipulation and event processing (Section V). We develop two levels without losing generality: our results apply to these encodings as a part of our implementation for the two arbitrary security lattices [14]. Security labels are used to scenarios above. store security levels for associated variables. In the following The first encoding implements parts of the core function- let h and l represent high and low variables. ality of the Document Object Model (DOM) [27] without Implicit flows may arise when the control flow of the imposing any constraints on the navigation. In particular, program is dependent on secrets. Consider the program direct indexing via the childNodes array, and node relocation if (h) l = 1; else l = 0;. Depending on the secret stored in when repeatedly adding the same node is fully supported. variable h, variable l will be set to either 1 or 0, reflecting The implementation only deals with the dynamic tree struc- the value of h. Hence, there is an implicit flow from h into l. ture of the DOM, in order to investigate the permissiveness Frequently, this is tracked by associating a security label, the of dynamic information flow. It does not obviate the need for security context, with the control flow. Above, the body of specific handling of the DOM in the form of, e.g., wrappers the conditional is executed in a secret context. Equivalently, implementing specific type rules, since the DOM is typically the branches of the conditional are said to be under secret not implemented in JavaScript. control. The definition of public context and public control JavaScript does not include concurrency features. How- are natural duals. ever, the DOM API allows creating JavaScript handlers that are triggered by external events and run without preemption. Eval: The runtime possibility to parse and execute a string The second encoding implements a simplified version of in a JavaScript program, provided by the eval instruction, the events of JavaScript, and shows how the propagation poses a critical challenge for static program analyses, since of events can be controlled, including how events can be the string may not be available to a static analysis. stopped, the presence of certain events can be made secret, Our approach: Dynamic analyses do not share this limita- or how the presence of events can be public, while the data tion, by virtue of the fact that dynamic analyses are executed of the event remains secret. at runtime. This is one of the two main reasons for the use of a dynamic type system in this paper. II.CHALLENGESANDOURAPPROACH The ultimate goal of this work is to enforce information- Aliasing and flow sensitivity: The type system of JavaScript flow security in JavaScript. This section outlines the main is flow sensitive; the types of, e.g., variables and fields challenges and illustrates our approach to resolving them. are allowed to vary during the execution. In addition, ob- jects in JavaScript are heap allocated and represented by A. Language challenges primitive references — their heap location. Hence, objects JavaScript is a dynamically typed, object-based language in JavaScript may be aliased. An alias occurs when two with higher-order functions, and dynamic code evaluation syntactically different program locations (e.g., two variables via, e.g., the eval construction. The voluminous ECMA-262 x and y) refer to the same object (contain the same primitive standard describes the syntax and semantics of JavaScript. reference). Flow sensitivity in the presence of aliases poses a signifi- Permissiveness: As is, no sensitive upgrade prevents af- cant challenge for static analyses, since changing the labels fecting public locations under secret control. This poses a of one of the locations requires that the security labels of permissiveness challenge: how to secure programs where all aliased locations are changed as well, which requires the public locations must be assigned under secret control. static analysis to keep track of the aliasing. Our approach: We address the challenge by facilitating Our approach: Dynamic approaches do not share this upgrade of the security label before entering the secret limitation, since they are able to store the security label in control via the addition of a number of upgrade instructions the referred object instead of associating it with the syntactic to the language. All but one of the upgrade instructions is program location. Consider the following program: expressible in the language. Thus, the addition is merely one x = new Object(); x.f = 0; y = x; y.f = h; of convenience and does not extend the language. Also note that the upgrade instructions are not necessary First, a new object is allocated and the primitive reference for the soundness of the system. They may be used to to the object is stored into x. Thereafter, the field f of the increase the permissiveness of the type system by com- newly allocated object is set to 0, and y is made an alias of municating security policies to the runtime type checker. x, and the field f is overwritten by a secret via y. This kind Although they can be used as part of the programming of programs are rejected by static analysis like Jif [32]. In language, in order to support legacy code it is more fruitful the dynamic setting, we simply update the security label of to view it as a way to incorporate the results of an au- the value of the field f of the allocated object. This is the tomatic analysis. We have successfully experimented with second main reason for the use of a dynamic type system the use of automatic black-box testing to inject the upgrade in this paper. instructions [7]. The idea is to run a modified version Dynamic flow sensitivity: There is a known limitation [21], of the type system on automatically generated test cases, [36] of the flow sensitivity of dynamic analyses. Consider the and, whenever the type system stops the execution, the following example, where we assume h is 1 or 0 originally: trace of the execution is inspected to find the place in the program where an upgrade instruction must be inserted. l = 1 ; t = 0 ; i f ( h == 1) t = 1 ; i f ( t != 1) l = 0 ; The inserted upgrade instructions prevent the monitor from If security labels are allowed to change freely under secret blocking the program and thus help avoiding false positives. control, the above program results in the value of h being Our experiments for a language with records and exceptions copied into l without changing the security label of l. indicate that random testing accurately discovers annotations Our approach: In order to prevent such leaks it suffices for a collection of scenarios with rich information flows. to disallow security label upgrades under secret control. Upgrade of the values of variables and fields: In order to This corresponds to Austin and Flanagan’s no sensitive write to variables or fields under secret control, the language upgrade [2] discipline. Hence, the execution of the above provides instructions that upgrade the security label of the program is stopped with a security error. value of the variable or field. For instance, the example from Structure and existence: Not only the values of fields can the discussion on dynamic flow sensitivity above can be be used to encode information, but also their presence or secured by adding appropriate upgrades: absence. Consider the following example: l = 1 ; t = 0 ; upg t ; i f ( h == 1) t = 1 ; upg l ; i f ( t != 1) l = 0 ; i f ( h ) o . q = 0 ; By upgrading the security label of the value of t before After execution of the conditional the answer to the question the conditional in which t is assigned we guarantee that the whether q is in the domain of o gives away the value of h. security label of the value of t is independent of secrets and It is important to note that not only the presence, but also compatible with the assignment (analogously for l). This the absence, of q gives away information — copying the renders a program that runs for all values of h, and where value of h into l via the presence/absence of q can easily the results stored in variables t and l are always secret. be done by executing l = (o.q == undefined ); , since projecting Upgrade of object structure and field existence: Addition non-existing fields returns undefined. and deletion of fields under secret control is only allowed Our approach: We solve this by associating an existence on structurally secret records: the existence of the added field security label with every field, and a structure security label becomes secret, and only fields with a secret existence label with every object, demanding that addition of new fields are allowed to be removed. To enable fields to be added under secret control is possible only if the structure of the or deleted under secret control the structure security label object is secret. Once the structure of an object is secret, of the record must be raised, as illustrated in the example knowing the absence of fields in the object is also secret. In below: the example above o.q would have secret existence security upg s t r u c t o ; i f ( h ) o . g = 1 ; labels, and the structure of o would have to be secret for the upg existence o . x ; upg existence o . y ; body of the conditional to be allowed to be executed. i f ( h ) d e l e t e o . x ; e l s e d e l e t e o . y ; Finally, it is not possible to express the upgrade of the assignment to l2 will be run. Thus, the update of l2 is existence security label of variables or of the structure public, whereas the update of l1 remains secret. The ex- security label of environment records (see Section III-B). ception handler is run under secret control given that the Under some circumstances this hinders addition and deletion exception label is secret. The exception security label of of variables under secret control. However, this restriction is the handler, however, is the initial exception security label, in line with the design of JavaScript, where variable hoisting which means that exceptions are not allowed in the handler, serves the purpose to make variable declarations independent unless exceptions under secret control are allowed by the of the control structure. outer exception security label. Although the language must be extended with non- Exceptions: Exceptions offer further intricacies, since they standard constructs to handle upgrading of the exception allow for non-local control transfer. Any instructions fol- security label this is not a fundamental limitation. Under lowing an instruction that may throw an exception based on the assumption that normal execution is prevalent, i.e., that a secret must be seen as being under secret control, since, the exceptions are used only in cases where there is a failure. similar to the conditional, the instruction may or may not For such cases, the exception security label instruction can be run based on whether the exception is thrown or not. be provided in order to increase the permissiveness of the Consider the following example: system. In the case the instruction is not made available only l = t r u e ; i f ( h ) {throw 0}; l = f a l s e ; programs that must be able to recover secret exceptions are Whether h is 0 or not controls whether the update is run or affected. not and hence l encodes information about h. Higher-order functions: Being first class values, functions Our approach: The default-allow policy for exceptions carry a security type that must be taken into consideration is clearly too restrictive — it would force us to treat all when calling the function. Consider the following example, side effects after the first possible exception under secret where a secret function f is created by choosing between control as secret. Instead, we introduce a dynamic security two functions under secret control. label for exceptions. If the exception security label is public, f = i f ( h ) { f u n c t i o n g ( x ) { l = 1 ; }} exceptions under secret control are prohibited. If, on the e l s e { f u n c t i o n g ( x ) { l = 0 ; }} other hand, the security label is secret, any side effects are treated as if they were under secret control. Depending on the secret h, a function that writes 1, or a Let us return to the example above. Since the exception functions that write 0 to l is chosen, and applying the result security label in the example is public, the conditional is copies the value of h into l. prevented from throwing exceptions and the update of l Our approach: The body of the function must be run in a can proceed without restrictions. If we want to allow the security context that is at least as secret as the security label exception to be thrown, however, we upgrade the exception of the function. This discipline is inspired by static handling security label, in which case the update of l will be treated of higher-order functions [33]. as being under secret control. On that account, the language Variables and scoping: JavaScript is known for its non- provides an upgrade instruction upg exc that upgrades the standard scoping rules. Variable hoisting in combination exception security label. Note that this instruction is not with non-syntactic scoping, the with and eval constructions, expressible in the language. and the fact that updating non-existing variables will define To make the example above run properly we must upgrade the variable in the global variable environment, cause com- both the exception security label and the security label of plex and sometimes unexpected behavior. To appreciate this the variable l. consider, for instance, conditional shadowing using eval. l = t r u e ; upg l ; upg exc ; f = f u n c t i o n f ( x ) { i f ( h ) { e v a l ( ” var l ” ) } ; l = 0} i f ( h ) {throw 0}; l = f a l s e ; In order to understand this example we must know more Clearly, secret exceptions would be rather prohibitive if about functions and scoping in JavaScript. First, the variable there was no way of lowering the exception security label. To environments form a chain. Variable lookup starts in the this extent, the body of the try-catch statement can be used topmost environment and continues down the chain until to encapsulate exception security label upgrades. Consider the variable has been found or the end of the chain — the the following example: global variable environment — has been reached. l1 = t r u e ; upg l1 ; Second, both if and eval are unscoped, i.e., the variable t r y { upg exc ; i f ( h ) {throw 0}; l1 = f a l s e ; } declared by the eval is declared in the topmost variable catch ( x ) { s k i p } ; l = 1 6 ; 2 environment of the function call. The use of eval is to pre- In this example, since the upgrade of the exception security vent variable hoisting until the execution of the conditional label occurs inside a try-catch statement , we know that branch. Otherwise, l would be hoisted out of the if and regardless of whether an exception is thrown or not the always be declared regardless of the value of h. Execution of f is split into two cases. If h is true, the variable is defined locally in the function, and the update of e ::= s | n | b | undefined | null | this | x | e1[e2] | e1 = e2 l is captured by the local l. If h is false, l is created in the | delete e | typeof (e) | e1 ? e2 | e(e) | new e(e) global variable environment (unless it already exists). Hence, | function x(x) c c ::= var x | c1; c2 | if (e) c1 else c2 | while (e) c both the value of l in the global variable environment and | for (x in e) c | throw e | try c1 catch(x) c2 | return e potentially its existence encodes information about h. The | eval e | with e c | skip | upg l | e latter implies that we must track the structure of variable l ::= e | existence e | struct e | exc environments, similar to objects above. In addition, the presence or absence of the l in the local variable environment A. Syntax (or somewhere else in the chain in general) effects where the Let X range over lists of X, where · denotes the cons update takes place. This means that, when reading or writing operator and [] denotes the empty list, e.g., x denotes lists to variables, the structure security labels encountered during of variable names, and e denotes lists of expressions. the traversal of the variable chain must be taken into account. The syntax of the language consists of two basic syntactic Our approach: We show that the intricate variable behav- categories: expressions, ranged over by e, and statements, ior of JavaScript can be handled by a faithful modeling of ranged over by c. the execution context in terms of objects. Unary operators are represented by delete, and typeof, and, without loss of generality, the binary operators are C. From the core to full JavaScript opaquely represented by ?. In addition, the empty statement is represented by a distinguished skip statement and the The core has been selected to be representative of the language is extended with nonstandard constructions for information flow challenges of JavaScript. The simplifica- security label upgrade of variables and fields, existence tions and omissions have been chosen to not exclude any security labels of fields, structure security labels of objects information flow challenges. Hence, our approach is not a and the exception security label, explained in Section II-B. sub-language approach. Rather we envision that extension For simplicity we assume that each function contains exactly to the full language is possible without further technical one return statement, and that it occurs as the last statement development. in the body of the function. Also, in the following, we In addition, even though property attributes and other identify string literals and variable names, writing s instead ECMA-262 (v.5) features like the ability to freeze objects of ”s”. and strict mode are important from a security perspective and might simplify enforcement of secure information flow we B. Semantics cannot assume that code is strict mode without sacrificing The semantics of the language is given in big-step oper- the possibility of handling legacy code. For this reason, we ational form and provides dynamic security type checking. target the non-strict semantics of ECMA-262 (v.5). This section consists of two parts. First, we introduce With the intuition on the challenges and their resolution the values including a primitive notion of objects, the basis at hand, we are now ready to proceed to the formal devel- for the formulation of ECMA objects. This provides func- opment: the presentation of the dynamic type system and its tionality for basic object interaction, extended to function soundness. objects, providing function call, and object construction via constructor functions, and environment records, providing III.LANGUAGE the foundation for the lexical and variable environments. Second, we introduce the semantics of expressions and The semantics is a subset of the non-strict semantics of statements in terms of the development of the first part. ECMA-262 (v.5) standard. In order to aid the verification of This stepwise construction allows for most of the the semantics and increase confidence in our modeling we information-flow control to be pushed into the basic prim- have chosen to follow the standard closely. itives, simplifying the formulation of more complex func- The semantics is instrumented to track information flow tionality and their explanation. with respect to a two-level security lattice, classifying in- formation as either public or secret, preventing secret infor- v ::= r | s | n | b | undefined p ::=v ˙ | F | c | x σ1 σn mation from affecting public information. This is achieved o ::= {s1 7→ p1,..., sn 7→ pn, σ} by stopping the execution when potential leaks are detected, which is expressed in the semantics by not providing reduc- Values: Let H (secret) and L (public) be security labels, tion rules for the cases that may cause insecure information ranged over by σ, used to label the other values with security flow. Stopping the execution when security violations are information. For clarity in the semantic rules, let pc and  detected may introduce a one-bit information leak, which is range over security labels in the function of security context reflected in our baseline security condition in Section IV. and the exception security label, see Section II-B. The primitive values, ranged over by v, are primitive containing the field together with field name. When reading, references (i.e., opaque pointers), strings, numbers, booleans, the result is raised to security label of the read context. and the undefined value. Similarly to security labels above, The write context of an entity is the read context together r ranges over primitive references in general, while le, ve, with the security context and the exception security label. and τ range over primitive references when denoting lexical When writing to an entity the demand is that the security environments, variable environments, and the this binding, label of the entity is at least as secret as the write context defined below. of the entity. This ensures that the security labels are In the instrumented semantics all primitive values occur independent of secrets. together with a security label representing the security clas- σ sification of the value. Let v be security labeled primitive We define ECMA Objects to be primitive objects extended values, written v˙ when the actual security label is unimpor- σ2 with a relevant selection of the core functionality. In partic- σ2 σ σ1tσ2 tant. Let v˙ = v 1 = v . ular, an ECMA Object O is defined by The references, (r, ˙ s˙), are pairs of security labeled prim- itive references and strings, denoting a field in an object. O = { GetOwnProperty 7→ GetOwnProperty, In the following we let v˙ range over both security labeled GetProperty 7→ GetProperty, value and references, (r, ˙ s˙). HasProperty 7→ HasProperty, Delete 7→ Delete, Get 7→ Get, Put 7→ Put } In addition to the primitive values, the notion of primitive object, ranged over by o, forms the foundation of the The rules for ECMA Objects are found in Table I. semantics of JavaScript. A primitive object is a map from strings to properties, decorated with existence and structure security labels, see Section II-B. The fields are either in- GetOwnProperty: Given a primitive reference and field ternal or external indicated by the IsExternal predicate on name GetOwnProperty returns a property descriptor, strings, which is false for strings of the form s and true {value 7→ v˙} containing the value of the field or undefined otherwise. Internal fields are used in the implementation of in the case the field does not exists. In both cases the the semantics but are not exposed to the programmer — security label of the result is raised to the read context see the semantics of for-in below. The properties of external (i.e. the primitive reference and field name). As discussed in fields are security labeled primitive values, while internal Section II-B the structure security label is taken into account fields may hold algorithms represented by general functions, for non-existing fields. F, statements, c, and lists of formal parameters, x. GetProperty: Let d range over property descriptors or σ σ The heap, ranged over by φ, is a mapping from primitive undefined, d ::= {value 7→ v˙}|undefined , and let d be references to primitive objects. The execution environment defined structurally in the immediate way. GetProperty is E ::= (φ, ) is a pair of a heap, φ, and an exception security formulated in terms of GetOwnProperty and follows the label, . Let E[r] = φ[r] for E = (φ, ). In addition, prototype chain [18] while searching for the field. During execution takes place with respect to an execution context the search the security labels of the primitive references and C ::= (τ, ˙ le,˙ ve˙ ), built up by the this binding, τ, a primitive of the GetOwnProperty results are accumulated and used to reference, le, to the topmost lexical environment, and a raise the final result, cf. the notion of read context and access primitive reference, ve, to the topmost variable environment. path. Let u˙ denote exception lifted values, i.e., u˙ ::=v ˙ | exc v˙. HasProperty: HasProperty is a boolean valued wrapper around GetProperty, i.e., it returns true if the field exists ECMA Objects: All objects of JavaScript define a number and false otherwise. of internal algorithm fields that provide a common interface Delete: Delete deletes fields of objects. Given a primitive for interacting with the object. Most of the standard is reference to a primitive object and a field name the field described in terms of this interface; only few algorithms is removed from the object. Deleting an existing field from manipulate the primitive objects directly. This common core an object, changes the structure of the object, which causes provides an ideal location for handling information flow the demand that the write context of the object is below security. By showing that the core is secure we can easily the structure label, and similarly for the existence, see establish (by using compositionality of our security notion) Section II-B. Similar to the update below, the structure that more complex functionality formulated in terms of the security label is raised to the security label of the field name. core is secure as well. Get: Given a primitive reference and a field name Get uses The explanation of information flow in an object oriented GetOwnProperty to obtain a property descriptor and returns language is facilitated by the notions of read context, and the value of the field or undefined if the field does not exist. write context. The read context for an entity is the accumu- Put: Of the ECMA object algorithms Put is the most com- lated security label of the access path of the entity. For a plicated from an information-flow perspective. It provides field, the access path is the primitive reference to the object addition and update of the fields of objects, with different σ3 o = E[r] o = {s 7→ v,˙ . . . } o = E[r] s 6∈ dom(o) o = {. . . , σ3} GetOwnProperty(rσ1 , sσ2 ) E = {value 7→ v˙ σ1tσ2tσ3 } GetOwnProperty(rσ1 , sσ2 ) E = undefined σ1tσ2tσ3 GetOwnProperty(r, ˙ s˙) E = undefined σ1 GetOwnProperty(r, ˙ s˙) E = {value 7→ v˙} o = E[r] o[ Prototype ] = null σ2 GetProperty(r, ˙ s˙) E = {value 7→ v˙} GetProperty(r, ˙ s˙) E = undefined σ1tσ2 σ GetOwnProperty(r ˙1, s˙) E = undefined 1 σ o = E[r1] o[ Prototype ] =r ˙2 GetProperty(r ˙2, s˙) E = d GetProperty(r, ˙ s˙) E = {value 7→ p } σ σ GetProperty(r ˙1, s˙) E = d 1 HasProperty(r, ˙ s˙) E = true

σ σ3 GetProperty(r, ˙ s˙) E = undefined o = φ[r] o = {s 7→ v,˙ . . . , σ4} σ = pc t  t σ1 σ <: σ4 σ t σ2 <: σ3 σ σ σ L HasProperty(r, ˙ s˙) E = false pc ` Delete(r 1 , s 2 )(φ, ) = (true , (φ[r 7→ o \ s, σ2 t σ4], )) o = E[r] s∈ / dom(o) GetProperty(r, ˙ s˙) E = {value 7→ v˙} GetProperty(r, ˙ s˙) E = undefined σ pc ` Delete(r, ˙ s˙) E = (trueL,E) Get(r, ˙ s˙) E =v ˙ Get(r, ˙ s˙) E = undefined σ

σ3 σ4 o1 = φ[r] o1 = {s 7→ v2 , . . . , σ5} σ = pc t  t σ1 o1 = φ[r] s 6∈ dom(o1) o1 = {. . . , σ3} σ = pc t  t σ1 (σtσ2)uσ3 σtσ2 σtσ2 σtσ2 σ u σ2 <: σ5 σ t σ2 <: σ4 o2 = o1[s 7→ v˙1 , σ2 t σ5] σ <: σ3 o2 = o1[s 7→ v˙1 , σ2 t σ3] σ σ σ σ pc ` Put(r 1 , s 2 , v˙1)(φ, ) = (φ[r 7→ o2], ) pc ` Put(r 1 , s 2 , v˙1)(φ, ) = (φ[r 7→ o2], )

Table I ECMAOBJECTS information-flow restrictions depending on whether the field Initial environment and built-in objects: In addition to the is already present or not. functionality provided by the expressions and statements of In the case of addition, the structure of the object is the language the standard execution environment contains a changed, and the demand is that the previous structure number of built-in objects reachable from the global object. security label is at least as secret as the write context of In the following, public existence security labels and value the object. In addition, flow sensitivity allows the structure security labels of internal fields are frequently omitted in the security label to be raised to the security label of the field case the field is mandatory or cannot be updated. name. Thus, adding field with a secret field name under We define a minimal initial environment, φinit = { rG 7→ public control to an object with public structure will make G, rO 7→ Object }, containing only the global object, G, and the structure of the object secret. The existence security label the object constructor, Object, defined below. and the value security label are both raised to their write Global object: In JavaScript, the global object defines a contexts. number of fields that enriches the execution environment In the case of update, the structure of the object is not with constants, functions and constructors. In addition to changed, but the absence of change encodes information this, the global object acts as the store for global variables. about the field name. If both the write context of the For space reasons, we include only the object constructor, object and the security label of the field name are secret Object, as a constructor property of the global object, it is demanded that the structure of the object is secret. refraining from including the other constructors and pro- Otherwise, the structure is raised to the security label of the totypes. field name. The existence security label is either retained or = [ Prototype 7→ null, Object 7→ r ] lowered, to allow for the existence security label to become G O O public if the field is updated in a public write context using Object constructor: The object constructor, Object = a public field name. Finally, the value security label is raise O[ Prototype 7→ null, prototype 7→ null, Construct 7→ to the write context of the field value. ObjectConstruct ], is a function object that provides function- ality for object creation, via the internal Construct field. Let NewEcma allocate a new ECMA Object and return See below for more information on function objects. The the primitive reference to the newly allocated object ObjectConstruct algorithm allocates a new object, initializes the Prototype field to null, and returns the new primitive r fresh φ2 = φ1[r 7→ O[pc t ]] L reference. pc ` NewEcma (φ1, ) = (r , (φ2, )) (r ˙2,E2) = pc ` NewEcma E1 L L where o[σ] denotes updating the structure security label. E3 = pc ` r˙2. Put ( Prototype , null ) E2 For convenience, we use the standard dot notation pc ` ObjectConstruct(r ˙1, [ ]) E1 = (r ˙2,E3) for method application defined as follows, rσ.X(a) E = (E[r][X](rσ · a) E)σ, where a (the arguments) denotes a list Variable environment and environment records: of security labeled values, v˙. The variable environment is a chain of environment records, chained together by chaining objects, C(r1, r˙2) = Call , and Construct . Let F denote the family of { EnvironmentRecord 7→ r1, OuterEnvironment 7→ r˙2}, function objects where EnvironmentRecord points to the environment record, and OuterEnvironment points to the next chaining F(x, c, r˙) = O[ Scope 7→ r,˙ FormalParameters 7→ x, Code 7→ c, Call 7→ FunctionCall, object in the chain. The environment records store Construct 7→ FunctionConstruct ] the variable bindings and come in two forms: object environment records and declarative environment records Call: Calling a user defined function first allocates a new differing in whether a separate object, the binding object, declarative environment in which the arguments are bound is used to store the variable bindings or if the bindings are by a process called declaration binding. Thereafter the body stored in the environment record itself. Another difference of the function is executed in the updated context. Note that is in the implementation of the ImplicitThisValue, for which the creation of the declarative environment, the declaration the object environment record returns the binding object binding, and the body are run in a security context raised and the declarative environment record returns null. to the security label of the primitive reference, rF , of the We simplify object environment records and declarative function, as is the returned value, see Section II-B. environment records to support the same subset of oper- ations: HasBinding, GetBindingValue, SetMutableBinding, F = E1[rF ] pc2 = pc1 t σ σ DeleteBinding, and ImplicitThisValue. (r, ˙ E2) = pc2 ` NewDeclarativeEnvironment(F[ Scope ] ) E1 E = pc , r˙ ` DeclarationBinding( , a) E The NewDeclarativeEnvironment algorithm allocates 3 2 F 2 pc2, (this(r ˙t), r,˙ r˙) ` hF[ Code ],E3i → hu,˙ E4i a new declarative environment and links it onto the σ σ pc1 ` FunctionCall(r ˙t, rF , a) E1 = (u ˙ ,E4) given environment record chain, and similarly for the NewObjectEnvironment algorithm for object environ- where this(undefined σ) = rσ , and this(r ˙) =r ˙, oth- ments. G erwise. (Recall that rG is the primitive reference to the global object defined above.) See below for the definition r1, r2 fresh E2 = E1[r1 7→ DE, r2 7→ C(r1, r˙)] L the semantics of statements used to evaluate the body, pc ` NewDeclarativeEnvironment(r ˙) E1 = (r ,E2) 2 F[ Code ]. r3, r4 fresh E2 = E1[r3 7→ OE(r ˙2), r4 7→ C(r3, r˙1)] Declaration binding: Declaration binding first binds the pc ` NewObjectEnvironment(r ˙ , r˙ ) E = (rL,E ) 1 2 1 4 2 arguments of the function call and then performs variable hoisting. Get identifier reference: GetIdentifierReference takes a primitive reference to the topmost variable environment and E2 = pc, r˙ ` BindParameters(F[ FormalParameters ], a) E1 a variable name and traverses the chain of environment E3 = pc, r˙ ` HoistVariables(F[ Code ]) E2 records until the variable is found or the chain ends. The pc, r˙ ` DeclarationBinding(F, a) E1 = E3 returned result is a reference (r, ˙ xL) where x is the name of the variable and r is a primitive reference to the environment The parameters are bound by ignoring any surplus param- record containing the variable, or undefined if the variable eters, and setting missing parameters to undefined. was not found. pc, r˙ ` BindParameters([ ], ) E = E

σ σ L GetIdentifierReference(null , x) E = (undefined , x ) L E2 = pc ` r.˙ SetMutableBinding (x , v˙) E1 r1 6= null r2 = E[r1][ EnvironmentRecord ] E3 = pc, r˙ ` BindParameters(x, v) E2 σ2 σ1 L true = r2 . HasBinding (x ) E pc, r˙ ` BindParameters(x · x, v˙ · v) E1 = E3 σ1 σ2 L GetIdentifierReference(r , x) E = (r , x ) L L 1 2 E2 = pc ` r.˙ SetMutableBinding (x , undefined ) E1 r1 6= null r2 = E[r1][ EnvironmentRecord ] E3 = pc, r˙ ` BindParameters(x, [ ]) E2 σ2 σ1 L false = r2 . HasBinding (x ) E pc, r˙ ` BindParameters(x · x, [ ]) E1 = E3 r˙3 = E[r1][ OuterEnvironment ] (r ˙ , x˙) = GetIdentifierReference(r ˙σ2 , x) E 4 3 Variable hoisting traverses the body of the function and σ1 GetIdentifierReference(r1 , x) E = (r ˙4, x˙) defines all variables, initializing them to undefined. The hoisting algorithm HoistVariables is easily formulated and Function objects: Function objects are objects containing can be found in the full version of the paper [26]. two internal properties, Call , used by function application Construct: Object construction via user defined functions and Construct , used in object construction. uses the function as an initializer on a newly allocated User defined function objects: The function objects created ECMA object. Before passing the object, the Prototype when evaluating function expressions are closures storing the field is set to the value of the prototype field of the context the function was created in, the formal parameters of constructor function, after which the object is initialized by the function and the code of the function, used by associated calling the constructor function using the primitive reference to the object as the this argument. Without loss of generality, All rules that contain evaluation of subexpressions use we assume that all constructor functions return a primitive GetValue to convert the results to values, assignment uses reference to the new object. PutValue to update the location denoted by the refer- ence. delete uses Delete or DeleteBinding depending on (r ˙1,E2) = NewEcma E1 pc2 = pc1 t σ if the target is an object or an environment record (in- σ r˙2 = rF . Get (prototype) E2 L dicated by IsPropertyReference). Function creation uses E3 = pc2 ` r˙1. Put ( Prototype , r˙2) E2 σ NewDeclarativeEnvironment to allocate the local variable (u, ˙ E4) = pc2 ` E3[rF ][ Call ](r ˙1, rF , a) E3 σ σ environment, NewFun to create the new function object and pc ` FunctionConstruct(r , a) E1 = (u ˙ ,E4) 1 F SetMutableBinding to initialize the new environment by In the following let NewFun allocate and set up a new binding the function name to the newly created function ob- function object from the given list of formal parameters, ject in order to allow for recursive calls. Function application function body and scope. uses Call, and object creation uses Construct. The field projection, assignment, object construction, and r1 fresh E2 = E1[r1 7→ F(x, c, r˙)] (r ˙2,E3) = NewEcma E2 binary operators all use the evaluation of a list of expressions L L E4 = pc ` r˙2. Put (constructor , r1 ) E3 pc, C ` he, E1i → hv, E2i, which returns a list of security L L E5 = pc ` r1 . Put (prototype , r˙2) E4 labeled values. L pc ` NewFun(x, c, r˙) E1 = (r1 ,E5) Note the this(v ˙) E3 of the function call, which computes the this binding of the invocation, from the reference v˙ = σ Auxiliary reference functions: GetValue fetches the value (r, s) : 1) if the base of the reference, r, is undefined, or associated with a reference; non-reference values are re- if it is a property reference then the base of the reference turned untouched. Subject to the limitations of Section II-B is returned, otherwise, 2) the base is an environment record an exception is raised if the reference is undefined. and the result of calling ImplicitThisValue is returned. Finally, note how typeof returns undefined for undefined variables, whereas using an undefined variable in, e.g., a σ σ pc ` GetValue(v ) E = v binary operator would cause an exception when trying to v˙ =r. ˙ Get (s ˙) E r 6= undefined apply GetValue on the reference. This is the reason typeof pc ` GetValue((r, ˙ s˙)) E =v ˙ can be used to detect whether variables are defined or not. σ t pc <:  r = undefined From an information flow perspective only the rules for pc ` GetValue((rσ, s˙)) (φ, ) = exc ReferenceError σ typeof and binary operators contain primitive information flow (corresponding to the standard treatment of unary and PutValue takes a reference and a value and updates the binary operators); the information flow of the rest of the location denoted by the reference with the value — if the rules is in terms of primitive constructions. reference is undefined the update is done on the global Semantics of statements: Let R ::= E | exc E | hu,˙ Ei object. Subject to the limitations of Section II-B an exception indicating normal termination without return value, excep- is raised if the first argument is not a reference. tional termination, and termination with return value u˙. The σ t pc <:  semantics of statements is of the form pc, C ` hc, Ei → R, σ σ read as c reduces to R when run in E, security context pc pc ` PutValue(v1 , v˙2)(φ, ) = (exc ReferenceError , (φ, )) σ and context C. E2 = pc ` p . Put (s, ˙ v˙) E1 G The semantic rules of statements are found in Table III, pc ` PutValue((undefined σ, s˙), v˙) E = E 1 2 where the rules for exception propagation have been omitted r 6= undefined pc ` r.˙ Put (s, ˙ v˙) E1 = E2 for clarity. We refer the reader to the full version of the pc ` PutValue((r, ˙ s˙), v˙) E1 = E2 paper [26] for the remaining rules. Sequence, iteration in the form of while, and conditional Semantics of expressions: The semantics of expressions is choice are all standard. The two latter raise the security of the form pc, C ` he, E1i → hu,˙ E2i, read as e reduces context of the body and chosen branch to the security label to hu,˙ E2i when run in E1, the security context pc, and the of the controlling expression. context C. The for-in statement iterates over the external fields of The semantic rules for expressions are found in Table II, an object. For each external field name in the object, the where the exception propagation rules have been omitted given variable is updated with the name using the existence for clarity. We refer the reader to the full version of the security label of the field as the security label, and the body paper [26] for the remaining rules. of the for-in is run. The iteration is provided by the three The expression rules are fairly straightforward, and for- rules of the form pc, C ` h(s, v,˙ c),E1i → E2, that for each mulated in terms of the primitives of the previous sec- s˙ in s binds the variable references by v˙ to s˙ before running tion. Identifier dereference uses GetIdentifierReference. c. Recall that s ranges over lists of security labeled strings. pc, C ` he, E1i → hv˙1,E2i v˙2 = pc ` GetValue(v ˙1) E2 L L L L pc, C ` hs|n|b|undefined,Ei → hs |n |b |undefined ,Ei pc, C ` he, E2i → ha, E3i pc, C ` h[],Ei → h[],Ei L pc, C ` hnull,Ei → h0 ,Ei pc, (τ, ˙ le,˙ ve˙ ) ` hthis,Ei → hτ,˙ Ei pc, C ` he · e, E1i → hv˙2 · a, E3i

pc, C ` h[e1, e2],E1i → h[v ˙1, v˙2],E2i pc, C ` h[e1, e2],E1i → h[v ˙1, v˙2],E2i r˙ = pc ` GetValue(v ˙1) E2 v˙3 = pc ` GetValue(v ˙2) E2 v˙ = GetIdentifierReferece(le,˙ x) E s˙ = pc ` GetValue(v ˙2) E2 E3 = pc ` PutValue(v ˙1, v˙3) E2 pc, (τ, ˙ le,˙ ve˙ ) ` hx, Ei → hv,˙ Ei pc, C ` he1[e2],E1i → h(r, ˙ s˙),E2i pc, C ` he1 = e2,E1i → hv˙3,E3i

pc, C ` he, E1i → h(r, ˙ s˙),E2i pc, C ` he, E1i → h(r, ˙ s˙),E2i IsPropertyReference((r, s)) E2 ¬IsPropertyReference((r, s)) E2 σ (v, ˙ E3) = pc ` r.˙ Delete (s ˙) E2 pc, C ` he, E1i → h(undefined , s˙),E2i (v, ˙ E3) = pc ` r.˙ DeleteBinding (s ˙) E2 L pc, C ` hdelete e, E1i → hv,˙ E3i pc, C ` hdelete e, E1i → htrue ,E2i pc, C ` hdelete e, E1i → hv,˙ E3i

pc, C ` he, E1i → hv,˙ E2i r˙ = pc ` GetValue(v ˙) E2 pc, C ` he, E1i → hv,˙ E2i r˙ = pc ` GetValue(v ˙) E2 pc, C ` he, E2i → ha, E3i pc, C ` he, E2i → ha, E3i (u, ˙ E4) = pc ` E3[r][ Call ](this(v ˙) E3, r,˙ a) E3 (u, ˙ E4) = pc ` E3[r][ Construct ](r, ˙ a) E3 pc, C ` he(e),E1i → hu,˙ E4i pc, C ` hnew e(e),E1i → hu,˙ E4i σ ˙ (le2 ,E2) = pc ` NewDeclarativeEnvironment(le1) E1 pc, C ` h[e1, e2],E1i → h[v ˙1, v˙2],E2i σ σ1 (r ˙f ,E3) = pc ` NewFun(x, c, le2 ) E2 r˙ = E3[le2][ EnvironmentRecord ] v3 = pc ` GetValue(v ˙1) E2 σ L σ2 E4 =r ˙ . SetMutableBinding (x , r˙f ) E3 v4 = pc ` GetValue(v ˙2) E2 ˙ σ1tσ2 pc, (τ, ˙ le1, ve˙ ) ` hfunction x(x) c, E1i → hr˙f ,E4i pc, C ` he1 ? e2,E1i → h(v3 ? v4) ,E2i

pc, C ` he, E1i → h(r, ˙ s˙),E2i σ σ pc, C ` he, E1i → hv ,E2i r 6= undefined v = GetValue((r, ˙ s˙)) E2 σ σ pc, C ` htypeof (e),E1i → htypeof (v) ,E2i pc, C ` htypeof (e),E1i → htypeof (v) ,E2i σ pc, C ` he, E1i → h(undefined , s˙),E2i σ pc, C ` htypeof (e),E1i → hundefined ,E2i

Table II SEMANTICSOFEXPRESSIONS

σ σ pc, C ` hc1,E1i → E2 pc, C ` he, E1i → htrue ,E2i pc, C ` he, E1i → hfalse ,E2i pc, C ` hc2,E2i → E3 pc t σ, C ` hc1,E2i → E3 pc t σ, C ` hc2,E2i → E3 pc, C ` hc1; c2,E1i → E3 pc, C ` hif (e) c1 else c2,E1i → E3 pc, C ` hif (e) c1 else c2,E1i → E3 σ pc, C ` he, E1i → htrue ,E2i σ pc, C ` he, E1i → hfalse ,E2i pc t σ, C ` hc, E2i → E3 pc t σ, C ` hwhile (e) c, E3i → E4 pc, C ` h([ ], v,˙ c),Ei → hEi pc, C ` hwhile (e) c, E1i → E2 pc, C ` hwhile (e) c, E1i → E4 IsExternal(s) E = pc ` PutValue(v, ˙ sσ) E 2 1 pc <:  pc t σ, C ` hc, E2i → E3 ¬IsExternal(s) pc, C ` h(s, v,˙ c),E3i → E4 pc, C ` h(s, v,˙ c),E1i → E2 pc, C ` hupg exc, (φ, )i → (φ, H) σ σ pc, C ` h(s · s, v,˙ c),E1i → E4 pc, C ` h(s · s, v,˙ c),E1i → E2 pc, C ` he, E1i → hu,˙ E2i pc, C ` hreturn e, E1i → hu,˙ E2i

pc, C ` hx, E1i → hv˙1,E1i pc, (τ, ˙ le˙ 1, ve˙ ) ` hc1, (φ1, 1)i → hexc v,˙ E2i pc, C ` he, E1i → hv˙2,E2i (leσ,E ) = pc ` NewDeclarativeEnvironment(le˙ ) E σ 2 3 1 2 r = pc ` GetValue(v ˙2) E2 r˙ = E [le ][ EnvironmentRecord ] σ σ 3 2 1 n σ L E2[r] = {s1 7→ p˙1, . . . , sn 7→ p˙n,... } (φ4, 4) =r ˙ . SetMutableBinding (x , v˙) E3 σtσ1 σtσn σ pc, C ` h([s1 , . . . , sn ], v˙1, c),E2i → E3 pc t 4, (τ, ˙ le2 , ve˙ ) ` hc2, (φ4, 1)i → E5

pc, C ` hfor (x in e) c, E1i → E3 pc, (τ, ˙ le˙ 1, ve˙ ) ` htry c1 catch(x) c2, (φ1, 1)i → E5

pc, C ` he, E1i → hv,˙ (φ2, 2)i pc <: 2 pc, C ` hc1, (φ1, 1)i → (φ2, 2) pc, C ` hthrow e, E1i → hexc v,˙ (φ2, 2)i pc, C ` htry c1 catch(x) c2, (φ1, 1)i → (φ2, 1)

σ ˙ pc, (τ, ˙ le,˙ ve˙ ) ` he, E1i → hs ,E2i c = parse(s) pc, (τ, ˙ le1, ve˙ ) ` he, E1i → hv,˙ E2i r˙ = pc ` GetValue(v ˙) E2 E3 = pc, ve˙ ` HoistVariables(c) E2 (le˙ 2,E3) = pc ` NewObjectEnvironment(le˙ 1, r˙) E2 pc t σ, (τ, ˙ le,˙ ve˙ ) ` hc, E2i → E3 pc, (τ, ˙ le˙ 2, ve˙ ) ` hc, E3i → E4

pc, (τ, ˙ le,˙ ve˙ ) ` heval e, E1i → E3 pc, (τ, ˙ le˙ 1, ve˙ ) ` hwith e c, E1i → E4

Table III SEMANTICS OF STATEMENTS The throw demands that the security context pc is below noninterference is a natural fit for the monitor because it the exception security label , as does the exception security justifies the blocking upon detecting a security violation. label upgrade statement. The execution of try-catch is divided into normal and A. Low-equivalence exceptional execution of the body. In the first case, the result Noninterference is formulated in terms of a family of low- of the execution is returned in the outer exception context, equivalence relations · ∼· · for values, objects, heaps, and i.e., the exception security label of the try-catch. This allows environments. The family of relations is defined structurally, for containing exception security label upgrades to the try- demanding that equivalent values carry equal security labels, catch. In the second case, if an exception is thrown in the and in the case the label is public that values are equal. The body of the try-catch, control is passed to the exception definition of the low-equivalence relation can be found in handler. The body of the handler is run in a new lexical the full version of the paper [26]. environment, in which the formal parameter of the handler is bound to the exception value. This means that variables B. Noninterference declared in the body of the handler are not contained to the Two statements c1 and c2 are noninterfering, ni(c1, c2), body of the handler, similar to eval and with above. With if any pair of terminating runs, starting from low-equivalent respect to information flow, the body of the handler is run execution environments, results in low-equivalent execution in a security context which is the least upper bound of the environments: initial security context and the exception security label at the program point where the exception was thrown. This ni(c1, c2) = E1 ∼β1,1 E2 ∧ C1 ∼β1 C2∧ 0 0 guarantees that the body of the handler is unable to leak L, C1 ` hc1,E1i → hu˙ 1,E1i ∧ L, C2 ` hc2,E2i → hu˙ 2,E2i ⇒ 0 0 information about the existence of secret exceptions. Further, ∃β2, 2 . β1 ⊆ β1 ∧ hu˙ 1,E1i ∼β2,2 hu˙ 2,E2i the body of the handler is run in the outer exception security level, since any (uncaught) exceptions in the handler escape We prove the security of the dynamic type system by the try-catch. establishing that all terminating runs of all programs are The eval statement evaluates its argument, parses the noninterfering: result to a program, which is run after hoisting the variables Theorem 1 (Noninterference). ∀c . ni(c, c). into variable environment. Hence, variables introduced by eval are defined in the context of the closest enclosing Proof: The proof (detailed in the full version of this function, or into the global object. The program is run in paper [26]) proceeds by induction on the size of the exe- a security context that is raised to the security label of the cution derivation tree. As is standard, the noninterference parsed string. theorem is uses a supporting lemma that proves freedom of Finally, the with statement changes the lexical environ- public side effects under secret control. The proof includes ment, hence shadowing existing variables, but not containing a number of tricky sub-proofs — in particular Put, and try- any potential variable declarations contained in the body of catch and parts of the exception propagation. Those sub- the with, since the variable hoisting declares the variable in proofs have been independently stated as lemmas, and have the variable environment. been formalized and proved using the proof assistant Coq.

IV. INFORMATION-FLOW SECURITY AND TRANSPARENCY C. Transparency A common policy for information-flow security is nonin- Transparency expresses that the security instrumentation terference [11], [22]. Formally, noninterference is formulated is conservative, i.e., if a program is able to run in the as the preservation of a family of low-equivalence relations, instrumented semantics, then this run is consistent with ∼, under execution. As is standard for languages with refer- the run of the program in the original (un-instrumented) ences [5], the family is indexed by a relation β representing semantics. Let denote evaluation in the un-instrumented a bijection between the public domains of the heaps. semantics that ignores security labels and interpret upgrade There are several flavors of noninterference depending on instructions as skip. Let Φ be a function that removes all whether timing, progress, and termination are taken into security labels from values. account. In the following, we consider a baseline policy Theorem 2 (Transparency). It holds that of termination-insensitive [44], [39] noninterference: two expressions are considered noninterfering if all terminating L, C ` hc, E1i → hu,˙ E2i ⇒ Φ(C) ` hc, Φ(E1)i hΦ(u ˙ ), Φ(E2)i runs agree on public outcomes. Termination-insensitive non- V. SCENARIOS interference allows leaks of information via the termination behavior of programs. In a batch-job setting, it allows leaks This section presents the implementation of the two of at most one bit of information. Termination-insensitive scenarios of Section III. A. Online advertisement upg struct (ul.childNodes); upg (ul.childNodes.length ); Consider an online shopping cart holding a number of upg (ul.lastChild); items. The cart contains a number of items, displaying their upg (I2.nextSibling); upg (D. nextSibling ); name and their prices, and the total price. In addition, the upg (D.prevSibling ); upg (D.parent ); merchant wants to include ads from cooperating third parties As discussed in Section II such upgrade sequences can be and discounts mixed in with the items to get the information generated by automatic testing. Finally, we add the last node, as close to the relevant item. the total, top .appendChild(T);. The resulting situation With some of the edges suppressed for clarity, the result is that items, discounts of the program is the node hierarchy depicted below. Note and third party code are how the contents of I1, I2, D, and T are secret, and how the all mixed, when rendering existence of the discount D is secret, indicated by the secret the cart. This gives rise references between D and its neighbors. In the bottom is to a number of interest- the child nodes array, where the existence of the first three ing information-flow issues. indices is public, and the existence of the last two is secret, Figure 1. Shopping Cart Example For instance, the customer i.e. there exists a point in the array dividing the array into may want to keep the ex- a public left part and a secret right part. The type of this istence of certain items, their prices, or the number of array corresponds to the structural restrictions imposed by items secret. Similarly, the merchant may want to keep Russo et al. [37]. It is interesting to note how this demand any discounts or offers secret, as they reflect a particular arises naturally in the implementation without imposing any customer relationship. restrictions, but rather based on how the array is used by In order to construct the above example we have imple- the node insertion code. Note that this applies only to the mented the core structure of DOM nodes, faithfully imple- array, and not to the linked node structure, which has a more menting the interface mandated by the DOM [27]. We allow liberal type. For instance, it is possible to reach T using the the programmer full access to the link structure in terms lastChild of ul. of parent, firstChild, lastChild, prevSibling, nextSibling, and the childNodes array. Insertion and removal of nodes is ulL provided via insertBefore, appendChild, replaceChild, and removeChild. As mandated by the recommendations [27], repeated insertion of the same node will move the node in L L H H L H H H H the structure. A I1 I2 D T The cart is implemented using the structure of an un- ordered list. This produces a linked structure mixing public and secret data, and where the existence of certain elements 0L : rL 1L : rL 2L : rL 3H : rH 4H : rH might be secret, depending on the security policies of the 1 2 3 4 5 merchant and the customer. Assume that the nodes of the Thus, we have shown how the language of this paper can example ul, A, I1, I2, D, and T have been created and be used to encode the core of the DOM, with the basic properly initialized. The names should be interpreted as operations provided by DOM nodes, with high precision. In follows: ul stands for unordered list, I for item, A for ad, contrast to earlier work (e.g., [37]) this is achieved entirely D for discount and T for total. without taking any DOM-specific information into account. Assuming that the customer wants to protect the price of Everything, including the arrays, has been implemented in the items and the total price, but not the items themselves, the language, and obey the basic type rules of the system. and that the merchant wants to protect the existence of We are, in a natural way, able to freely traverse the resulting discount, we can build the list of the cart by successive use hierarchy and access nodes via the childNodes array. of appendChild on ul. ul.appendChild(A); ul.appendChild(I1); B. User tracking ul.appendChild(I2); ... Consider a login system combining the use of a shared This code adds the ad, and the first items to the list. secret and the use of a username and password. Once the Thereafter, the discount is added under secret control using latter has been presented, a nine-digit keypad and a challenge the expression if (h) top .appendChild(D);, where h = 1H . This are presented. To authenticate, the user finds the correct addition is not allowed without changing the security labels response to the challenge using the shared secret, and uses of the existing structure, since it is being written into under the keypad, to enter the response. Such a system is currently secret control. The following sequence of label upgrades employed by barclays.es using a response size of 2 decimal covers the footprint of the appendChild method. digits chosen from a shared secret of 100 such numbers. At the same time the page uses Google Analytics to track the top. In the example this would allow deduction of the usage. shared secret from the event data sent to the heat map Now assume, that the above is part generator. of a bigger website, where some tech- Propagation of secrets: corresponds to the situation, where nology for generating click heat maps is the second fire event method is used to inject the event. applied. In such a case, it is very impor- This handler upgrades the security label of the data of the tant that the position information of the event, i.e., the position of the click. This makes the event clicks on the keypad is not propagated data secret. Even though the event is propagated upwards, to the heap map generator, since the any operation on the event data will reflect its secrecy, and positions of the clicks give away parts if data reaches the heat map generator it will not be able to Figure 2. Keypad of the shared secret. Further, one might use the data without triggering a security violation. Hence, Example want to protect not only the position the map generator gets to know the existence of the event, information in the click events, but also but not its contents. the fact that the clicks occur. The reasons for this might Stopped propagation of secrets: If we want to prohibit the include secrecy of the length of the response, or secrecy of heat map generator from receiving click events from the the time at which the events occur. keypad altogether, we have two options. The first option is We support the example by implementing a program to install a non-propagating handler in k, (or all of 1 to 9) modeling rudimentary support for event propagation. With- that stops the propagation of events upwards to the parent. In out loss of generality, the model only supports one event such case, events originating from 1 to 9 will be propagated listener per node, and one type of events. An extension to k, where the handler will return false preventing further to multiple event listeners and events is immediate, but propagation which stops the event from reaching the heap clutters the model. Each node provides methods for setting map generator. the event listener, setting the parent and firing an event. Secret propagation: The other method allows the prevention The fire event method takes a parameter, the event data, of click events originating from 1 to 9 from being used by and calls the registered event listener, if one exists. If the the heat map generation without installing special handlers event listener returns true the event is propagated to the in k. Instead, if the third fire event method is used, the parent otherwise not. Three different fire event methods are event handlers, including the heap map generator, will be provided: one acting as previously described, one upgrading executed under secret control. The result is that the heat the event data to secret, and one running the event handler map generator is prevented from causing public side effects, under secret control. The second fire event method models and thus neither the event data or the fact that the event events where the data is secret, e.g., the position data of occurred can be used without causing a security violation. the clicks discussed above, and the third models when both This method is preferable, since it relies on the security the data and the existence of the clicks is secret. In the labels, rather than the presence of a special handler. following, consider the events to be the onClick events generated when the user click on the buttons of the keypad. We have shown how a rudimentary event model can be Simplified, the above exam- encoded natively in the language, and how the features ple can be represented with provide the possibility of dynamic event propagation hierar- d map the following DOM node chies, in addition to both protecting the data of events, and hierarchy, where the nodes the fact that the event occurred. The event implementation k r 1 9 to represents the but- can be seen as a simplified version of the event model of tons grouped under a key- Rafnsson and Sabelfeld [34], which extends the reactive k pad node , which is part model presented by Bohannon et al. [8]. 1 5 9 of the document d, together with the rest of the docu- VI.RELATED WORK ment r, and the click heat map generator map. The hierarchy also represents the parent hierarchy of event Amongst a large body of research on language-based propagation, i.e., events on 1 are propagated to k, and finally approach to information-flow security [39], we discuss most to d, where the event is collected by the click heat map related work on dynamic information control, as well as generator, if the handlers do not stop propagation. Now related work that targets securing JavaScript. consider the following different possibilities. Dynamic information-flow control Our paper pushes the Unconstrained propagation: corresponds to the situation limits of dynamic information-flow enforcement on both described above, where an event is injected using the first expressiveness of the underlying language and on the per- fire event method and is propagated upwards in the parent missiveness of the enforcement. We briefly discuss previous hierarchy after execution of the local handler until reaching work that serves as our starting point. Russo and Sabelfeld [36] show that purely dynamic flow- simplified version of Rafnsson and Sabelfeld’s event model. sensitive monitors do not subsume the permissiveness of JavaScript semantics The literature includes two major flow-sensitive security type systems. Although our monitor approaches to formalizing the semantics of JavaScript. is purely dynamic, the language includes a security label On one hand, Maffeis et al. [29] give a detailed semantics upgrade operator. This means that we can mimic type for full JavaScript. It is a full account of the ECMA-262 systems by injecting security upgrades in appropriate parts standard (v.3) [17], which faithfully models the, sometimes of the code. Hence, the permissiveness of our approach slightly unusual, behavior of JavaScript programs. can be boosted to that of hybrid monitors, at the cost of On the other hand, Guha et al. [25] present a semantics programmer annotations. claimed to capture the essence of JavaScript. They provide a Chugh et al. [10] present a hybrid approach to handling core functional language that shares some similarities to the dynamic execution. Their work is staged where a dynamic semantics of Maffeis, but deviates in a number of important residual is statically computed in the first stage, and checked places regarding the modeling of variables and functions. at runtime in the second stage. Yu et al. [45] also formulate a semantics in terms of a Fenton [21] discusses purely dynamic monitoring for lambda calculus. Contrary to Guha et al. [25], no attempt information flow but does not prove noninterference. Vol- at faithfully mimicking JavaScript scoping is made, thus pano [43] considers a purely dynamic monitor to prevent avoiding key problems associated with JavaScript. explicit (but not implicit) flows. In a flow-insensitive setting, Our semantics is closest to that by Maffeis et al, with Sabelfeld and Russo [40] show that a monitor similar the obvious difference of instrumentation with information- to Fenton’s enforces termination-insensitive noninterference flow checks. Nevertheless, we expect that our transparency without losing in precision to classical static information- theorem also holds against the semantics by Maffeis et al. flow checkers. This line of work has progressed further Compared to the semantics of Guha et al., using a variable to extend the monitor to a language with dynamic code environment chain requires more heavyweight formalism. evaluation, communication, and declassification [1], as well However, it has the benefit that it is able to deal with the as timeout instructions [35]. entire (complex) scoping behavior of JavaScript, including In previous work, Russo et al. [37] investigate the impact with. This is challenging to model in the semantics of Guha of dynamic tree structures like the DOM on information et al., as noted by them. In addition, being close to the flow. The monitor focuses on preventing attacks based on standard makes it natural to verify that the semantics is navigating and deleting DOM tree nodes. The monitor faithful to the JavaScript semantics. derives the security level of existence for each node from Our subset of JavaScript is distilled to illustrate the main the context of its creation. Our model can be viewed as challenges for tracking information flow. Hence, our work is a generalization, where the DOM falls out naturally, and not a safe sub-language approach like Caja [31], FaceBook without losing permissiveness, from the general treatment JavaScript (FBJS) [20], ADSafe [13], Gatekeeper [23], or of pointers and linked structures. the approach by Guha et al. [24]. Further, we chose to be Austin and Flanagan [2], [3] suggest a purely dynamic faithful to the latest version (5) of the ECMA-262 standard. monitor for information flow with a limited form of flow sen- Empirical JavaScript studies On the other side of the spec- sitivity. They discuss two disciplines: no sensitive-upgrade, trum there is empirical work where the goal is not soundness where the execution gets stuck on an attempt to assign to but catching information-flow attacks in the wild. Vogt a public variable in secret context, and permissive-upgrade, et al. [42] implement a static flow-sensitive information- where on an attempt to assign to a public variable in secret flow analysis to crawl around 1,000,000 popular web sites context, the public variable is marked as one that cannot be and, after white/black-listing 30 web sites, detect suspected branched on later in the execution. Austin and Flanagan [3] attempts for cross-domain communication in 1,35% of the discuss inserting privatization operations, which are akin to sites. our upgrade commands. The insertion takes place when a Jang et al. [28] focus on privacy attacks: cookie stealing, variable that was previously upgraded in secret context is location hijacking, history sniffing, and behavior tracking. about to be branched upon. Magazinius et al. [30] show The analysis is based on code rewriting that inlines checks how to inline a no-sensitive upgrade monitor into programs for data produced from sensitive sources no to flow into in a language with dynamic code evaluation. public sinks. They detect a number of attacks present in Bohannon et al. [8] present a flow-insensitive static popular web sites, both in custom code and in third-party analysis for JavaScript-like event systems. Rafnsson and libraries. Sabelfeld [34] model event hierarchies and present a hybrid We believe that the road to bridging the gap between of flow-sensitive static analysis and transformation that formal and empirical approaches is dynamic information- guarantees that at most one bit is leaked per consumed flow tracking. For a language like JavaScript, static analysis public input. Besides the natural differences on dynamic vs. is hardly feasible, as argued by this paper and others [41], static analysis, our event implementation can be seen as a while dynamic analyses provide possibilities for precisely recording relations between data in a given trace. The REFERENCES FlowSafe [19] project at Mozilla takes a similar (dynamic) path. [1] A. Askarov and A. Sabelfeld. Tight enforcement of information-release policies for dynamic languages. In Proc. Secure multi-execution In an orthogonal yet promising IEEE Computer Security Foundations Symposium, July 2009. effort, Devriese and Piessens [16] investigate enforcement of secure information by multi-execution. Multi-execution runs [2] T. H. Austin and C. Flanagan. Efficient purely-dynamic the original program at different security levels and carefully information flow analysis. In Proc. ACM Workshop on synchronizes communication among them. Multi-execution Programming Languages and Analysis for Security (PLAS), June 2009. is secure by design since programs that compute public input only get access to public input. Bielova et al. [6] implement [3] T. H. Austin and C. Flanagan. Permissive dynamic informa- secure multi-execution for the Featherweight Firefox [9] tion flow analysis. In Proc. ACM Workshop on Programming model. Austin and Flanagan [4] propose faceted values to Languages and Analysis for Security (PLAS), June 2010. model secure multi-execution within a single run. Each value facet corresponds to the view of the value from the point [4] T. H. Austin and C. Flanagan. Multiple facets for dynamic information flow. In Proc. ACM Symp. on Principles of of an observer at a given security level. They show that Programming Languages, Jan. 2012. this approach is semantically equivalent to secure multi- execution for a λ-calculus with mutable reference cells. An [5] A. Banerjee and D. A. Naumann. Stack-based access control advantage of this approach with respect to multi-execution and secure information flow. Journal of Functional Program- is that a single faceted execution simulates as many non- ming, 15(2):131–177, Mar. 2005. faceted executions as there are elements in the security lat- [6] N. Bielova, D. Devriese, F. Massacci, and F. Piessens. tice. However, faceted values have to deal with the problem Reactive non-interference for a browser model. In Proc. of tracking control flow (which is a non-issue in original International Conference on Network and System Security secure multi-execution). It is not clear how to scale faceted (NSS), pages 97–104, Sept. 2011. values to handle exceptions. For the secure multi-execution approach as a whole, it remains to be investigated whether [7] A. Birgisson, D. Hedin, and A. Sabelfeld. Boosting the per- silent modification of behavior with respect to the original missiveness of dynamic information-flow tracking by testing. Draft, Apr. 2012. program (such as reordering communication events) is an obstacle in practice. [8] A. Bohannon, B. Pierce, V. Sjoberg,¨ S. Weirich, and S. Zdancewic. Reactive noninterference. In ACM Conference VII.CONCLUSION on Computer and Communications Security, pages 79–90, Nov. 2009. We have developed a dynamic type system for enforcing secure information flow for core features of JavaScript: [9] A. Bohannon and B. C. Pierce. Featherweight Firefox: Formalizing the core of a web browser. In Proc. USENIX objects, higher-order functions, exceptions, and dynamic Security Symposium, June 2010. code evaluation. Our semantic model closely follows the choices of the ECMA-262 standard (v.5) on the language [10] R. Chugh, J. A. Meister, R. Jhala, and S. Lerner. Staged constructs from the core. We have established a formal information flow for javascript. In Proceedings of the 2009 guarantee that the type system guarantees noninterference. In ACM SIGPLAN conference on Programming language design addition, we have illustrated our results with two prototype and implementation, PLDI ’09, New York, NY, USA, 2009. ACM. implementations that show that our framework is powerful enough to support functionalities of JavaScript’s API from [11] E. S. Cohen. Information transmission in sequential programs. the document object model (DOM) without loss of precision. In R. A. DeMillo, D. P. Dobkin, A. K. Jones, and R. J. Lipton, As a result, we improve on previous work both with respect editors, Foundations of Secure Computation, pages 297–335. to modeled language features and permissiveness of the Academic Press, 1978. enforcement. [12] Coq. http://coq.inria.fr. As argued in Section II, our results provide a solid platform for tackling the rest of JavaScript. We believe that [13] D. Crockford. Making javascript safe for advertising. ad- the technical material developed in this paper suffices to safe.org, 2009. support the remaining constructs of JavaScript with minor extensions. [14] D. E. Denning. A lattice model of secure information flow. Comm. of the ACM In accord with the formalization development, we pursue , 19(5):236–243, May 1976. implementation in a form of a JavaScript execution monitor. [15] D. E. Denning and P. J. Denning. Certification of programs Future work includes an evaluation of the permissiveness as for secure information flow. Comm. of the ACM, 20(7):504– well as the performance overhead of the monitor. 513, July 1977. [16] D. Devriese and F. Piessens. Non-interference through secure [33] F. Pottier and V. Simonet. Information flow inference for ML. multi-execution. In Proc. IEEE Symp. on Security and ACM TOPLAS, 25(1):117–158, Jan. 2003. Privacy, May 2010. [34] W. Rafnsson and A. Sabelfeld. Limiting information leakage [17] ECMA International. ECMAScript Language Specification, in event-based communication. In Proc. ACM Workshop on 1999. Version 3. Programming Languages and Analysis for Security (PLAS), June 2011. [18] ECMA International. ECMAScript Language Specification, 2009. Version 5. [35] A. Russo and A. Sabelfeld. Securing timeout instructions in web applications. In Proc. IEEE Computer Security [19] B. Eich. Flowsafe: Information flow security for the browser. Foundations Symposium, July 2009. https://wiki.mozilla.org/FlowSafe, Oct. 2009. [36] A. Russo and A. Sabelfeld. Dynamic vs. static flow-sensitive [20] Facebook. FBJS. http://wiki.developers.facebook.com/index. security analysis. In Proc. IEEE Computer Security Founda- php/FBJS, 2009. tions Symposium, July 2010. Computing J. [21] J. S. Fenton. Memoryless subsystems. , [37] A. Russo, A. Sabelfeld, and A. Chudnov. Tracking informa- 17(2):143–147, May 1974. tion flow in dynamic tree structures. In Proc. European Symp. on Research in Computer Security, LNCS. Springer-Verlag, [22] J. A. Goguen and J. Meseguer. Security policies and security Sept. 2009. models. In Proc. IEEE Symp. on Security and Privacy, pages 11–20, Apr. 1982. [38] P. D. Ryck, M. Decat, L. Desmet, F. Piessens, and W. Joose. [23] S. Guarnieri and B. Livshits. Gatekeeper: mostly static Security of web mashups: a survey. In Nordic Conference in enforcement of security and reliability policies for javascript Secure IT Systems, LNCS, 2010. code. In Proceedings of the 18th conference on USENIX security symposium, SSYM’09, Berkeley, CA, USA, 2009. [39] A. Sabelfeld and A. C. Myers. Language-based information- USENIX Association. flow security. IEEE J. Selected Areas in Communications, 21(1):5–19, Jan. 2003. [24] A. Guha, M. Fredrikson, B. Livshits, and N. Swamy. Verified security for browser extensions. In Proceedings of the [40] A. Sabelfeld and A. Russo. From dynamic to static and 2011 IEEE Symposium on Security and Privacy, SP ’11, back: Riding the roller coaster of information-flow control Washington, DC, USA, 2011. IEEE Computer Society. research. In Proc. Andrei Ershov International Conference on Perspectives of System Informatics, LNCS. Springer-Verlag, [25] A. Guha, C. Saftoiu, and S. Krishnamurthi. The essence June 2009. of JavaScript. In European Conference on Object-Oriented Programming, June 2010. [41] A. Taly, U. Erlingsson, M. Miller, J. Mitchell, and J. Nagra. Automated analysis of security-critical JavaScript APIs. In [26] D. Hedin and A. Sabelfeld. Information-flow security for a Proc. IEEE Symp. on Security and Privacy, May 2011. core of JavaScript. Full version, http://www.cse.chalmers.se/ ∼utter/jsflow/jsflow-full.pdf. [42] P. Vogt, F. Nentwich, N. Jovanovic, E. Kirda, C. Kruegel, and G. Vigna. Cross-site scripting prevention with dynamic data [27] A. L. Hors and P. L. Hegaret. Document Object Model Level tainting and static analysis. In Proc. Network and Distributed 3 Core Specification. Technical report, The World Wide Web System Security Symposium, Feb. 2007. Consortium, 2004. [43] D. Volpano. Safety versus secrecy. In Proc. Symp. on Static [28] D. Jang, R. Jhala, S. Lerner, and H. Shacham. An empirical Analysis, volume 1694 of LNCS, pages 303–311. Springer- study of privacy-violating information flows in JavaScript Verlag, Sept. 1999. web applications. In ACM Conference on Computer and Communications Security, pages 270–283, Oct. 2010. [44] D. Volpano, G. Smith, and C. Irvine. A sound type system for secure flow analysis. J. Computer Security, 4(3):167–187, [29] S. Maffeis, J. C. Mitchell, and A. Taly. An operational 1996. semantics for JavaScript. In Proc. of APLAS’08, volume 5356 of LNCS, pages 307–325, 2008. [45] D. Yu, A. Chander, N. Islam, and I. Serikov. JavaScript instrumentation for browser security. In Proc. ACM Symp. [30] J. Magazinius, A. Russo, and A. Sabelfeld. On-the-fly inlining on Principles of Programming Languages, pages 237–249. of dynamic security monitors. In Proceedings of the IFIP ACM, 2007. International Information Security Conference (SEC), Sept. 2010.

[31] M. Miller, M. Samuel, B. Laurie, I. Awad, and M. Stay. Caja: Safe active content in sanitized javascript, 2008.

[32] A. C. Myers, L. Zheng, S. Zdancewic, S. Chong, and N. Nys- trom. Jif: Java information flow. Software release. Located at http://www.cs.cornell.edu/jif, July 2001.