9/7/2013

Some topics I’m working on

• Computing on encrypted data • Information flow: Dynamic IFC in Haskell, web Sandboxing Untrusted JavaScript • Third‐party web tracking and other web security stories • Practical web security (tools, methods,…) • Android malware scanning John Mitchell • Machine learning for CAPTCHAs, security Stanford University • Online learning

Seek postdoc with theoretical, practical skills

Outline for Today, Tomorrow

• Background: computer security • Web fundamentals and browser security • JavaScript isolation – How can trusted and untrusted code be executed in the same environment, without compromising functionality or security? Computer Security • Three parts – Isolate untrusted application from hosting page – Isolate one untrusted application from another – Mediated access: reference monitor for critical resources • Additional topics – Operational semantics (covered between parts I and II) – Foundations for Web security

Computer Security Network security

• Security model – A system of interest – Desired properties of the system – Interface and capabilities of an attacker • Security analysis Alice – Can system design and security mechanism it includes guarantee desired the properties, in spite of attacker? Network Attacker

Secure(Sys,Prop,Threat) = System May intercept and U UserIn. A  Threat. Runs  Sys(A,U). Prop(Runs) alter network traffic; cannot break crypto Inherently analytical problem; not determined by testing

1 9/7/2013

Operating system security Web Security

Good server Enter password? System Browser Network

User Alice

OS Attacker Bad Server

May control malicious files and applications How can honest users safely interact with well‐intentioned sites, while still freely Can also operate as client browsing the web (search, shopping, ads) ? to other servers

Web Security Broader goals of web security

System Good server Enter password? • Safely browse the web Browser – Users should be able to visit a variety of web sites, Network without incurring harm: • No stolen information (without user’s permission) • Site A cannot compromise session at Site B User • Secure web applications – Applications delivered over the web should have the Interface same security properties we require for stand‐alone Bad Server applications

How can honest users safely interact with • Mobile apps well‐intentioned sites, while still freely Can also operate as client – Many mobile apps are interfaces to web sites (WebView) browsing the web (search, shopping, ads) ? to other servers Attacker

Web Threat Models Specific problem for this talk

Good server • Web attacker Enter password? – Control attacker.com Browser Network – Can obtain SSL/TLS certificate for attacker.com – User visits attacker.com • Or: runs attacker’s Facebook app User • Network attacker – Passive: Wireless eavesdropper Bad Server – Active: Evil router, DNS poisoning How can sites that incorporate untrusted JavaScript applications protect their users? • Malware attacker Supply web application – Attacker escapes browser isolation mechanisms written in JavaScript and run separately under control of OS

2 9/7/2013

Specific problem for this talk

System Good server Enter password? Browser Network Web fundamentals and User browser security

Interface Bad Server How can sites that incorporate untrusted JavaScript applications protect their users?

Supply web application written in JavaScript Attacker

Network

Network request and response

Uniform Resource Locator (URL) HTTP Request

