Static Analysis for JavaScript

Transcription

1 Static Analysis for JavaScript Adi Yoga Sidi Prabawa Supervisor: Associate Professor Chin Wei Ngan Department of Computer Science School of Computing National University of Singapore June 30, 2013

2 Abstract JavaScript has become the de facto programming language for the web. Initially used for a richer experience and interactivity in the client webbrowser, JavaScript has gained acceptance outside the web-browser environment with the use in Modern (traditionally called Metro) application in Windows 8, mobile application in Firefox OS, and event-driven, high-performance server called Node.js. The dynamic nature of JavaScript allows for easy coding of small program but even these small programs are notoriously hard to debug and they pose major security risks for web-applications. We plan to design a rich program logic that is expressive enough to capture the symbolic states of JavaScript programs while maintaining the capability for automated reasoning and verification. The main challenges in analyzing JavaScript programs are the dynamic-typing system, the prototype-based inheritance, higher-order functions, and eval meta-operations that allows code to be constructed at runtime. Our aim is to design a framework for static analysis of JavaScript programs. 1

3 Contents 1 Introduction 4 2 A Tour of JavaScript JavaScript Objects JavaScript Functions Prototype-Based Inheritance Scoping in JavaScript Higher-Order Functions eval and Other Meta-Functions JavaScript Strict Mode Significance of JavaScript Semantics of JavaScript Separation Logic From Hoare Logic to Separation Logic Introduction to Separation Logic HIP/SLEEK Current Verification Methods Static Type-Checking Axiomatic Verification Object-Capabilities Model Our Proposed System Source-to-Source Translation Dynamic-Typing Higher-Order Functions Future Research and Conclusion 64 1

4 List of Figures 1 Basic JavaScript Example Basic JavaScript Example with Hoisting Example JavaScript Object Creation Checking for Field in JavaScript Example JavaScript Array Creation Primitive Datatype and Object Type Coercion Example JavaScript Function Example JavaScript Function Parameters Immediately Invoked Function Expression JavaScript Prototype Example Relationships between Objects on Figure JavaScript Function Prototype Relationships between Objects on Figure JavaScript instanceof Example JavaScript with-statement and Scope-Chain Scope-Chain at Line 11 of Figure 16 from Call at Line 16 and JavaScript Higher-Order Map Function JavaScript eval Evaluation Context ES5S Restriction Effect of Ramify Rule Core Imperative Language Function.prototype vs Object.prototype Diagram Explaining the Behavior shown in Figure with-statement Before Translation with-statement After Translation

5 27 Comparison of Untranslated and Translated with-statement

6 1 Introduction JavaScript (E.C.M.A.International, 2011) is the assembly language of the web. Developed by Brendan Eich at Netscape in 1995, JavaScript has broken out of the traditional web-browser environment and find usage in Modern (traditionally called Metro) application in Windows 8, mobile application in Firefox OS, and even-driven, high-performance server called Node.js (Tilkov and Vinoski, 2010). In Firefox OS, mobile applications are developed entirely in HTML and JavaScript while in Node.js, this server-side code is written entirely in JavaScript running on V8 JavaScript engine. The language is not standardized until November 1996 by ECMA International and renamed into ECMAScript. Even then, it is not until June 1997 that the first edition of the ECMA-262 specification came out. Most of the specifications were informal and there is a lack of tractable account for the language. While there has been recent interest in the semantics of the language (Maffeis et al., 2008; Guha et al., 2010; Gardner et al., 2012), research in verification of JavaScript language is still lacking in comparison to other object-oriented language such as C++ (Stroustrup, 1994) and Java (Gosling et al., 2005). Current modern web-browser should supports all the features of ECMAScript 3 (ES3) (E.C.M.A.International, 1999) and ECMAScript 5.1 (ES5) (E.C.M.A.International, 2011). In addition, a safer variant of ES5 called ECMAScript 5 Strict Mode (ES5S) is available for opt in by developer. ES5 is considered to be the superset of ES3 as it incorporates many aspects of ES3. Whenever it is clear from the context, the term JavaScript will refer to the ES5 which are compatible to ES3. To highlight aspects specific to certain version, we will explicitly refer to the version ES3 (resp. ES5). Furthermore, Mozilla Firefox 21 partially supports the upcoming ECMAScript 6 (codenamed Harmony). However, as it is not fully standardized, let alone implemented yet, we do not consider it in our paper. Due to the complexity and informality of 4

7 JavaScript, this project aims to design such framework for automated verification of JavaScript program. In our proposal, we aim to verify JavaScript program incrementally. With the many features of JavaScript such as dynamic-typing and higher-order functions, it is difficult to attempt to solve all of them at the same time. As such, our first aim to verify first-order JavaScript language followed by verifying typed annotated JavaScript allowing higher-order functions. Future works would include attempts to combine both solution to verify a wide range of dynamically-typed JavaScript with higher-order functions. Given the road map of the research proposal, this paper will first give a quick tour of JavaScript in Section 2, highlighting the quirks and counter-intuitive aspects of JavaScript as compared to a more established programming language such as C++ and Java. In Section 3, we will discuss Hoare logic up to separation logic with focus on our existing system HIP and SLEEK. Section 4 highlights the current methods to verify many aspects of JavaScript including absence of runtime error, security, and partial functional correctness. This is then followed by discussion on our proposed system in Section 5 and it is concluded in Section 6. 5

8 2 A Tour of JavaScript JavaScript is a dynamically-typed language with syntax similar to C++ and Java. There is only one variable type in JavaScript, var, as shown in Figure 1, where variables x, y, z, and f are assigned to number, string, boolean, and function types respectively. The first three number, string, and boolean are the three primitive datatypes in JavaScript. The last one, function, is a special object type and will be discussed further in Section 2.2. The dynamic-type nature of JavaScript can be seen in line 10 where we overwrite the value of variable y to a value with a type number. Besides the three primitive datatypes, JavaScript has one more type which is object. There are also two special values in JavaScript, namely null and undefined. Variable declarations in JavaScript can be done in two ways. The first is using the var declaration as above and the second not a good way of declaration is to assign a value to a variable not previously declared using var as is shown in line 15. All variables declared using the latter method, such as variable a, will be available globally. Function declarations can be done in two ways as well. method by assigning an anonymous function to a variable. Line 4-9 shows one The function names for anonymous functions are actually optional (i.e. we can declare it as var f = function bar(){...}). However, they cannot be directly referenced using the declared name. As such, anonymous functions, albeit possible to have a name, must be assigned directly to a variable during its declaration. To avoid conflict, function declaration would refer to the first method and function expression would refer to the second method (Crockford, 2008). One of the confusing aspect of JavaScript is the concept of hoisting. Hoisting intuitively means to pull declaration up to the top of the scope it is declared in. However, a scope in JavaScript is only created on declaration of a function. Thus, 6

9 1 var x = 100; // x: number 2 var y = " str "; // y: string 3 var z = true ; // z: boolean 4 var f = function () { 5 if (!x) { 6 var x = 200; 7 } 8 return x; 9 } 10 y = f (); // y: number 11 function foo (y) { 12 if(y) { 13 function f() { return 100; } 14 } 15 a = f (); // a was initially undeclared 16 } Figure 1: Basic JavaScript Example in the function at line 4-9, the variable x is hoisted up to in between line 4 and 5. The entire code in Figure 1 can be rewritten into Figure 2 when we considering hoisting of both variable and function declaration. A few things to note about hoisting is summarized below: 1. Declaration of variable x, y, z, and f are moved to line Declaration of function foo is moved to line Declaration of function f inside foo is moved to the top of function foo. 4. Declaration of variable x inside anonymous function is moved to the top of the anonymous function. 5. Anonymous function declaration (i.e. function expression) is not moved up. 6. Variable a is never declared, only assigned when function foo is called. Looking at Figure 1, it is not so obvious to see that assignment to y at line 10 will always yield 200. However, after hoisting, it is clearer to see that at line 13 of Figure 2, the value of x is undefined. In JavaScript, the value undefined will be coerced into false, and hence, the if-condition will always be true. We will delve further into scoping in Section 2.2 when we discuss about function and finish the 7

10 1 // Hoisting of Variable and Function Declaration 2 var x, y, z, f; 3 function foo (y) { 4 function f() { return 100; } // Internal hoisting 5 if(y) { } 6 a = f (); // a was initially undeclared 7 } 8 9 x = 100; // x: number 10 y = " str "; // y: string 11 z = true ; // z: boolean 12 f = function () { // Anonymous function is not hoisted 13 var x; // Initialized to undefined 14 if (! x) { // undefined evaluated to false 15 x = 200; 16 } 17 return x; 18 } 19 y = f (); // y: number Figure 2: Basic JavaScript Example with Hoisting discussion in Section 2.4 when we discuss about scope-chain. Type coercion will be discussed in Section 2.1 when we discuss about object type in JavaScript. This highlights the difference between the two methods of variable declarations. Using the first method (i.e. using var keyword), value lookup on the variable before the assignment to the variable will return undefined. However, using the second method (i.e. assignment to initially undeclared variable), value lookup on the variable before the assignment to the variable will result in runtime error. Therefore, any lookup for variable a before the function foo is called will cause runtime error of the JavaScript program at that position. Similarly, any call to f() before line 12 will result in a runtime error as function expression is not hoisted. While hoisting might look straightforward, there are differences in the implementation for different web-browser. The hoisting in Figure 2 is hoisting happening in Google Chrome 27 and Internet Explorer 9 1. In Firefox, function hoisting will 1 For simplicity, in this paper, Chrome refers to Google Chrome 27, IE refers to Internet Explorer 9, and Firefox refers to Mozilla Firefox 21. All codes and results are tested in these three major 8

11 pull function declaration to the top of the block instead of the top of the scope. As such, the code for function foo remains the same in Firefox (i.e. function f inside the if-block). This differences leads to different result when foo is called. In Chrome and IE, the result of calling foo will be to always assign 100 to variable a, regardless of the argument passed to foo (i.e. foo(false), foo(true), foo(), etc). In Firefox, when the argument to foo is evaluated to false, 200 is assigned to a as per discussion of the anonymous function, and 100 will be assigned to a when the argument is evaluated to true (i.e. foo(true) 100 and foo(false) ). This behavior is standard on name conflict where we choose the bindings in the nearest scope (in this case, the function f from function declaration as opposed to variable f which is a function from function expression). It is possible that Firefox differentiates the hoisting principle as it partially supports ECMAScript 6. In ECMAScript 6, one of the proposed changes is to add a local variable declaration using let syntax. The variable declared using let is local to the block as would be expected in other programming languages such as C++ and Java. This block-level scoping might also be used by Firefox for hoisting of function declarations. As ECMAScript 6 is not yet standardized, we do not discuss it further. It is suffice, for now, to differentiate the hoisting principle in our source-to-source translation by using a tag during the translation to indicate the web-browser it is going to be verified against. The source-to-source translation procedure will be discussed further in Section JavaScript Objects In class-based language such as C++ or Java, classes act as templates for the creation of objects. JavaScript unifies classes and functions into functions. As a first-class web-browsers. 2 We use to refer to the reflexive and transitive closure of. It intuitively means that an expression, evaluated in the given program state, will eventually yield the value given on the right-hand side of 9