Method File HTTP version Headers • Global identifier of network‐retrievable content GET /index. HTTP/1.1 • Example: Accept: image/gif, image/x-bitmap, image/jpeg, */* http://stanford.edu:81/class?name=cs155#homework Accept-Language: en Connection: Keep-Alive User-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95) Protocol Host: www.example.com Fragment Referer: http://www.google.com?q=dingbats Hostname Port Path Query Blank line • Special characters are encoded as hex: Data – none for GET – %0A = newline – %20 or + = space, %2B = + (special exception) GET : no side effect POST : possible side effect

3 9/7/2013

HTTP Response

HTTP version Status code Reason phrase Headers

HTTP/1.0 200 OK Date: Sun, 21 Apr 1996 02:20:42 GMT Server: -Internet-Information-Server/5.0 Connection: keep-alive Content-Type: text/html Data Last-Modified: Thu, 18 Apr 1996 17:39:05 GMT Rendering Content Set-Cookie: … Content-Length: 2543

Some data... blah, blah, blah

Cookies

Washington Post: Breaking News, World, US, DC News .. Analysis ... Displaying a page ...

Secret court:
NSA gathered thousands of domestic e-mails ...

Ellen Nakashima …

The program unlawfully gathered as many as tens of thousands of e-mails, according to a 2011 opinion.

...
... Share this video: ...

make RPC call server and in your client‐side code. server.html: another page on same server, could be server.php, etc – Simple HTTP via a hidden IFRAME Important Point: A web can maintain bi‐directional communication with browser (until user closes/quits) RPC can be done silently in JavaScript, passing and receiving arguments See: http://developer.apple.com/internet/webcontent/iframe.html

Continuing trend Browser security mechanism

• Why ask the user to do something if you can write JavaScript to do it automatically? A B A A

B

• Each frame of a page has an origin – Origin = protocol://host:port • Frame can access its own origin – Network access, Read/write DOM, Storage (cookies) • Frame cannot access data associated with a different origin

Library import Analogy

• Primitives • Primitives – System calls – Document object model – Processes – Frames VeriSign – Disk – Cookies / localStorage • Principals: Users • Principals: “Origins” – Discretionary access control – Mandatory access control • Vulnerabilities • Vulnerabilities • Embedded script has privileges of frame, NOT source server – Buffer overflow – Cross‐site scripting • Can script other pages in this origin, load more scripts – Root exploit – Cross‐site request forgery • Other forms of importing – Cache history attacks – …

6 9/7/2013

Advertisements Maps

Social Networking Sites Third‐party content

User data

User‐ supplied application

Secure Web Mashups

 Challenge Site data – How can trusted and untrusted code be executed in the same environment, without compromising functionality or security? Hosting page isolation User‐supplied content Protect hosting page from  Approach  Test cases and paradigms – Programming language semantics – Facebook JavaScript (FBJS) untrusted applications  Mathematical model of program execution  Allow user‐supplied applications (executed in the same browser frame) – Secure sublanguages and security tools – Yahoo! ADSafe  Filtering, Rewriting, Wrapping  Screen ad content before publisher  Object‐capability model – Google Caja  Improved JavaScript standards  Mathematical foundations of object‐  Automated code analysis tool(s) capability languages  Isolation, defensive consistency, …

7 9/7/2013

Hosting page isolation Facebook FBJS

– Facebook applications either“iframed” or integrated on page • We are interested in integrated applications Outer page contains user – Integrated applications are written in FBML/FBJS account information, other • Facebook subsets of HTML and JavaScript User data important data • FBJS is served from Facebook, after filtering and rewriting Embedded • Facebook libraries mediate access to the Document Object Model application can try – Security goals to access this data • No direct access to the Document Object Model (DOM) • No tampering with the execution environment • No tampering with Facebook libraries – Basic approach • FBJS restricts “tricky” parts of JavaScript User‐ • Blacklist variable names that are used by containing page supplied • Prevent access to global scope object, because variables are application properties of scope objects

Four “FBJS” Theorems JavaScript Challenges

• Theorem 1: Subset J(B) of ES‐3 prevents access to – Mutable objects with implicit self parameter: chosen blacklist B (assuming B P =) • o={b:function(){return this.a}} nat – Prototype‐based object inheritance: • Theorem 2: Subset J(B)G of J(B) prevents any • Object.prototype.a=“foo”; expression from naming the global scope object – Scope can be a first‐class object: • this.o === o; • Theorem 3: Subset J(B)S of J(B)G of prevents any expression from naming any scope object – Can convert strings into code: • eval(“o + o.b()”); • Theorem 4: Aspecific “wrapping” technique – Implicit type conversions, which can be redefined. preserves Theorem 3 and allows previously • Object.prototype.toString = o.b; blacklisted functions to be safely used

JavaScript can be tricky

• Which declaration of g is used? • Use of this inside functions var f = function(){ var a = g(); var b = 10; function g() { return 1;}; var f = function(){ var b = 5; function g() { return 2;}; function g(){var b = 8; return this.b;}; var g = function() { return 3;} g();} return a;} var result = f(); var result = f(); // has as value 10 // has as value 2 • String computation of property names • Implicit conversions var m = "toS"; var n = "tring"; var y = "a"; Object.prototype[m + n] = function(){return undefined}; var x = {toString : function(){ return y;}} x = x + 10; for (p in o){....}, eval(...), o[s] js> "a10" // implicit call toString allow strings to be used as code and vice versa

8 9/7/2013

JavaScript modularity Operational Semantics [APLAS’08]

• Modularity: variable naming and scope • JavaScript local variables are not “local” – Activation records are objects – A program can get access to these objects • Properties (local variables) can be added, removed – These objects have prototypes • Properties (local variables) can be added, removed • Traditional JavaScript (ECMA 2.6.2‐3) does not support modularity with information hiding

Basis for JavaScript Isolation Sample Facebook vulnerability

1. All explicit property access has form x, e.x, or e1[e2] 2. The implicitly accessed property names are: 0,1,2,…, toString, toNumber, valueOf, length, prototype, constructor, message, arguments, Object, Array, RegExpg 3. Dynamic code generation (converting strings to programs) occurs only through eval, Function, and indirectly constructor – FBJS e1[IDX(e2)] did not correctly convert objects to strings 4. A pointer to the global object can only be obtained by: this, – Exploit: we built an FBJS application able to reach the DOM. native method valueOf of Object.prototype, and native – Disclosure: we notified Facebook; they promptly patched FBJS. methods concat, sort and reverse of Array.prototype – Potential for damage is considerable. 5. Pointers to local scope objects through with,try/catch, • Steal cookies or authentication credentials • “named” recursive functions var f = function g(..){… g(..)… Impersonate user: deface or alter profile, query personal information, spam friends, spread virally.

The run time monitor IDX Improving our solutions by wrapping

– We need some auxiliary variables: we prefix them with $ – No need to blacklist sort, concat, reverse, valueOf. and include them in our blacklist B • We can wrap them as follows var $String=String; $OPvalueOf=Object.prototype.valueOf; var $B={p1:true;...,pn:true,eval:true,…,$:true,…} Object.prototype.valueOf= – Rewrite e1[e2] to e1[IDX(e2)], where function(){var $=$OPvalueOf.call(this); IDX(e) = return ($==$Global?null:$)} ($=e,{toString:function(){ • This variant is provably correct. return($=$String($), $B[$]?"bad":$) – Wrapping eval and Function : possible in principle }}) • Blacklisting can be turned into whitelisting by inverting the check above ($B[$]?$:"bad"). – Our rewriting faithfully emulates the semantics e1[e2] -> va1[e2] -> va1[va2] -> l[va2] -> l[m]

9 9/7/2013

Four “FBJS” Theorems[CSF'09… ESORICS’09] Yahoo! AdSafe

• Theorem 1: Subset J(B) of ES‐3 prevents access to • Goal: Restrict access to DOM, global object

chosen blacklist B (assuming B Pnat =) Advertiser Ad Network Publisher Browser

• Theorem 2: Subset J(B)G of J(B) prevents any Ad expression from naming the global scope object Ad Ad Ad Content • Theorem 3: Subset J(B)S of J(B)G of prevents any Content expression from naming any scope object • Theorem 4: Aspecific “wrapping” technique • This is a harder problem than SNS applications preserves Theorem 3 and allows previously – Advertising network must screen advertisements blacklisted functions to be safely used – Publishing site is not under control of ad network We can prove isolation for a language very similar to FBJS. Success!! ?

Outline for Today, Tomorrow

• Background: computer security • Web fundamentals and browser security • JavaScript isolation – How can trusted and untrusted code be executed in the same Structured environment, without compromising functionality or security? • Three parts Operational Semantics – Isolate untrusted application from hosting page – Isolate one untrusted application from another – Mediated access: reference monitor for critical resources • Additional topics – Operational semantics (covered between parts I and II) – Foundations for Web security

Operational Semantics Structural Operational Semantics

• Abstract definition of program execution • Systematic definition of operational semantics – Sequence of actions, formulated as transitions of – Specify the transitions in a syntax oriented manner an abstract machine using the inductive nature of program syntax • States corresponds to • Example – Expression/statement being evaluated/executed – The state transition for e1 + e2 is described using the transitions for e1 and the transition for e2 – Abstract description of memory and other data • structures involved in computation Plan – SOS of a simple subset of JavaScript – Summarize scope, prototype lookup in JavaScript

10 9/7/2013

Simplified subset of JavaScript Form of SOS

• Three syntactic categories – Arith expressions : a ::= n | x | a + a | a * a – Bool expressions : b ::= a<=a | not b | b and b – Statements : s ::= skip | x := a | s; s | if b then s else s | while b do s • States – Pair S =  t ,  – t : syntax being evaluated/executed –  : abstract description of memory, in this subset a function from variable names to values, i.e.,  : Var Values

Sample operational rules Sample rules

Conditional and loops Context Sensitive Rules

11 9/7/2013

Moving to full JavaScript Heap operations

• Program state is represented by a triple H, l, t • Each Heap object o has the form – H : program heap, mapping locations (L) to objects – {p1 : ov1, …, pn : ovn} where pi are property names – l : Location of the current scope object (“activation record”) and ovi are primitive values or heap addresses – t : expression, statement, or program being evaluated • Note • Operations on heap objects – All definable values (including functions) are either objects or – Dot(H, l, p) = l1 primitive values • property p of object at location l – Activation records are normal JavaScript objects and variable – declarations define properties of these objects Put(H, l, p, lv) = H’ – Instead of a stack of activation records, there a chain of scope objects, • Update property p of object at H(l) producing H’ called the scope chain – H’, l = alloc(H, o) • Allocate object o at new location l

Scope and prototype lookup Some notation (based on ECMA Std)

• o hasProperty p – p is a property of object o or one of the ancestral prototypes of o • o hasOwnProperty p – p is a property of object o itself • A JavaScript reference type – pair written l*p where l is a heap address, also – Every scope chain has the global object at its base called the base type of the reference, and p is a – Every prototype chain has Object.prototype at the property name top, which is a native object containing predefined functions such as toString, hasOwnProperty, etc

Semantics of scope lookup Semantics of prototype lookup

12 9/7/2013

Summary of Operational Semantics

• Abstract definition program execution – Uses some characterization of program state that reflects the power and expressiveness of language • JavaScript operational semantics Isolation Between – Based on ECMA Standard – Lengthy: 70 pages of rules (ascii) Untrusted Applications – Precise definition of program execution, in detail – Can prove properties of JavaScript programs • Progress: Evaluation only halts with expected set of values • Reachability: precise definition of “garbage” for JS programs • Basis for proofs of security mechanisms, variable renaming, …

Isolation between applications FBJS limitations

• Authority leak Outer page with user account information, other data – Can write/read properties of native objects Embedded User data • var Obj = {}; application 1 • var ObjProtToString = Obj.toString; Embedded application 2 • Communication between untrusted apps – First application • Obj.toString.channel = ”message”; – Second application • var receive_message = Obj.toString.channel;

Defeat Sandbox How to isolate applications?

Attack FBJS! – Give independent apps disjoint capabilities • Problem: Is there a capability‐safe JavaScript? • Redefine bind method used to Curry functions • Interferes with code that uses f.bind.apply(e)

13 9/7/2013

Foundations for object‐capabilities [S&P 2010]

• Object‐capability model [Miller, …] – Intriguing, not formally rigorous – Examples: E (Java), JoeE (Java), Emily (Ocaml), W7 (Scheme) • Authority safety Mediated Access – Safety conditions sufficient to prevent How can trusted code provide access to • Authority leak (“only connectivity begets connectivity”) • Privilege escalation (“no authority amplification”) security‐critical resources? – Preserved by program execution • Eliminates basis for our previous attacks • Capability safety – Access control model sufficient to imply authority safety • Theorems: Cap safety  Auth safety  Isolation – Accepted examples satisfy our formal definitions

Mediated Access ECMA Script 5 Strict Mode

• Restricted subset of JavaScript with “safer” semantics, e.g. 2 JS Filter & – Assignment to an undeclared identifier does not create a B.com property in the global object Sandboxed code Rewriter (3rd party) – Strict mode eval code cannot instantiate variables or functions API Untrusted in the variable environment of the caller to eval. 1 – A this value of null or undefined is not converted to the global Protected resources A.com object … (hosting Page) – Strict mode code may not include a WithStatement – … Trusted • Goals – Provide language framework for code isolation – Protect trusted strict code against untrusted unstrict code

Facebook FBJS, Yahoo! ADSafe, Google Caja Language standard captures many properties explored in our research

81 JavaScript API Confinement

Two Problems Evolution of JavaScript

• ES3: JS based on ECMA‐262 3rd edition spec Sandboxing: Ensure that access to • ES5: JS based on ECMA‐262 5th edition spec protected resources is obtained ONLY Sandboxed code using the API (released in Dec 2009) API Protected resources • ES5S: strict mode of the ES5 language API Confinement: Verify that no • SESlight: Secure ECMAScript, a subset of ES5S sandboxed untrusted program can use – Basis for our tool the API to obtain a critical reference . – SES is currently under proposal by the ECMA committee.

83 JavaScript API Confinement Stanford9/7/2013 Security Workshop 2011 84

14 9/7/2013

From ES3 to ES5S Second Problem

Sandboxing: Ensure that access to protected resources is obtained ONLY Sandboxed code using the API API Protected resources API Confinement: Verify that no Property: ES5S is a lexically scoped language sandboxed untrusted program can use the API to obtain a critical reference .

9/7/2013 Stanford Security Workshop 2011 85 86 JavaScript API Confinement

API Confinement Problem Techniques

• Points‐to Analysis – Context Insensitive: Single Activation Record per function. – Flow Insensitive: Insensitive to the order of statements. PointsTo(x, P): Set of values that get stored in variable x during – Only track references, ignore primitive values the execution of program P. • Expressed in Datalog (Whaley et al) – Collect Facts about the program: Assign(x,y), Load(x,y,z),... Confine(P, F): For all programs s in SES , If untrusted s has light – Encode semantics of the program as Horn clauses: access to API defined by P, can s gain access to any forbidden Stack(x,l) :‐ Assign(x,y), Stack(y,l) reference in F? – Generate all possible consequence facts under the rules. – Tricky Case: eval, capturing implicit code execution.

• Scalable and well studied techniques for C, Java

9/7/ 9/7/2013 88 Stanford Security Workshop 2011 201

Simple Example Datalog Predicates

Program Facts

var y = {}; Stack(y,ly) var z = {}; encode Stack(z,lz) var x = y; Assign(x,y) x.f = z; Store(x,”f”,z) x = y.f; Load(x,y,”f”)

9/7/2013 89 9/7/2013 90

15 9/7/2013

Inference Rules Procedure

Procedure D(P, F): 1. Build P’ from P by adding “test” variable

2. D1  Encode(P’) + Encoding of built‐in objects.

3. D2  All possible consequences of D1 4. Return confined iff there is no l  F such that

Stack(“test”,l)  D2

Theorem: Procedure D(P,F) is sound.If the procedure says confined then the API is actually safe.

9/7/2013 91 9/7/2013 92

Yahoo! ADSafe Feasible Attack !

Add • ADSafe API does not use setters/getters “___nodes__” property to • can be de‐sugared to SES adsafe_lib light • ADSAFE.lib defined as • Annotations: function (name, f){adsafe_lib[name] = f(adsafe_lib)} • $Num: Added to patterns of the form for(..i..){ o[i,$Num]} • ADSafe API protects DOM objects by hiding them behind • $Reject: Added to patterns of the form “___nodes___” property of certain fake object (Bunch objects). if(!reject(name)){ …object[name,$Reject]… } • Assumption: Sandboxed code can never write to • Approx 2000 LOC. “___nodes___” property of any object. Pass adsafe_lib Analysis tool output: NOT CONFINED if the methods ADSAFE.lib and as Bunch ADSAFE.go are exposed to untrusted code. object to DOM wrapper

9/7/2013 93 9/7/2013 Stanford Security Workshop 2011 94

Fixing the vulnerability

• Replace ADSafe.lib with the following ADSafe.lib = function(name, f){ if(reject_name(name){ adsafe_lib[name] = f(adsafe_lib)} General Foundations for } Web Security Tool analysis result: API is CONFINED. ADSafe API is confined under the provided annotations and the

SESlight threat model.

Repair adopted by Yahoo! ADSafe.

9/7/2013 95

16 9/7/2013

Broader Foundations for Web Security A formal model of the web

 Problem: Web platform and application security are not • Includes browser, servers, and network based on precise model • Threat models include:  Solution: Foundational model of – web attacker with no special network privilege web macro‐platform supporting rigorous analysis – network attacker that can eavesdrop and/or modify – Apply formal modeling unencrypted traffic at will techniques and tools, e.g., network security  web • Security goals include: – Precise threat models: web  Initial case studies – Security invariants attacker, active network – Origin header • Assumptions about how today’s Web works attacker, gadget attacker – Cross‐Origin Resource Sharing – Support trustworthy design • Example: no DELETE in cross‐origin HTTP requests of browser, server, – Referer Validation, – Session integrity protocol, web application – HTML5 forms • Attacker does not participate in the HTTP transaction mechanisms – WebAuth  Find attacks, verify repairs

Alloy [Jackson] Web modeling examples

• Concepts expressed by relations abstract sig NetworkEvent extends Event { – General logical language from: NetworkEndpoint, • User inputs “scope” to determine precision to: NetworkEndpoint } abstract sig HTTPEvent extends NetworkEvent { – Tool converts logical expressions to finitary form by allocating specific number of bits to each possible host: Origin } value sig HTTPRequest extends HTTPEvent { • SAT‐based analysis method: Method, path: Path, – Satisfiability checker used to see if formula is satisfiable headers: set HTTPRequestHeader } sig HTTPResponse extends HTTPEvent { – Leverage large community working on efficient SAT checkers statusCode: Status, headers: set HTTPResponseHeader }

Principals Browsers

• A Principal is an entity that controls a set of NetworkEndpoints and • A Browser is an HTTPClient together with a set of trusted owns a set of DNSLabels, which represent fully qualified host CertificateAuthorites and a set of ScriptContexts. (For technical names: convenience, we store the Browser as a property of a ScriptContext.) abstract sig Browser abstract sig Principal { extends HTTPClient { servers: set NetworkEndpoint, trustedCA: set CertificateAuthority dnslabels: set DNS } } sig ScriptContext { abstract sig PassivePrincipal owner: Origin, extends Principal{} { location: Browser, servers in HTTPConformist transactions: set HTTPTransaction } }

17 9/7/2013

Cookies (modeled as a fact) Property: session integrity

• Idea: HTTPRequests from Browsers contain only appropriate fun involvedServers[t:HTTPTransaction] : cookies from previous SetCookieHeaders fact { set NetworkEndpoint { all areq:HTTPRequest | { (t.*cause & HTTPTransaction).resp.from areq.from in Browser hasCookie[areq] + getTransactionOwner[t].servers } implies all acookie: reqCookies[areq] | } some aresp: getBrowserTrans[areq].resp | { aresp.host.dnslabel = areq.host.dnslabel acookie in respCookies[aresp] pred webAttackerInCausalChain[t:HTTPTransaction] { happensBeforeOrdering[aresp,areq] some (WEBATTACKER.servers & involvedServers[t]) } } }

Alloy metamodel Sample case studies

• HTML5 Forms • Referer validation • WebAuth protocol

Referer Validation Modeling

• A proposed defense against Cross‐Site Request • Referer header already part of model Forgery (CSRF) and Cross‐Site Scripting (XSS) • Add check: RefererProtected principals allow HTTP requests with external Referers only on the [F. Kerschbaum, 2007] “LOGIN” page: fact { all aReq:HTTPRequest | { • Websites reject a request unless (getTransaction[aReq].resp.from – the referer header is from the same site, or in RefererProtected.servers ) – the request is directed at an “entry” page vetted and isCrossOrigin[aReq] for CSRF and XSS vulnerabilities } implies aReq.path = LOGIN }

18 9/7/2013

Referer header and redirects

referer: http://www.site.com

referer: http://www.site.com

Referer Validation ‐ Countermeasure WebAuth

• Exploitation • Web‐based Single Sign‐On protocol – CSRF and XSS can be carried out on websites protected with Referer Validation • WebAuth and a similar protocol, Central • Countermeasure Authentication Service (CAS), are deployed at – This vulnerability is difficult to correct as Referer over 80 universities worldwide header has been widely deployed – Websites can try to suppress all outgoing Referer • Although we analyze WebAuth specifically, we headers using, for example, the noreferrer relation have verified the same vulnerability exists in attribute on hyperlinks. • Web extension CAS – Origin header records path of redirects

WebAuth WebAuth Protocol Attack

19 9/7/2013

WebAuth Analysis Statistics for the case studies

• Attack Case Lines of No. of CNF CNF gen. CNF solve – An insider can share privileged web resources with Study new code clauses time (sec) time (sec) unprivileged users without sharing login credentials – Attacker can steal sensitive user information by HTML5 20 976,174 27.67 73.54 logging users into attacker’s account Form • Countermeasure Referer 35 974,924 30.75 9.06 – Store a nonce in a host cookie to bind messages 3 Validation and 9, and splice in messages in between by WebAuth 214 355,093 602.4 35.44 including the nonce in the request and id tokens. – Verified the fix up to a finite size in our model • The base model contains some 2,000 lines of code • Tests were performed on an Intel Core 2 Duo 3.16GHz CPU with 3.2 GB memory

Conclusion of case studies Challenge

• Identified previously unknown attacks in HTML5 Forms, • Does CSP prevent XSS? Referer validation, and WebAuth • Proposed countermeasures to the attacks • These attacks are identified based on a formal model the Web that is implemented in Alloy • Modeling approach can discover practical new attacks and verify the security of alternate designs, up to a certain size of the model

Goals and Challenges Ahead Conclusions

• Language‐based isolation • Web platform security • – Better understanding of – Formalize additional The web is an exciting area for Computer Science object‐capability model properties of web platform • Isolating untrusted JavaScript – Apply to JavaScript and • Browser same‐origin – Isolate untrusted application from hosting page other languages: E, Joe‐E, • Cookie policies – Isolate one untrusted application from another Emily, W7, ES 3  ES 5 • Headers, … – Confinement: mediate access to critical resources – Better tools for working – Prove correctness of • Many more Web security problems with secure JavaScript accepted defenses – Define precise model of web application platform – Wider recognition and – Improve design of central deployment through components – Analyze protocols, conventions, attacks, defenses standards, browser – Improve design of new – Range of information flow problems implementations features (e.g., native client) – Look at correctness, precision of web application development tools

20 9/7/2013

References Additional related work

[Yu,Chander,Islam,Serikov’07] JavaScript instrumentation for browser security. • With A. Taly, S. Maffeis: Rewriting of JavaScript to enforce security policies based on edit‐automata. – Operational semantics of ECMA 262‐3 [APLAS’08] [Sands,Phung,Chudnov’09] Lightweight, self protecting JavaScript. – Language‐Based Isolation of Untrusted Aspect‐oriented wrapping of DOM to enforce user‐defined safety policies. JavaScript [CSF'09] [Jensen,Møller,Thiemann’09] Type analysis for JavaScript. – Run‐Time Enforcement of Secure JavaScript Subsets Abstract‐interpretation based analysis to detect basic type errors. [W2SP'09] – Isolating JavaScript with Filters, Rewriting, and [Chugh,Meister,Jhala,Lerner’09] Staged information flow for JavaScript. Wrappers [ESORICS’09] Static information flow analysis plus run‐time checks for integrity and confidentiality. – Object Capabilities and Isolation of Untrusted Web [Livshits, Guarnieri’09] GateKeeper: Mostly static enforcement of security and Applications [S&P’10] reliability policies for JavaScript code. Enforcing policies by filtering and rewriting based on call‐graph and points‐to analysis. – Automated Analysis of Security‐Critical JavaScript APIs [S&P’11] (with T. + Google group) Web Sandbox (Scott Isaacs). Based on BrowserShield. Rewriting and run‐time monitoring with performance penalty.

21