12 1 function Point2D (x, y) { // Function as a Class 2 this.x = x; 3 this.y = y; 4 } 5 var p1 = new Point2D (1,2); // Object using Function 6 var p2 = {x: 3, y: 4}; // Object Creation Syntax 7 8 p2.z; // Returns undefined 9 p2. z = 5; // Create z in p2 10 delete p2. x; // Field x is removed from p2 11 p2.x.a; // Error 12 p2["y"]; // Returns 4; Figure 3: Example JavaScript Object Creation object, function is also treated like an object. In Figure 3, Point2D acts as a template for creating the object referenced by variable p1 at line 5. Without the new keyword at line 5, Point2D would have been called as a normal function which returns nothing, i.e. undefined. A mutable field constructor will be added to the prototype of Point2D function object. prototype is different from proto and it will be discussed in 2.3. We also elide the discussion on this keyword until Section 2.2 but it suffices to say that after line 5 is executed, variable p1 would have the field x = 1 and y = 2 3. Another way to create an object is directly using the object creation syntax at line 6. The syntax is {fn 1 : fv 1, fn 2 : fv 2,...} where fn i is the i th field name and fv i is i th field value. Field names are string and field values are values which include the two special values (null and undefined). Values can also be function expression which serve to add function into the object. Thus, object can be seen as a mapping from strings to values similar to hashmaps in Java or dictionaries in Python (Lutz, 2001). In JavaScript, fields can be added and removed dynamically. JavaScript is closer to object-based language (Abadi and Cardelli, 1995; Fisher and Mitchell, 1995) than 3 In JavaScript, they are called property instead of field, but we abuse the notation to conform to the notation used in object-oriented paradigm. 10

13 1 var p = {a:1, b: undefined, c: null }; // proto_ of o 2 var o = {x:2, y: undefined, z:null, proto :p}; 3 o. hasownproperty ("w"); // false 4 o. hasownproperty ("x"); // true 5 o. hasownproperty ("y"); // true 6 o. hasownproperty ("z"); // true 7 o. hasownproperty ("a"); // false (b & c naturally false ) 8 9 "w" in o; // false 10 "x" in o; "y" in o; "z" in o; // true 11 "a" in o; "b" in o; "c" in o; // true 12 "d" in o; // false typeof o.x!== " undefined " && o.z!== " undefined ";// true 15 typeof o.y!== " undefined "; // false 16 typeof o.a!== " undefined " && o.c!== " undefined ";// true 17 typeof o.b!== " undefined "; // false Figure 4: Checking for Field in JavaScript class-based language (Bono et al., 1999a; Bono et al., 1999b). Line 9 shows the addition of field z into object referenced by variable p2. The same mechanism is at play in the definition of function Point2D where the field x and y is added dynamically to the variable this. Thus, function only serves as a loose template for objects in JavaScript. Field removal is done using the operator delete at line 10. It only deletes the field in the object, not fields inherited from the prototype. In addition, field-lookup to non-existent field will return undefined instead of error. However, field-lookup from null or undefined yields a runtime error as shown at line 11. An interesting aspect from the safety perspective regarding the dynamic addition and removal of field is to check if an object has a certain field. JavaScript provides a function and an operator to check if a field has been added to an object regardless of a value. The function is hasownproperty and it is inherited through Object.prototype. The operator is the binary operator in. A simple usage can be seen in Figure 4. The difference between hasownproperty function and in operator 11

14 is that the former checks only in the direct field without checking if the field is present in the proto -chain which is done by the latter. In our example in Figure 4, object referenced by p is the proto of the object referenced by o. To put is simply, o inherit the fields a, b, and c from p. Line 3-7 shows that hasownproperty function only returns true if the field is directly in the object referenced by o. As such, w return false because it doesn t exist in either o or p, while a, b, and c return false because it is in p but not in o. In comparison, in operator returns true for a, b, and c because it is in p. Using those two methods, it is irrelevant that the values are undefined or null, as long as the field is a field of the object, the operations return true. A more naïve method of checking for presence of field is checking if the field is undefined. Note that the value of undefined is a string (i.e. with quotes) as undefined is not a protected keyword and a variable with the same name can be declared (e.g. var undefined = 2; is legal). Line is a verbose version of checking for undefined using the typeof operator. Note that if the field is presence but has a value of undefined such as o.y and o.b, the result is false whereas the previous two methods shows true. As objects are mapping from string to values, field-lookup on an object would require the field name to be coerced into a string. In fact, given an object obj and a field name fn, obj.fn is equivalent to obj[fn], and vice versa. As such, line 12 is the same as p2.y. Additionally, it is required that the field name fn can be coerced into a string. This requirement yields an interesting result on arrays. JavaScript arrays is just another object which contains a special field called length. In Figure 5, there are two ways to create an array. The first way is through a function called Array (line 1) and the second is using array creation syntax (line 2). Array in JavaScript is a heterogeneous collection of values. Line 6 and 7 shows that we can insert values of arbitrary types into the array. This is similar to array of objects in Java (i.e. Object arr = new Object[size];). Another similarity is 12

15 1 var ar1 = new Array (1, 2); // ar1 = [1, 2] 2 ar1. push (3); // ar1 = [1, 2, 3] 3 ar1. pop (); // ar1 = [2, 3] 4 5 var ar2 = ["x","y","z"]; // ar2 = [x, y, z] 6 ar2 ["1"] = 2; // ar2 = [x, 2, z] 7 ar2 [4] = true ; // ar2 = [x, 2, z, null, true ] 8 ar2. length = "a"; // Error 9 10 var arr = [[1,2],[3,4,5]]; // arr = [[1,2],[3,4,5]] 11 var arr_obj = [{x:2,y :3}]; // array of object var obj = {"0": "x"}; // obj = {"0": "x "}; 14 obj ["3"] = "y"; // obj = {"0": "x", "3": "y"} 15 obj. length = "a"; // obj = {..., " length ": "a"} Figure 5: Example JavaScript Array Creation the index for arrays in JavaScript begins at 0. Thus, ar2["1"] at line 6 refers to the second element in the array ar2. Furthermore, insertion into array at index greater than the length would create holes that is filled with null values. We can also create multi-dimensional arrays by making array of arrays as in line 10 and create array of objects as in line 11. The core JavaScript language has a primitive support for arrays and would ensure that the field length is an integer. An assignment to the field length that is not an integer would cause a runtime error as shown in line 8. This primitive support is more apparent if we look at the code at line Line 13 shows an object obj created using object creation syntax with field "0" assigned to x. While this can be thought of as similar to an array with a single value x at index 0, line 14 shows that assignment to field "3" does not create holes as opposed to if we work with array. In addition, assignment of field length with non-integer at line 15 does not result in error but addition of the field into the object. An important aspect of array is the type coercion to string type. In a similar way that array can be declared using the function Array, JavaScript provides functions to create objects of Number, String, and Boolean. However, a different behavior is 13

16 1 var x = 1; // typeof x === " number " 2 var y = "a"; // typeof y === " string " 3 var z = false ; // typeof z === " boolean " 4 function f() {... } // typeof f === " function " 5 var a; // typeof a === " undefined " 6 var o = null ; // typeof o === " object " 7 8 var ox = new Number (1); // typeof ox === " object " 9 var oy = new String ("a"); // typeof oy === " object " 10 var oz = new Boolean ( false ); // typeof oz === " object " var xx = Number (1); // typeof xx === " number " 13 var yy = String ("a"); // typeof yy === " string " 14 var zz = Boolean ( false ); // typeof zz === " boolean " Figure 6: Primitive Datatype and Object observed when we create object this way. For instance, a call new Number(10) will return an object instead of the primitive datatype. The runtime type can be naïvely checked using the typeof operator 4. Figure 6 shows the important result of typeof operator. Notice that line 8-10 shows "object" as the return value but that line returns the respective primitive datatype. A dynamically-typed language such as JavaScript often offer powerful type conversion but in this case, it might cause confusion on the programmer. +, *, ==, and!= 5 operators perform implicit type conversion, among other operators, and + operators is both numeric addition and string concatenation. Type coercion for + is specified in an 8-steps algorithm, * is specified in a 7-steps algorithm, == and!= are specified in a 22-steps algorithm. These specifications can be found in Section , Section 11.5, and Section of (E.C.M.A.International, 2011) respectively. Important in the type conversion is the value of false. Values that are treated as false are often called falsey (Wyke-Smith, 2009), and they include undefined, null, 0, "" (empty string), false, and NaN (not a number, which may be obtained from addition with undefined value). The rest of the values are treated 4 The === operator is similar to == equality operator but without type conversion. 5!== is the version of!= without type conversion. 14

17 as true and called truthy. To add to the complexity, these algorithms refer to three pages of pseudofunctions GetValue, ToPrimitive, and Type with additional two primitive type conversion functions ToNumber and ToString 6 hidden in the details of the algorithm. ToPrimitive pseudo-function is a function that convert the object to number, usually via valueof function, or to string, usually via tostring function, when valueof function is unavailable. Note that there is no real guarantee that the return value of either function be the correct type (number and string respectively) as JavaScript is dynamically-typed language. As such, the algorithm for ToPrimitive can be seen as calling valueof if it is available or calling tostring if valueof is unavailable. In the usual cases, tostring is always available and inherited from a special object called Object.prototype. However, as functions are mutable, they can be overwritten and if neither valueof nor tostring are available, it will cause runtime error. To illustrate the complexity of type coercion, we show the representative examples in Figure 7. Line 1-3 shows type coercion from object to number since Number has the function valueof defined. Line 5-7 shows type coercion from number to string, both primitive datatypes, using the primitive type coercion function ToString. Line 9-15 elaborates on the order of functions being called during conversion to primitive datatypes in ToPrimitive pseudo-function. Line is forcing the field n to a number by using the primitive multiplication operation which coerce n to number. Line is forcing the field n to string. In the example at line 18, the result is a number 4, showing that valueof is called before tostring. Removal of line will yield 22 as the result. Line 19 and 20 shows the difference between having type coercion in equality operator. Line shows type coercion from string to number. Lastly, line shows type coercion from array to either 6 To differentiate between the function written in the specification and the function available in JavaScript library, we will use bold typeface to represent function written in the specification and monospace typeface for function in JavaScript library. 15

18 number or boolean. The type coercion mechanism discussed above give rise to an unconventional example at line 28 which evaluates to a string fail 7. In JavaScript, primitive datatype is immutable. Field addition to primitive datatype will be dropped as shown at line Anderson (Anderson, 2006) explained the behavior as converting the variable x to object, assign the field a to the object, and assign the newly created object to a ghost variable. In a sense, the object exists but unreachable. Although the behavior is identical to dropping the operation, the logic depends on knowing the exact type of x which, considering the dynamic-type nature of JavaScript, is generally intractable, if not undecidable. There also exists conversion from primitive datatype to object as shown in line y is an object representing the boolean value false. However, object is a truthy value in JavaScript and evaluation of it in line 36 leads to line 37 being executed. 2.2 JavaScript Functions As stated before, JavaScript treated function as first-class object. Function can be assign to a variable, returned as a return value, or passed as an argument to another function. In short, function is just another object in JavaScript, albeit a special one. Function contains an internal field code which represent the body of the function, and scope which represent the lexical scope of the code. Note that, unlike proto 9, these internal fields of function are not accessible to programmer. In addition, similar to field-lookup, invoking a non-function object causes a runtime error in JavaScript execution. We will use and extend function Point2D from Figure 3 as our example in Figure 8. A new lexical scoping is created when function is declared using either function declaration or function expression. Nested function such as the function Length 7 Example is taken from 8 The expression y = Boolean(x); does not convert the primitive boolean to object. Instead, y remains as boolean 9 proto is not accessible in the JavaScript standard in (E.C.M.A.International, 2011) but major modern web-browser such as Firefox, Chrome, and IE supports explicitly accessing this field. 16

19 1 x = 1; 2 y = new Number (2); // Has valueof function 3 result = x + y; // result = x = 1; 6 y = "a"; 7 result = x + y; // result = "1a" 8 9 function MyNumber ( n) { 10 this.n = n; 11 this. valueof = 12 function () { return n *1; }; // Force to number 13 this. tostring = 14 function () { return ""+n; }; // Convert to string 15 } 16 x = new MyNumber (2); 17 y = 2; 18 result = x + y; // result = 4 19 result = x == y; // result = true 20 result = x === y; // result = false x = "1"; 23 y = 2; 24 result = x * y; // result = result = +[]; // result = 0 27 result =![]; // result = false 28 result = (![]+[])[+[]]+(![]+[])[+!+[]]+([![]]+[][[]]) 29 [+!+[]+[+[]]]+(![]+[])[!+[]+!+[]] 30 // result = " fail " x = false ; 33 x.a = 1; // Dropped 34 x.a; // x.a: undefined ( error in Firefox ) 35 y = new Boolean (x); // y: object 36 if(y) { 37 alert ("y is true?"); // This will be executed 38 } Figure 7: Type Coercion Example 17

20 creates a new scope which is nested in the scope of Point2D. This scope-chain is also called execution context. As execution context forms a linear list that is added in front when entering a function (or entering a with-block) and removed from the front when exiting a function (or exiting a with-block), it is similar to call stack in other programming languages. Thus, we can refer to both myx and myy in Length but we can t refer to length in Point2D. Similarly, we can t refer directly to Length from outside the function Point2D. Thus, we need to give access to these using assignment to this object which is passed implicitly depending on the caller. Since declaring a function creates a new scope, and nested functions create nested scopes, a variable lookup will go through chain of scopes called a scope-chain. Ignoring with-statement, this scope-chain can be resolved statically in a lexical manner. with-statement break this lexical scoping by allowing a direct manipulation of scope-chain by prepending an arbitrary object into the scope-chain. Thus, it is preferable to recover the lexical scoping by source translation mechanism as there are many tools available only works in a lexically scope subset of JavaScript (Anderson et al., 2005; Crockford, 2011; FacebookTeam, 2013; Guha et al., 2009; Heidegger and Thiemann, 2009; Miller et al., 2008). Although with-statements allow prepending arbitrary object into the scopechain, scope object is unlike normal object. The difference between scope object and normal object is in the proto field. Normal scope object neither has proto field nor does it allow addition of proto field. An exception is the global scope which, in many web-browsers, is represented as a special object called window which has a proto field pointing to Object.prototype. This scope-chain resolution will be discussed in Section 2.4. Similar to C++ and Java, JavaScript employs this keyword to refer to the current object. Since JavaScript s function is a first-class object, this variable is bound to the object invoking the function, or window object if the function is called without an object a la static method in Java, regardless of where the function is 18

21 1 function Point2D (x, y) { 2 // Internal variable ( inaccessible ) 3 var myx = x; 4 var myy = y; 5 6 // Internal function ( inaccessible ) 7 function Length () { 8 var length = 0; 9 if(myx > myy ) { 10 length = myx - myy ; 11 } else { 12 length = myy - myx ; 13 } 14 return length ; 15 } // Accessible fields 18 this.x = myx ; 19 this.y = myy ; 20 this. l = Length ; 21 } var p1 = new Point2D (1,2); 24 var p2 = new Point2D (5,1); // Another definition to count length 27 function ThisLength () { 28 var length = 0; 29 if( this.x > this.y) { 30 length = this.x - this.y; 31 } else { 32 length = this.y - this.x; 33 } 34 return length ; 35 } p2. l = ThisLength ; 38 p1.l (); // Returns 1 39 p2.l (); // Returns 4 40 ThisLength (); // Returns NaN Figure 8: JavaScript Function Example 19

22 declared. Function declaration and function expression only determines the scope of the function while the context of the function call is determined by how the function is invoked. This is apparent in the example where, at line 37, we replace the function referenced by l originally invoking the function Length by the newly created function ThisLength. Depending on the way l is invoked, the behavior differs. At line 39, we invoke l with the context set to be p2 (i.e. this variable refers to p2). Therefore, this.x (similarly, this.y refers to the accessible field of Point2D which is the value of x = 5 on input (similarly, y = 1 on input). Hence, the return value of 4. At line 40, the context is window which contains neither x nor y. Thus, the return value is NaN as both values are undefined. The subtlety of the context of execution of a function comes when we consider the prototypical inheritance pattern in JavaScript. The next Section is dedicated to discussion on JavaScript prototype. Another subtlety of JavaScript function invocation is that there is no checking for the number of arguments passed. Taking an example from Figure 9, we can invoke SimpleSum with as many variable as we want. Unlike in Java or C++, there is no function overloading. The behavior is more closely related to default argument in C, except in JavaScript, we couldn t specify the default value directly in parameters. Line 29 shows that when we specify more arguments than what is expected, it will still be accepted, albeit without the direct variable name to access it. JavaScript provides an implicit arguments aptly called arguments which is an array of arguments passed during function invocation. This arguments array allows for access to parameters that might be shadowed by another parameter such as shown in the function WrongSum. In WrongSum, the parameters a is duplicated and only the right-most parameter is directly accessible. The previous a, however, is still accessible through arguments[0]. Hence, the result at line 36 is 5. Lastly, function contains a field representing the number of formal parameters they are expecting. This special field is immutable as shown by line 38 20

23 1 // Accessing the Parameters Directly by Name 2 function SimpleSum (a,b, c) { 3 var _a = a 0, 4 _b = b 0, 5 _c = c 0; 6 return _a + _b + _c; 7 } 8 9 // Accessing the Parameters through Implicit Parameters 10 // called arguments 11 function ComplexSum (a,b, c) { 12 var sum = 0; 13 for ( var i =0; i< arguments. length ; i ++) { 14 sum += arguments [i]; 15 } 16 return sum ; 17 } // Duplicated Parameters 20 function WrongSum (a,a, c) { 21 return a + c; 22 } SimpleSum (); // Returns 0 25 SimpleSum (1); // Returns 1 26 SimpleSum (1,2); // Returns 3 27 SimpleSum (1,2,3); // Returns 6 28 SimpleSum (1,2,3,4); // Returns ComplexSum (); // Returns 0 31 ComplexSum (1); // Returns 1 32 ComplexSum (1,2); // Returns 3 33 ComplexSum (1,2,3); // Returns 6 34 ComplexSum (1,2,3,4); // Returns WrongSum (1,2,3); // Returns 5 37 WrongSum. length ; // Returns 3 38 WrongSum. length = 4; 39 WrongSum. length ; // Returns 3 ( no effect ) 40 /* WrongSum (1,2,3,4): has arguments. length = 4 41 but WrongSum. length is still 3 */ Figure 9: JavaScript Function Parameters 21

24 1 function average ( arr ) { 2 var sum = 0; 3 ( function (a) { 4 for ( var i =0; i<a. length ; i ++) { 5 sum += a[i]; 6 } 7 )( arr ); 8 return sum / arr. length ; 9 } Figure 10: Immediately Invoked Function Expression and 39 that assignment to WrongSum.length has no effect. The field length only corresponds to the declared formal parameters expected and does not reflect the actual number of arguments passed. Hence, invoking WrongSum(1,2,3,4) will have arguments.length 4 when queried inside the function but WrongSum.length 3. Lastly, given that the scope is created on declaration of new function, to avoid name conflict while maintaining readability, programmers have devised a clever tactic called immediately invoked function expression (IIFE). In essence, it is a function declaration followed by function invocation in a single expression. The expression is generalized to be as follows: (function (args ) {... })(args ). An example is given in Figure 10 which uses IIFE to loop through an array without polluting the scope with new variable names. 2.3 Prototype-Based Inheritance Figure 3 shows two example of object creation in JavaScript. The reproduced code, with addition, is shown in Figure 11. We will now describe the difference between them, the proto -chain. In the first method, using function as a class, there is an implicit creation of prototype field of Point2D function object. The prototype field of any function object is an object in JavaScript that has its own proto set to Object.prototype. When p1 is created using the new operator, it has its 22

25 1 function Point2D (x, y) { // Function as a Class 2 this.x = x; 3 this.y = y; 4 } 5 var p1 = new Point2D (1,2); // Object using Function 6 var p2 = {x: 3, y: 4}; // Object Creation Syntax 7 var p3 = new Point2D (5,6); // Object using Function 8 9 Point2D. prototype. z = 7; // Add z to Point2D. prototype 10 p2. proto.w = 8; // Add w to Object. prototype 11 p1. z = 9; // Copy - on - Write mechanism p1.z; // Returns 9 14 p2.z; // Returns undefined 15 p3.z; // Returns 7 16 p1.w; // Returns 8 17 p2.w; // Returns 8 Figure 11: JavaScript Prototype Example proto field set to Point2D.prototype object at the point of creation. Thus, if we change the prototype field of Point2D to another object, any object created using new Point2D(, ); syntax will have its proto points to the new prototype. Additionally, the constructor field is added to Point2D.prototype and set to Point2D. On the other hand, using object creation syntax, p2 will have its proto set to Object.prototype directly. A diagram showing the relationship between the objects, proto, prototype, and constructor is shown in Figure 12. In the Figure, {Fields of...} is the rest of the field of the objects, not shown for succinctness. The arrows,,, and, show the hidden prototype, proto, and constructor fields respectively. This convention will be used on later Figures when we show more complicated relationships on objects. Some authors, notably Qin et al. (Qin et al., 2011), mixes prototype and proto probably for simplification of their system. As a simplification, prototype is generally a field of function object. As such, Object is just a function. Class-based language uses inheritance for sharing fields, but as an object-based 23

26 Figure 12: Relationships between Objects on Figure 11 language, JavaScript uses prototype to share fields (Borning, 1986). Delegation is used as a mechanism to implement prototypical inheritance (Lieberman, 1986). In JavaScript, each object can only inherit from a single object (i.e. the prototype). This creates chain of prototypes. Field-lookup (e.g. p2.z) is implemented by searching through the object s own field to see if the field is present (e.g. p2.hasownproperty("z")). If the field is present, return the value, otherwise, delegate the search to the prototype object (e.g. the proto of p2 is Object.prototype). Since proto -chain is ensured to be cyclic-free, there will be a proto without its own proto (i.e. its proto is undefined or null). In such a case, undefined is returned. Line 11 on Figure 11 updates the field z on p1. Notice that p1 doesn t have the field specified; it inherits z from Point2D.prototype. Thus, p1 adds the field z to its own field. This behavior is similar to copy-on-write mechanism. Thus, at line 13, p1.z refers to its own field z with value 9 while at line 15, p3.z refers to the field z of Point2D.prototype with a value 7. Using copy-on-write mechanism allows an 24

27 1 var Point2D = 2 new Function ("x", "y", " this.x=x; this.y=y"); 3 Point2D. z = 1; 4 var Point3D = function (x, y, z) { 5 this.x = x; 6 this.y = y; 7 this.z = z; 8 }; 9 Point3D. proto. default_value = 0; // Declaration of p1, p2, and p3 as before Point2D. default_value ; // Returns 0 Figure 13: JavaScript Function Prototype object to share fields while enabling each object to differ from the prototype without affecting the rest of the objects using the prototype. In addition, notice how the behavior is different from line 10, where we explicitly declare that the field w should be written to the proto, instead of p2. While direct prototype manipulation is not allowed in ECMAScript Language Specification (E.C.M.A.International, 2011), most modern web-browser such as Firefox, Chrome, and IE allows it by giving programmer access to proto field. The only limitation is that proto -chain cannot contain a cycle. Thus, either an object has no proto field or the proto -chain ends in null. As Figure 4 shows, we can set the proto of an object created using object creation syntax and, hence, setting up the proto -chain directly. As mentioned above, a function is just another object, albeit a special one. Thus, it has a proto field too. To explain the prototype inheritance of a function object, we need to introduce a function called Function. This function takes in an arbitrary number of arguments, the last of which represents the body of the function while the remaining is the formal parameter of the function. The behavior of function declaration and function expression is identical to parsing the code and invoking Function accordingly. 25

28 Figure 14: Relationships between Objects on Figure 13 Given the description of Function, we can code the function Point2D like the line 1 of Figure 13. Additionally, since Point2D is an object 10, we can assign a field to it as shown in line 3. As an object, every function has a proto field that points to Function.prototype. This is a special object which is pointed to by the prototype field of Function function object. The design choice of having every proto field of a function object points to Function.prototype has an interesting effect in the initial heap configuration of JavaScript program as shown by the blue boxes in Figure 13. An interesting point to note is that when we add a field to the proto of any function, all other functions has access to this field as shown in Figure 14. Given that functions act as classes in JavaScript, we would expect to relate between an object and its constructor function. However, in JavaScript, this relationship is mutable. Similar to Java, JavaScript has an instanceof operator. The usual way of using instanceof operator is to write it as object instanceof function. The behavior is similar to finding if any object in object s proto - 10 This is true even when we declare the function using function declaration. 26

29 chain is equivalent 11 to the prototype of function. We can write instanceof as a function in JavaScript as follows: 1 function instanceof ( obj, func ) { 2 while ( obj ) { // while obj is not null or undefined 3 if( obj. proto === func. prototype ) { 4 return true ; 5 } else { 6 obj = obj. proto ; 7 } 8 } 9 return false ; 10 } However, the mutability of proto and prototype may cause counter-intuitive result. Figure 15 shows one such example. Point2D and Point3D are as before and we define a new class Point4D. p1 is created at line 5 before we set the prototype of Point2D to prototype of Point3D at line 8 while p3 is created after. As such, p1 has different behavior of instanceof from p3 as shown in line because p2 inherits the old prototype of Point2D while p3 practically inherits prototype of Point3D. As In fact, both p2 and p3 has identical behavior as they have the same proto -chain. Furthermore, the proto field of Point3D.prototype points to Point4D.prototype. Thus, line returns true. 2.4 Scoping in JavaScript As mentioned before, scope object in JavaScript is a special object that does not have proto field except for the global scope window. However, JavaScript allows direct scope manipulation using the with-statement. with-statement prepends an arbitrary object into the scope-chain. We will illustrate this scope-chain and scopechain traversal using the example in Figure 16. In Figure 16, we have two with-blocks, the outer one at line 7-14 and the inner 11 By equivalent, we mean name-equivalent. Although Cardelli et al. (Cardelli et al., 1989) noted that name-equivalence is not entirely a correct term, we use it for its popularity. 27

30 1 function Point2D (x, y) { /*... */ } 2 function Point3D (x, y, z) { /*... */ } 3 function Point4D (x, y, z, w) { /*... */ } 4 5 var p1 = new Point2D (1, 2); 6 var p2 = new Point3D (1, 2, 3); 7 8 Point2D. prototype = Point3D. prototype ; 9 Point3D. prototype. proto = Point4D. prototype ; var p3 = new Point2D (1, 2); /* At this point, the proto chain looks like : 14 p > Point2D. prototype 15 ( original Point2D. prototype ) > Object. prototype 17 p > Point3D. prototype > Point4D. prototype 19 ( through line 9) > Object. prototype 21 p > Point3D. prototype 22 ( modified Point2D. prototype ) > Point4D. prototype 24 ( through line 9) > Object. prototype */ p1 instanceof Point2D ; // false 28 p2 instanceof Point2D ; // true 29 p3 instanceof Point2D ; // true p1 instanceof Point3D ; // false 32 p2 instanceof Point3D ; // true 33 p3 instanceof Point3D ; // true p1 instanceof Point4D ; // false 36 p2 instanceof Point4D ; // true 37 p3 instanceof Point4D ; // true Figure 15: JavaScript instanceof Example 28

31 1 var p1 = {z: 1} 2 var o1 = {x: 2, proto :p1 }; 3 4 var p2 = {w: 3} 5 var w1 = {x: 4, proto : p2 }; 6 7 with (w1) { 8 function foo (o) { 9 var x = 5, y = 6, z = 7; 10 with (o) { 11 return w + x + y + z; 12 } 13 } 14 } foo (o1 ); // Returns w1 = {w: 9}; 18 foo (o1 ); // Returns foo (w1 ); // Returns 27 Figure 16: JavaScript with-statement and Scope-Chain one at line In addition, the function foo is located inside the outer withblock. Normally, the execution context inside foo is just the scope of foo followed by the global scope object window. However, with the addition of with-block enclosing the function, w1 is prepended to the front of this scope-chain. Thus, the scope-chain consists of w1, followed by scope of foo, and lastly, followed by window. Similar reasoning can be used to obtain the scope-chain at line 11, which is o, followed by scope of foo, followed by w1, followed by w1. This depiction is shown in Figure 17. The = represent the next scope in the scope-chain. In this particular instance, we know that variable o in the call to foo refers to the object o1. An interesting effect happens when we update the variable w1 with a new object at line 17. The effect of this update is the same as allocating a new heap memory for {w: 9} and assign w1 the value of the heap address. Thus, w1 at line 5 and 17 contains two different values. The with-statement at line 7 statically determine the value of w1 and assign it as the scope of foo in the internal variable scope. 29

32 Figure 17: Scope-Chain at Line 11 of Figure 16 from Call at Line 16 and 17 Hence, there is no changes in the output of the second call to foo at line 18. The inner with-statement at line 10 also determine statically the variable o. However, it statically determine that it refers to the parameter of foo. This value changes depending on the argument to foo. Hence, when we call foo at line 19 with input argument w1 (at this point, w1 is {w: 9}), the result changes. Given that example, we will now elaborate more on how the scope-chain traversal works. Assume we do a lookup for variable w in the scope-chain at line 11 given the call point of line 16 and 18. The first scope in the chain is the object o1. Since it doesn t contain the field w, we lookup the proto -chain to p1 and again to Object.prototype. As it is not present in Object.prototype and it has no proto field of its own, the lookup on this scope fails and we continue to the next scope in the chain, foo. Since it is not present here either, we continue until we encounter w in the proto object of w1 and we return the value 3. Variable lookup for call point at line 19 is similar except that variable w is immediately present in 30

33 the first scope object. This traversal can be extended to lookup a more complex expression such as w.field. In such a case, the scope-chain traversal is only done to lookup the variable, ignoring the field. Once we found the first occurrence of w, we continue to look for field on w s field and along its proto -chain. Now suppose we add w = 10; in between line 10 and 11. Again, this is assuming the call point at line 16 and 18. Similar to before, the first occurrence of w is at p2. However, since p2 is the proto of w1, and we are writing to w directly instead any of its field, we will add w into w1 s field with the value 10 yielding an object similar to this: w1 = x: 4, y: 8, w: 10, proto : p2. Suppose, instead, we add w.a = 10;, we will add field a to the object w inside p2. However, as mentioned before, since w is a primitive datatype, this field addition is ignored. As an intuition on how a piece of code containing with-statement can be transformed into one without with-statement, and thus, yielding an effectively lexical scoping, notice that the effect of with-statement is to prepend the object in front of the scope-chain so that variable lookup will search in the field of the object first. We can make this explicit by transforming any variable lookup inside the with-block with an if(... in...) {...} else {...} statement. There are conditions to be satisfied during the transformation and it will be discussed in Section 5.1, but the basic idea is the same. 2.5 Higher-Order Functions We have discussed how function is a first-class object in JavaScript: it can be passed in as argument and returned as return value. Closure of function returned is defined in a standard way. This allows higher-order function to be created such as the map function in Figure 18. The difficulty in verifying higher-order function is the lookup on higher-order store for a function. As mentioned before in Section 2.2, invoking a non-function object causes runtime error. As such, we need to verify that f in map is indeed a function at line 12 and 13. Line 16 shows an example of a non-function 31

34 1 function map (f, l) { 2 var r = new Array (); 3 for ( var i =0; i<l. length ; i ++) { 4 r[i] = f(l[i ]); 5 } 6 return r; 7 } 8 var square = function (n) { return n*n; } 9 var cube = function (n) { return n*n*n; } var arr = [1,2,3,4,5]; 12 var sqarr = map ( square, arr ); // [1, 4, 9, 16, 25] 13 var cbarr = map ( cube, arr ); // [1, 8, 27, 64, 125] square = 1; 16 sqarr = map ( square, arr ); // Error Figure 18: JavaScript Higher-Order Map Function object being passed which results in an error. 2.6 eval and Other Meta-Functions Like many dynamic languages before it Lisp (Graham, 1996), Lua (Ierusalimschy et al., 2007), Ruby, Python, etc JavaScript provides method to execute arbitrary string as code at runtime. This method is known as eval. The return value of eval is the result of the last statement executed. Any exception thrown during execution of eval is also propagated to the caller. In practice, eval is widely used in many websites even when they do not actually require them (Richards et al., 2011). Modern JavaScript also provide a limited string evaluation for object in JavaScript called JSON 12. JSON provides two important functions, called JSON.parse to convert a valid string into a JavaScript object and JSON.stringify to convert a JavaScript object into a string representation. A peculiarity of eval is in how it is evaluated. When called directly, eval is evaluated in the local context. However, when invoked indirectly (e.g. through 12 JSON stands for JavaScript Object Notation. 32

35 1 var globaleval = eval ; // Aliasing 2 function f() { 3 globaleval (" function g() { return global ; }"); 4 eval (" function h() { return local ; }"); 5 } 6 7 f (); 8 g (); // Returns " global " 9 h (); // Error var x = 0; 12 function foo () { 13 return x; 14 } 15 function bar1 () { 16 var x = 1; 17 return foo (); 18 } 19 function bar2 () { 20 var x = 2; 21 eval ( String ( foo )); 22 return foo (); 23 } bar1 (); // Returns 0 26 bar2 (); // Returns 2 Figure 19: JavaScript eval Evaluation Context assignment of eval into a variable, or other aliasing method), it is evaluated in the global context. Line 3 and 4 of Figure 19 shows this example of evaluation of eval in global and local context. Line 9 causes runtime error because function h is only created locally at line 4. Another curious example of the use of eval is to simulate dynamic scoping. Since evaluation context of direct call to eval is local, we can evaluate a string representation of a function (line 21). Invoking the eval d function will then simulate this dynamic scoping as shown at line 26. In general, static analysis of eval is extremely difficult. Any sound string solver such as Hampi (Kiezun et al., 2009), Rex (Veanes et al., 2010), Kaluza (Saxena 33

36 et al., 2010), and SUSHI (Fu et al., 2012) would have to take a pessimistic view of the string supplied to eval. In the worst case, the string is supplied by user at runtime. Such is the case of online JavaScript interpreter JSFiddle 13. With the difficulty of verifying eval, it is generally considered to be a bad practice to use eval. To quote Doug Crockford, eval is evil. Beside eval and JSON, JavaScript provides other meta-functions. One such function has been shown before in Figure 13. JavaScript function called Function takes in an arbitrary number of string arguments are construct a function object with the code represented by the last argument. Other functions such as settimeout and setinterval takes in a string as their first argument and an integer as their second. The first argument represents the code to be executed and the second argument represents the time until it is executed (once for settimeout and repeatedly at regular interval for setinterval). In addition, document.write is also considered a meta-function as it is able to write to arbitrary string to web-pages. It is part of specification of Document Object Model (DOM) 14 (Champion et al., 1998; Hors et al., 2000; Hors et al., 2004). Since modern interactive web-pages are often intertwined with inline JavaScript code enclosed in the script tag (i.e. <script> /* JavaScript Code or File */ </script>, document.write is able to write arbitrary code into the web-page. The ability to execute string as code is one of the main vulnerability in modern web-browser. In fact, a popular MySpace 15 worm called Samy (Kankar, 2005) uses eval written in the Cascading Style Sheet (CSS) file 16. This class of code injection attack is called cross-site scripting (XSS) and most modern attack do not use eval altogether. Based on Symantec Internet Security Threat Report DOM represents cross-platform and language-independent convention for representing and interacting with objects in HTML CSS is language used to describe the formatting of a web-document. More information can be found in (Meyer, 2006). 34

37 2013, XSS is the most common scripting vulnerabilities on web-pages (Symantec, 2013). Due to the severity and prevalence of XSS, a large body of research has been dedicated to prevent it statically (Minamide, 2005; Jovanovic et al., 2006a; Jovanovic et al., 2006b), dynamically at runtime (e.g. through tainting, code sanitization, etc) (Huang et al., 2003; Kirda et al., 2009; Louw and Venkatakrishnan, 2009; Saxena et al., 2011; Pieter Hooimeijer and Veanes, 2011), combination of static and dynamic (Huang et al., 2004; Vogt et al., 2007), or by automated attack generation (Martin and Lam, 2008) either on server-side or client-side. 2.7 JavaScript Strict Mode Strict mode provides a number of changes to ES5 that is aimed to be more secure. It has been supported since Mozilla Firefox 4, Internet Explorer 10, and Google Chrome 12. ES5S also converts common mistakes into errors to be easily noticeable by novice developers. Lastly, ES5S make changes that anticipates future ECMAScript evolution. Declaring strict mode is done by indicating a string "use strict"; at the top of the scope where the strict mode is expected. As such, if done at the top of the file (program, or function), the entire file (program, or function) will be checked against the strict mode conditions. As for nested functions, if the outer function has been declared as strict, it will follow. A strict eval can also be performed by starting the string passed into eval with "use strict";. A comprehensive guide to the changes in JavaScript in ES5 is summarized in Figure 20. Some of the restrictions are specific to ES5. Among them is the attribute of field. In ES3, we can only create properties that can be written, enumerated (using for... in loop), and deleted. ES5 allows control of these field property by the use of a special function in Object called defineproperty. The usage is exemplified by the code below that is adding a field x with value 1 to object o that cannot be written or deleted, but is enumerable. 35

38 1 var o = {}; 2 Object. defineproperty (o, "x", { 3 value : 1, 4 writable : false, // Disallow write 5 enumerable : true, // By default, allowed 6 configurable : false // Disallow delete 7 }); 8 9 for ( var fld in o) { 10 /* " x" will be assigned to fld in 11 one of the iteration */ 12 } In addition, ES5 allows freezing of object to prevent further addition of fields to the object. Since by default addition to field of frozen object already causes a runtime error, it is not described in strict mode. Freezing an object can be done using Object.freeze(o); where o is the object to be frozen. Regarding duplication of parameter name in function declaration, as discussed above in Section 2.2, the parameter is not actually inaccessible as it can be accessed using the arguments variable. However, duplicated field name is shadowed and only the latest field name declared is preserved. Lastly, with-statement is forbidden as it breaks lexical scoping. Our proposed source-to-source translator is capable of removing with-statement while theoretically maintaining semantics. Hence, the translator can be used to translate older version of JavaScript code to conform to the ES5S standard. 2.8 Significance of JavaScript JavaScript programs have been widely used to provide rich internet application in the web-browser through AJAX-style 17 client-side capability that dramatically improve user experience through better interactivity. However, many websites readily 17 AJAX stands for Asynchronous JavaScript and XML processing. It captures the art of exchanging data with a server and updates parts of a web-page without reloading the entire page. The connection to server is usually done using a special JavaScript object called XMLHttpRequest object, usually shortened to XHR. 36

39 Element Restriction Rationale arguments delete eval Field Function Keywords Numbers Assignment to arguments variable Deleting a variable, function, or arguments Deleting a field with configurable attribute set to false Assignment to eval variable Variable declared inside eval cannot be used outside Writing to read-only field Adding field to object with extensible attribute set to false Duplicate field name in object Declaration of function inside a statement of block Using future reserved keywords: implements, interface, let, package, private, protected, public, static, yield Assigning octal value to number (octal value are numbers starting with 0 or escaped with \0) Parameter Duplicate parameter name in function this Variable No coercion of this variable to global scope or window object Assignment to undeclared variable Avoid unintended behavior Lexical scoping OOP principle Avoid unintended behavior Encapsulation OOP principle OOP principle Avoid error of mistyping Standardization of hoisting rule among major web-browser Future-proofing Avoid error of mistyping Avoid error of mistyping Isolation of global object Avoid error of mistyping with with-statement is not allowed Lexical scoping Figure 20: ES5S Restriction 37

40 incorporate untrusted third-party JavaScript codes into their web-pages to provide external functionalities such as advertisements, gadgets (used by many websites such as OpenSocial platforms, igoogle, Facebook, and Yahoo! s Application Platform) 18, and social networking aggregations of third-party content (such as Flickr albums, Facebook badges, and Google Map used by Yelp to display restaurant location 19 ). With the JavaScript capabilities to create, read, and erase cookies, as well as to manipulate and navigate DOM pages, JavaScript codes pose significant security risks to the hosting system. One approach to contain the threat is to isolate third party codes by sandboxing the code in iframe. However, this leads to reduced performance and constraints in the interaction between the host system and thirdparty code. In the case of advertisement, the use of iframe will contain the display of advertisement in the specific location of the web-page while it is often desirable for high-valued advertisement to be able to be displayed as pop-up on the page and gain more attention. Another solution is to limit the capability of third-party JavaScript code by providing a sub-language of JavaScript with limited functionality. This approach is used by Google Caja (GoogleCajaTeam, 2013; Miller et al., 2008), ADsafe (Crockford, 2011), and FBJS (FacebookTeam, 2013). However, this solution limits the functionalities of JavaScript, which is generally not applicable for the code deployed by the host. While these sub-languages ease the verification of security property of third-party JavaScript programs, they are found to be vulnerable to attacks (Maffeis et al., 2010). Thus, a more general purpose verification method for JavaScript that can handle not only the sub-languages but the more expressive JavaScript program is desirable. For this approach to work properly, we require a sound and expressive program 18 These gadgets can be found at and respectively. 19 These third-party aggregator can be found at and respectively. 38

41 logic for JavaScript code that could unambiguously capture the underlying intention of each JavaScript program code. We would also need a verification methodology that can formally certify that each installed third-party code meets the safety expectations of the hosting websites. Thus, an expressive program logic and an automated verification methodology are basic ingredients towards supporting the development and deployment of trusted third-party JavaScript programs. 2.9 Semantics of JavaScript David Herman and Cormac Flanagan specified JavaScript using ML in a big-step operational semantics (Herman and Flanagan, 2007). This is then followed by Maffeis et al. in the form of small-step operational semantics of JavaScript in 2008 (Maffeis et al., 2008). The small-step operational semantics has been frequently updated, with the latest revision appearing online on 18 April 2012 (Maffeis et al., 2012). While they provide progress theorem showing that the semantic is sound and heap reachability justifying the mark and sweep garbage collection algorithm used in JavaScript the semantics is large and generally not amenable to conventional verification method. A simplified small-step operational semantic is then proposed by Arjun Guha et al. by transforming JavaScript code to a functional programming language called λ js capturing the core specification of JavaScript except for eval (Guha et al., 2010). Their specification is smaller than that of Maffeis et al. To increase the confidence on the correctness of their code transformation, they test the transformed code with test suites from SpiderMonkey (Firefox), V8 (Chrome), and Rhino. In addition, they show example on how their method can be used to proof properties such as sandboxing. Due to its simplicity, λ js has been adapted and expanded. Lambda sob (λ ob s )) (Politz et al., 2012b) adapt λ js to provide semantics and types for objects simulating JavaScript object (i.e. first-class member names using string). System!D 39

42 (D-ref) (Chugh et al., 2012a) which extends λ js with dependent type. However, System!D transformed from a statically typed dialect of JavaScript they define called Dependent JavaScript (DJS). An automated type checking algorithm is later defined called System D (Chugh et al., 2012b). Dependent type is useful in specifying higher-order functions and dynamic-typing. This idea is then expanded again in JS* (Swamy et al., 2013) that provides refinement to dependent function types using Dijkstra Monad based on predicate transformer (i.e. weakest precondition predicate that can compute the weakest precondition for any postcondition) (Dijkstra, 1975). Lastly, S5 (Politz et al., 2012a) extends λ js to account for the ES5S. In 2012, Gardner et al. provides a big-step operational semantics for JavaScript that captures even non-standard semantics such as proto (Gardner et al., 2012). The proposed operational semantics is geared towards program logic with eval and higher-order functions. Their program logic has been manually verified in Coq (Bertot and Castéran, 2004) to provide a certified interpreter for JavaScript (Bodin and Schmitt, 2013). 40

43 3 Separation Logic In 1969, Sir Charles Antony Richard Hoare developed Hoare logic as a formal logic system for proving properties of programs (Hoare, 1969). The main idea in Hoare logic is to use Hoare triples to provide assertions for the program. Hoare logic is written in a form of {P} C {Q} where P is the program state before the computation C, and Q is the program state after the computation. We call P the precondition and Q the postcondition. The Hoare triples is interpreted as if a program C is run on an initial state satisfying P, then the program will be in a state satisfying Q if the program terminates. In addition, the logic also provides axioms and inference rules to proof valid Hoare triples. Since Hoare triples doesn t proof termination, since it is generally undecidable, we say that Hoare triples proofs partial correctness 20. Edsger Wybe Dijkstra proposed a similar method using weakest precondition transformer that produces the weakest precondition for any postcondition (Dijkstra, 1975). We say that a precondition {P 1 } in {P 1 } C {Q} is weaker than a precondition {P 2 } in {P 2 } C {Q} if {P 1 } {P 2 }. As such, nothing is weaker than true. This is the same weakest precondition predicate transformer used in Dijkstra Monad (Swamy et al., 2013). As will explained later, Hoare logic has been extended to proof correctness of dynamically allocated memory (also called heap allocated memory) using separation logic. In addition, to remedy the strict property of disjointness of memory in separation logic, Aquinas Hobor and Jules Villard has added ramification rule to deal with partial disjointness (or partial sharing) of data in the memory. In our discussion, P, Q, P, P 0, P 1,... represent first-order logic predicates, C, C, C 0, C 1,... represent program code, and h, h, h 0, h 1,... represent heap. A Inference rule is denoted by B where A represents the antecedent, or premise, and B represents the conclusion. It is similar to A B. Consequently, axiom is just an inference rule without antecedents. It can be represented as Axiom. Alternatively, 20 We will refer to partial correctness as correctness in this paper. 41

44 for both axiom and inference rule, the name and/or side-condition can be given at A the side, yielding the following: B Side Condition [Name]. 3.1 From Hoare Logic to Separation Logic Burstall developed a system called distinct non-repeating list system to proof programs which alters data structure (Burstall, 1972). He proposed a new operator & in the assertion. Given an assertion P 1 &... & P n, sharing was only allowed from variables into data fragments in the distinct P i or from one data fragment P i to another distinct data fragment P j. However, this technique is rigid in a sense that it imposes a fixed finite bound on the number of substructures. His technique was an inspiration to O Hearn, Reynolds, and Yang in developing separation logic. Another precursor to separation logic is the logic of bunched implications developed by O Hearn and Pym (O Hearn and Pym, 1999). Lacking in Hoare triples, the breakthrough was made by John Reynolds by adding an independent conjunction, written in the same way as Burstall connectives & (Reynolds, 2000). In his logic, an assertion P & Q is true when both P and Q are true and they depend on distinct areas of storage. Both bunched implications and independent conjunction are specified in intuitionistic logic. Ishtiaq and O Hearn then combine the idea to reworked it in classical logic instead of intuitionistic logic. They also introduces the spatial form of conjunction called separating conjunction together with the adjoint operator, separating implication (Ishtiaq and O Hearn, 2001). Separation is thus born as a logic for local reasoning of program with heap (O Hearn et al., 2001). 3.2 Introduction to Separation Logic As discussed above, separation logic extends Hoare logic with two new connectives, the separating conjunction and separating implication 21. Similar to indepen- 21 Separating implication also goes by the name septraction and magic wand operator. 42

45 dent conjunction, an assertion P Q specifies two distinct memory location where one is satisfied by the assertion P and the other by Q. Separating implication is analogous to implication. An assertion P Q is satisfied by any heap h 0 such that for all heaps h 1 satisfying P, h 0 h 1 satisfies Q. Intuitively, the assertion P Q is satisfied by a heap that satisfies Q with the parts of heap satisfying P removed. A heap refers to dynamically allocated storage. It can be seen as a collection of cells with index ranging in the positive natural numbers. Each of these cells stores a single value. The value can be an integer, or a pointer. The pointer can refer to another cell, or a special value 0. Since index of heap cell range in the positive natural numbers, the value 0 is not associated with any heap cells and thus, can be seen to represent a null pointer. An operator, written x y represents a heap cell indexed by the value x, stores the value y. Multiple values in a single cell is represented as x y and (x + 1) z, or more succinctly, x y, z. Separating conjunction simplifies proof of program by capturing non-aliasing. Given the following imperative code fragment a = 2;, executed in an environment with two variables a and b, Hoare logic gave us the following triplets: {a b } a = 2; {(a 2 b a = b) (a 2 b 2 a b)} where specifies any value. Alternatively, we can specify that a and b are not aliased: {a b a b} a = 2; {a 2 b }. However, the specification for non-aliasing grows exponentially with the number of variables. This problem is remedied by separating conjunction as {a b } specifies that a and b are disjoint. Thus, the exponential explosion of specification is avoided elegantly. Another addition of separation logic is the Frame rule: {P }C{Q} {P R}C{Q R} that allows local reasoning. The semantics of Frame rule in local reasoning can be found in (Yang and O Hearn, 2002). The rule intuitively specifies that given a Hoare triples such that a command C in a state satisfying P, if it terminates, the resulting state will satisfy Q, we can inject the code in a frame, satisfying R without affecting 43

46 the disjoint heap. Thus, the specification can be local, by specifying only the heap or resources used in the computation (e.g the footprint). Using Frame rule, the previous example can be written as {a } a = 2; {a 2} since it only affects a. {a b } a = 2; {a 2 b } can be inferred using the Frame rule. While in standard Hoare logic there is no guarantee about the states not explicitly mentioned in the specifications, separation logic only access the possibly subset of states explicitly mentioned in the specification. Thus, it is a tight interpretation. The states that are accessed are called the footprints while the states that are not accessed are called the residue. Any other predicates specifying precondition and/or postcondition not mentioned in the specifications are not changed by the command. Separation logic has matured to the extent that the logic has been extended to reason about Java object (Parkinson, 2005; Distefano and Parkinson J, 2008), concurrency (Brookes, 2007; Calcagno et al., 2007b; O Hearn, 2007), permission accounting (Bornat et al., 2005), and information hiding (O Hearn et al., 2009). In addition, it has been combined with other reasoning system such as cyclic proof (Brotherston et al., 2008) and rely/guarantee (Vafeiadis and Parkinson, 2007) which is further extended to deny/guarantee (Dodds et al., 2009). Furthermore, supporting tools have been developed to automate reasoning. Most notable of those, shown in chronological order, are Smallfoot (Berdine et al., 2006a), Mutant (Berdine et al., 2006b), Space Invader (Distefano et al., 2006), jstar (Distefano and Parkinson J, 2008), Slayer (Berdine et al., 2011), and HIP/SLEEK (Chin et al., 2011). It is interesting to note that Space Invader has been used to verify up to 10,000 lines of codes in Microsoft and Linux device drivers (Yang et al., 2008). Using bi-abduction method (Calcagno et al., 2011), it is possible to scale to codes with over a million lines of code. However, our main interest is the extension on overlapping memory using the overlapping conjunction operator. Introduced by Gardner et al. in (Gardner et al., 2012) as sepish connectives, overlapping conjunction is prevalent in JavaScript 44

47 Figure 21: Effect of Ramify Rule code for reasoning about shared proto. Interpretation of an assertion P Q is that the heap can be separated into three disjoint heaps, h 0, h 1, and h 2 such that h 0 h 1 satisfies P, and h 1 h 2 satisfies Q where is a disjoint union operator. In short, they have a shared heap, which in the description above is depicted by the heap h 1. In JavaScript, such as shown in Figure 17, Object.prototype is shared by objects if the proto is not modified directly. Due to the centrality of sharing in prototype-based inheritance, taming overlapping conjunction is important in reasoning about JavaScript program. Ramification rule of separation logic is devised to tame sharing using a family of rules called Ramify (Hobor and Villard, 2013). Defining a predicate ramify(p Q, R) = R as R P (Q R ), Ramify rule below. {P}C{Q} ramify(p Q, R) = R {R}C{R } Ramify Taking an example from (Hobor and Villard, 2013), using a directed acyclic graph (DAG) and graph marking algorithm, we can visualize the ramif y predicate as in Figure 21. In the Figure, dag(r, δ) is a directed acyclic graph with the root node r. δ represents the nodes on the entire graph. Thus, both dag(l, δ) and dag(r, δ) have 45

48 the same set of nodes. The predicate m(δ, l) represents a set of nodes such that the set of nodes in δ reachable from l has been marked, i.e. the DAG after the recursive call to mark(l) where l is the left-child of the current DAG. Let P = dag(l, δ), Q = dag(l, m(δ, l)), R = dag(l, δ) dag(r, δ), R = dag(l, m(δ, l)) dag(r, m(δ, l)), and F = dag(r, δ). In addition, we let C = mark(l); such that {P } mark(l); {Q}. 3.3 HIP/SLEEK HIP and SLEEK are systems to automatically verify functional correctness of heapmanipulating programs. HIP system is a automated verifier for separation logic for simple imperative language that is able to modularly verify the specification of heap-manipulating programs. The output of HIP is a set of separation logic proof obligations in the form of formula implications which are sent to the SLEEK separation logic solver. SLEEK is a fully automatic entailment prover for separation logic with capability for inferring frame. The underlying system is based on (Nguyen et al., 2007). The input to SLEEK are two separation formulae representing the heap states before (i.e. antecedent) and after (i.e. consequent) the operation. It then checks if the antecedent entails the consequent by converting the separation formulae into pure formulae (i.e. formulae with separation logic operator) and solve it in provers such as Z3 (De Moura and Bjørner, 2008), Mona, Omega, Isabell, Coq (Bertot and Castéran, 2004), and CVC Lite (Barrett and Berezin, 2004). The core imperative language is given in Figure 22. The first 5 lines defines the grammar for the imperative language, a standard simple imperative language with loop and branch. The rest defines the grammar for the specification language. In HIP and SLEEK, the burden of specifying the program is pushed to the developer (i.e. it does not infer specification 22 ). Some extensions to the HIP and SLEEK that are currently available are multiple 22 Partial inference (i.e. automatic refinement of partial specification) is currently supported based on (Qin et al., 2011). 46

49 P ::= tdecl meth tdecl ::= datat viewt datat ::= data c{field } field ::= t v t ::= c τ τ ::= int bool float void viewt ::= view C v Φ inv π 0 meth ::= t mn ((t v) ) where (Φ pr Φ po ) {e} e ::= null k τ v v.f v := e v 1.f := v 2 new c(v ) e 1 ; e 2 t v; e mn(v ) if v then e 1 else e 2 while v where (Φ pr Φ po ) {e} Φ ::= ( v κ π) π ::= γ φ γ ::= v 1 = v 2 v = null v 1 v 2 v null γ 1 γ 2 κ ::= emp v :: C v κ 1 κ 2 ::= Φ 1 2 π 1 2 v φ ::= ϕ b a φ 1 φ 2 φ 1 φ 2 φ v φ v φ b ::= true false v b 1 = b 2 a ::= s 1 = s 2 s 1 s 2 s ::= k int v k int s s 1 + s 2 s max(s 1, s 2 ) min(s 1, s 2 ) ϕ ::= v B B 1 = B 2 B 1 B 2 v B φ v B φ B ::= B 1 B 2 B 1 B 2 B 1 B 2 {} {v} Figure 22: Core Imperative Language specifications (Chin et al., 2007), structured specification (Gherghina et al., 2011), user-defined predicates (Chin et al., 2012), specification for exceptions (Gherghina and David, 2010), native barrier verification (Hobor and Gherghina, 2011), immutability specifications (David and Chin, 2011), fractional permission (Le et al., 2012c), termination analysis (Le et al., 2012b), variable permission (Le et al., 2012a), error calculus (Le et al., 2013). There are also concurrent works on overlapping conjunction (Sharma et al., 2013a) and compatible sharing (Sharma et al., 2013b). 47

50 4 Current Verification Methods 4.1 Static Type-Checking In general, static type-checking is an analysis of program code to verify that a program will not have type errors (e.g. calling a function type instead of primitive type, passing the correct type as an argument, or verifying that the field accessed is present in the object). A well-typed program is ensured not to have type errors when it runs. In JavaScript, the runtime errors are generally calling a non-function type and accessing a field from null or undefined values (accessing a non-existent field returns undefined instead of error (E.C.M.A.International, 2011)). The dynamically-typed nature of JavaScript means that there will be no mismatch between the type expected in a function parameters to the arguments passed during function call. Jensen et al. (Jensen et al., 2009) identified nine conditions they classified as JavaScript type errors: 1. Invoking a non-function (e.g. number). 2. Reading an absent variable. 3. Accessing a property of null or undefined. 4. Reading an absent property of an object. 5. Writing to a variables or object properties that are never read. 6. Implicit conversion of primitive to object. 7. Implicit conversion of undefined to a number yielding NaN. 8. Calling a function object both as a function and as a constructor. 9. Calling a built-in functions with an invalid number of parameters. However, it is important to note that only conditions 1 and 3 causes an actual runtime error in JavaScript. The remaining can be considered to be warnings that are beneficial for programmers. The dynamic-type nature of JavaScript limits the capability of static typechecker. The various type systems proposed for JavaScript are accompanied by 48

51 the semantics for a small subset of JavaScript instead of the entire language. For example, JS 0 (Anderson et al., 2005; Anderson and Giannini, 2005; Anderson, 2006) is a type system from Anderson et al. that excludes prototypes and first-class functions, Recency types (Heidegger and Thiemann, 2009; Heidegger and Thiemann, 2010) that admits prototypes and first-class but excludes assignment. Static type-check of first-class functions, and hence, higher-order functions, are proposed independently by Chugh et al. using Duck Typing and by Swamy et al. using Dijkstra Monad. Both static type-checker uses dependent types with built-in McCarthy s theory of finite map (McCarthy, 1962). Chugh et al. first proposed an explicitly typed JavaScript called Dependent JavaScript (Chugh et al., 2012a), which they then proposed the type inference algorithm using nested refinement of dependent type (Chugh et al., 2012b). The main insight in their paper is using refinement logic of the form T ype ::= {v p} where v is a value and p is a predicate that depends on the value v. In addition, they have a predicate has-type using :: binary uninterpreted predicate. As such, they can represent function apply(x,f) { return f(x); } as apply :: Int {v v :: Int Int} Int, assuming x is an integer, and f is a function accepting integer and returning another integer. It roughly translates as follows: apply is a function accepting two parameter: an integer and a function that has-type Int Int, and returning an integer. Furthermore, using McCarthy s theory of finite map, they can represent an object as a dictionary by tagging the constructor of the object to Dict. Hence, an object var o = a: 1, f: apply; has a type of o :: v tag(v) = Dict sel(v, a) : Int sel(v, f) :: Int {v v :: Int Int} Int 23. A similar technique of tagging is used by Swamy et al. in their dependent type version of Dijkstra Monad. Dijkstra Monad is developed to alleviate the problem of Hoare Monad (Nanevski et al., 2008). While State Monad is of a type heap (a heap) i.e. given a heap, it returns both the return value a and the 23 sel(v, a) : Int can also be written as tag(sel(v, a)) = Int to be more explicit. 49

52 changed heap, which expresses stateful computation Hoare Monad has addition of pre and postcondition. Hoare Monad is of a type h : heap{pre h} {x : a h : heap{post x h }} where h : heap{pre h} is a heap that satisfies the predicate pre h. This is reminiscence of refinement logic used by Chugh et al. above. The problem with Hoare Monad is that combining two operations requires the postcondition of the first operation to match the precondition of the second operation. However, using Dijkstra Monad, taking clue from Dijkstra predicate transformer (Dijkstra, 1975) that computes the weakest precondition from any postcondition, we have a type p h : heap{wp p h} {x : a h : heap{p x h }}. That is, we can compute the weakest precondition using the given predicate transformer wp computed for any predicate (e.g. postcondition p) and a heap h using wp p h. Combining computation is now computed by composing the computation of the weakest precondition of each component. This type-checking is inherently a backward analysis as to ensure safety, we know a postcondition to be satisfied (e.g. invoking a function requires the invoked object to be a function object). 4.2 Axiomatic Verification Another static verification method of JavaScript is using axiomatic verification method (Qin et al., 2011). Their system uses a restricted dialect of JavaScript they called JS sl which captured prototypical inheritance, functions as an object, and dynamic field addition through assignment. Their work might be the first step towards a fully automated simple verification for JavaScript. However, their model is too simplistic for general purpose JavaScript and in some part, doesn t conform to the standard ECMAScript. Firstly, their model doesn t allow first-class function. Furthermore, they confuses the treatment of proto and prototype 24. In fact, they didn t differentiate the two. It should be noted, 24 In their paper, they use the It is more analogous to proto as they for field lookup. 50

53 1 Function. prototype. x = 2; 2 Object. prototype. x = 3; 3 4 var o = {}; 5 function f() {} 6 7 o.x; // Returns 3 8 f.x; // Returns 2 Figure 23: Function.prototype vs Object.prototype however, that those two fields are different as stated in Section 2. Lastly, they simplify the representation of proto such that every function objects has the proto field refer to Object.prototype instead of Function.prototype. While they claim that the simplification makes no harm to the semantics, it is easy to construct an example where it is as shown in Figure 23. The difference in the return value can be visualized by the diagram in Figure 24. The code at line 1 adds the field x at Function.prototype which is the proto inherited by all function objects. On the other hand, the code at line 2 adds the field x at Object.prototype which is the proto inherited by all objects, including Function.prototype. Hence, o.x 3 while f.x 2. It is worth noting that without the code at line 1, both will return 3. Despite the limitation, their work is the first step towards verification of JavaScript using Hoare logic. Recently, another tools using Hoare logic is proposed with the name JuS (JavaScript under Scrutiny) by Gardner and Smith (Gardner and Smith, 2013). While JuS follows closely the program logic for JavaScript proposed in (Gardner et al., 2012), their examples are handpicked and consists of a maximum of 13 lines of codes. In addition, the specification required is large in comparison to the number of lines of codes with some cases, it takes up over 40% of the number of lines. Their tool is present online at It is possible that the problems faced by both tools are in the sharing of variables. While it is true that objects in JavaScript tends to share the Object.prototype 51

54 Figure 24: Diagram Explaining the Behavior shown in Figure 23 unless the proto field is manually set directly or indirectly, it does not mean that the specification requires the use of connector. Take for example, two objects described as follows: var o1 = {a:1}; var o2 = {a:2}; Object.prototype.b = 3;. Both o1 and o2 shared the field b inherited from Object.prototype. Thus, it is possible to describe the heap as follows: {o1 :: {a 1, b 3} o2 :: {a 2, b 3}}. Thus, we know that there are possible sharing between them but we do not know exactly which (it may be the case that there are no sharing either). However, we can also be more explicit and describe the heap without as follows: {o1 :: {a 1, proto O p } o2 :: {a 2, proto O p }} O p :: {b 3} where O p describes the Object.prototype object. The main problem with the latter method is that the specifications become very precise. It may only describe a single heap. In contrast, the former method hides the sharing (i.e. more abstract) as the field b may actually be along several proto - chain object. Using the latter model, we might have to explicitly specify the heap for every function call. This might be the main reason why JuS is currently not scalable. Our hope is to find the right balance to be able to automate the verification yet, 52

55 still expressive enough to be able to verify complex examples. 4.3 Object-Capabilities Model Object-capability model is an adaptation of capability-based protection (Levy, 1984; Tanenbaum et al., 1990) seen in some operating systems with the blurring of the dichotomy between subject and object (Miller et al., 2003; Miller, 2006). A capability can be seen as an unforgeable token to access a resources. Under the assumption of having a set of restricted action and a set of initial heap, Maffeis et al. defines an isolation intuitively as no two programs (in this case, JavaScript code) may influence each other and there is no leak of access (Maffeis et al., 2010). This model is then extended further by defining a sub-language called Secure EC- MAScript (SES light ) which is very close to ES5S (as described in Section??. Using SES light, they define a static analysis method comprising of conventional contextinsensitive and flow-insensitive points-to analysis to check for isolation property based on object-capability model (Taly et al., 2011). However, their static verification method is only interested in verifying isolation property of the application programming interface (API) and the programs generated using them. Other safety property such as invoking a non-function is not checked. 53

56 5 Our Proposed System Given the description of JavaScript and current verification method, we would like to propose our system to handle JavaScript piece-wise. The first problem with JavaScript is the many relaxed conditions such as allowing multiple declaration of variables, duplicate function parameters, etc. In addition, with-statement allows manipulation of scope-chain to prepend arbitrary object and break the static scoping. This problem is not present in ES5S. Hence, our first attempt is to convert JavaScript code to the semantically equivalent ES5S code through source-to-source translation in Section 5.1. The next step will be to handle verification of dynamic-typing and higher-order functions independently of each other in the hope of finding a semantics and specification language that can capture both aspects in the future. In the verification of dynamic-typing, we are hoping to verify first-order dynamically-typed JavaScript code which is already transformed to ES5S using the source-to-source transformation. In the verification of higher-order functions, we can either create an explicitly typed JavaScript variant similar to JavaScript 2.0 (Horwat, 2005) or using annotations in comment that can be parsed by our automated verifier to annotate type. 5.1 Source-to-Source Translation Following the differences in scoping evaluation between some major web-browsers, most notably between Mozilla Firefox and the rest of the modern web-browsers, our proposed source-to-source translation will have a tag to indicate which browser it is intended to be. The source-to-source translator is similar to a compiler that takes in arbitrary JavaScript code, but instead of transforming it to machine code, it will transform the parsed code to another JavaScript code satisfying ES5S. Of importance in the translation is the removal of with-statement while maintaining semantics. We borrow from Guha et al. in their translation to λ js (Guha et al., 54

57 1 var o = {x: 1, y: 2}; 2 with (o) { // Outer with - statement 3 function foo (y, z) { 4 with (z) { // Inner with - statement 5 return x + y + z; 6 } 7 } 8 } 9 o = {x: 3, y: 4}; alert ( foo (5,{z :12})); // Returns alert ( foo (5,{x:10, z :12})); // Returns alert ( foo (5,{x:10, y:11, z :12})); // Returns 33 Figure 25: with-statement Before Translation 2010), but instead, we will translate to another JavaScript code. In the translation, we assume the existence of JavaScript parser such as Esprima (Hidayat, 2012). The output parsed tree is then given to the source-to-source translator to produce another parsed tree that can be written back to ES5S format. As in general compiler, the translator will differentiate block and statement in the translation. The translation scheme for with-statement is shown in Algorithm 1 for block translation and Algorithm 2 for statement translation. Note that the remaining blocks and statements are elided for simplicity of presentation. An example of translation can be seen in Figure 25 and 26. In the translation, we start by creating a fresh variable for the object declared within the with-statement, in the example, object o and z. This is done to record the object at the time the with-statement is declared. Otherwise, the changes to object o at line 9 of Figure 25 (resp. line 32 of Figure 26) will causes changes to the execution which is incorrect. The variable accessed by with-statement should be statically scoped. At the start of function foo, we should record that variables y and z should be local. Any access to either one will be prioritized over lookup through object o and the remaining scope-chain. However, with the addition of inner with-statement, lookup through object z is prioritized. 55

58 Input: sourcet ree = parsed tree from source code; withlist = list corresponding to with-object; locallist = list corresponding to local variable; nodelist := read from source tree targett ree := empty tree while nodelist is not empty do /* The rest of translations are straightforward and is elided from for simplicity of presentation */ if node in nodelist is with-block then withobject := read with object from node withblock := read with-block from node withv ar := new fresh variable targett ree.insertstatement(parse( var +withv ar+ = +withobject+ ; )) withlist.push(withv ar) locallist.push(empty list) targett ree.insertstatement(translateblock(withblock, withlist, locallist)) withlist.pop() locallist.pop() end if node in nodelist is function-block then parameters := read parameters from node localdeclaration := read local variable declared in function-block f uncblock := read function-block from node foreach param in parameters do locallist.getfirst().push(param) end foreach local in localdeclaration do locallist.getfirst().push(local) end node.replacefunctionblock(translateblock(f unctionblock, withlist, locallist) foreach local in localdeclaration do locallist.getfirst().pop() end foreach param in parameters do locallist.getfirst().pop() end targett ree.insertstatement(node) end end return targettree Algorithm 1: Source-to-Source Translation for Block 56

59 Input: sourcet ree = parsed tree from source code; withlist = list corresponding to with-object; locallist = list corresponding to local variable; targett ree := empty tree /* The rest of translations are straightforward and is elided from for simplicity of presentation */ if node in sourcetree is variable-statement then varn ame := read variable name from node newn ame := new fresh variable ifadded := false targett ree.insertstatement(parse( var +newn ame+ ; )) foreach (withvar,localvars) in (withlist,locallist) do if the first statement then if varname in localvars then targett ree.insertstatement(parse(newn ame+ = +varn ame+ ; )) Break end else ifadded := true targett ree.insertstatement(parse( if( +varname+ in + withv ar+ ) { +newname+ = +withv ar+. +varname+ ; } )) end end else if varname in localvars then ifadded := false targett ree.insertstatement(parse( else { + newname+ = +varname+ ; } )) Break end else ifadded := true targett ree.insertstatement(parse( elseif( +varname+ in + withv ar+ ) { +newname+ = +withv ar+. +varname+ ; } )) end end end if ifadded = true then targett ree.insertstatement(parse( else { + newname+ = +varname+ ; } )) end end /* For member-lookup statement, we search for the first variable using the above scheme, the rest is straightforward */ return targettree Algorithm 2: Source-to-Source Translation for Statement 57

60 1 var o = {x: 1, y: 2}; 2 var _o_fresh = o; // Outer with - statement start 3 function foo (y,z) { 4 var _z_fresh_1 = z; // Inner with - statement start 5 6 var _x_fresh ; // Search for x 7 if("x" in _z_fresh_1 ) { 8 _x_fresh = _z_fresh_1. x; 9 } else if("x" in _o_fresh ) { 10 _x_fresh = _o_fresh. x; 11 } else { 12 _x_fresh = x; 13 } var _y_fresh ; // Search for y 16 if("y" in _z_fresh_1 ) { 17 _y_fresh = _z_fresh_1. y; 18 } else { 19 _y_fresh = y; // Local parameter before outer with 20 } var _z_fresh_2 ; // Search for z. a 23 if("z" in _z_fresh_1 ) { 24 _z_fresh_2 = _z_fresh_1. z. a; 25 } else if(" z" in _z_fresh_1 ) { 26 _z_fresh_2 = _z_fresh_1. z. a; 27 } else { 28 _z_fresh_2 = z; 29 } 30 return _x_fresh + _y_fresh + _z_fresh_2 ; 31 } 32 o = {x: 3, y: 4}; alert ( foo (5,{z:{a :12}})); // Returns alert ( foo (5,{x:10, z:{a :12}})); // Returns alert ( foo (5,{x:10, y:11, z:{a :12}})); // Returns 33 Figure 26: with-statement After Translation 58

61 Whenever we encounter a statement that requires variable lookup (in this case, the return statement with lookup for variable x, y, and z) we replace them with explicit lookup through the scope-chain that is extended from the with-statement. For variable x, the lookup is straightforward: we search in z, follow by o, and finally, global. Variable y is shorter because after the inner with-statement, we know that it is locally declared in the scope. Thus, we should not search for y in object o (i.e. outer with-statement). Lastly, search for z.a only requires lookup for variable z in the scope-chain, the rest is lookup through proto -chain which doesn t require special syntactic transformation. Although the remainder of the translation is more straightforward than the translation for with-statement, we will check the output of the translation with standard JavaScript test suite such as SpiderMonkey (Firefox), V8 (Chrome), and Rhino. Furthermore, given that with-statement is difficult to optimize due to nonstatic scoping, we will also benchmark the execution of the translated and nontranslated code. Initial benchmark test at is promising. The result of comparison of codes at Figure 25 and 26 shows that with-statement is generally slower than the translated code 25. The result is summarized in Figure 27. In two out of three web-browsers, the result for translated code outperforms untranslated code with performance gain of about 90% for Firefox. The only exception is IE where translated code performs almost as good as the other web-browsers and untranslated code outperforms all other browsers. It should also be noted that the code run with a little modification. Line 3 of Figure 25 is changed to var foo = function (y,z). Since both Chrome and IE hoist the code to the top of the scope, function foo is declared outside the with-statement. Hence, lookup of variable x will fail at line Test page can be seen at 59

62 Figure 27: Comparison of Untranslated and Translated with-statement 5.2 Dynamic-Typing Our proposed solution for verification of dynamically-typed language such as JavaScript is to bypass the type system. In the core imperative language of HIP and SLEEK, we can define our own recursive data structure. However, this will not be allowed in our proposed system and will not be checked for syntactic correctness. Instead, we will use the following notation variable :: {field value} borrowed from (Qin et al., 2011). In addition, the following axioms will be introduced. Axiom 1 Normalization Axiom v :: {f 0, f 1,..., f n 1 } v :: {f n, f n+1,..., f m } v :: {f 0, f 1,..., f m } Axiom 2 Separation Axiom v :: {f, f 0,..., f n 1 } v :: {f, f n,..., f m } With the two axioms, separation can be seen to be specific to each field of an object. In addition, this allows us to write a more concise specification showing only 60