Building Secure Web Mashups Outline I Browser

Building Secure Web Mashups

Outline I. Browser Security Overview II. Web Mashups III. Browser Security Details IV. Mashup Frameworks: Mashup. OS, Subspace, SMash, Caja V. Framework Evaluation and Comparison VI. Related Work 2

Browser Security Overview

Layers of Browser Code ü Default browser behavior ü Binary plug-ins for embedded content ü Extensions that modify browser behavior ü Scripts that make web pages active 4

Extensions vs. Scripts ü Theoretical perspective: the only difference is that web page scripts disappear after you leave a page and extensions don't ü Firefox reality: ü Extensions are completely unrestricted ü Web page scripts are restricted unless digitally signed 5

Security in Web Browsers ü Browsers simultaneously handle documents and scripts from multiple sources ü Scripts may attempt to interact with: ü Other web pages ü The browser ü Files and processes on the user's computer ü Remote hosts 6

A Security Failure Example ü The user is viewing a page with a secret confirmation code, which can be traded in person for some good or service ü A web page in another window reads the code and sends it to a remote host, where it can be accessed by an unscrupulous third party 7

Real-World Defense ü Same-origin policy: active content from different trust domains shouldn't interact ü SOP mostly succeeds for pages that want complete isolation ü SOP has inconsistencies and gaps that make partial isolation difficult or impossible 8

Web Mashups

Mashup Examples ü housingmaps. com ü Wii Finder ü Clockr ü popurls. com ü Yahoo vs. Google ü Google Gadgets 10

Web Mashup Definitions ü Mashup: A web application that performs browser-side integration of content or services from multiple sources ü Integrator: site that hosts the web application ü Provider: site the provides content to the mashup ü Component: a piece of active content from a provider 11

Sorts of Mashups ü Directly interacting with a web service from inside a browser script (e. g. , reading an RSS feed) ü Display control delegation (Google gadgets: Google as integrator) ü Display control delegation + two-way browserside communication (Google maps, Google search: Google as provider) 12

Mashup Techniques ü Simulated mashup: server-side data collection ü Frames + proxy server ü Frames + fragment-identifier messaging ü Browser plug-ins for relaying information ü Dynamically generated script requests 13

Mashup Security Concern ü If you include a Google Search control on your page, you give Google the ability to: ü read arbitrary information ü send it to an arbitrary recipient ü execute arbitrary code 14

Browser Security Details

Browser State: Documents ü DOM: mutable tree structure model ü Metadata: ü domain property ü cookie property ü referrer property ü etc. 16

Browser State: Frames ü Can be nested with <iframe> tag ü Metadata: ü document property ü location property ü history property ü parent property ü frames property 17

Scripts in Documents ü Java. Script: dynamically typed, object-oriented, first-class functions, reflection, eval ü Two primary methods ü Inline: <script>var x=3; </script> ü External: <script src="xyz. com/abc. js"/> ü Each frame has one global environment 18

Web Scripting ü Event handling ü Browser data structure access and DOM manipulation ü Script environment access ü Opening, closing, and navigating frames ü HTTP transactions (XMLHttp. Request) ü Also: cookie access, plug-in scripting 19

Dynamic Script Request <html> <head><title>Script Request</title> <script> function do. It() { var s = document. create. Element("script"); s. set. Attribute("src", "http: //www. xyz. com/code. js") document. body. append. Child(s); } </script> </head> <body> <p><button onclick="do. It()">Do it!</button></p> </body> </html> 20

SOP Origins ü Origin = domain name + port + protocol ü Assigned to content and scripts according to document URL (source of script irrelevant) ü Domain promotion: ü xyz. com < abc. xyz. com ü Accomplished by setting domain property 21

SOP Restrictions ü A script cannot read or write data associated with a frame of a different origin -- exceptions: ü Scripts can write the location property ü Scripts may be able to read the frames property ü A script cannot access the Java. Script environment of a frame of a different origin ü A script cannot use XMLHttp. Request to interact with a site of a different origin 22

Mashup. OS Helen J. Wang, Xiaofeng Fan, Jon Howell, and Collin Jackson. Protection and communication abstractions for web browsers in Mashup. OS. SIGOPS Oper. Syst. Rev. , 41(6): 1 -16, 2007.

Mashup. OS Concept ü Keep the same-origin policy around for frames ü Add new frame-like structures to HTML with variations on the same-origin policies 24

Sandboxes ü <Sandbox> like a frame ü References from outside the sandbox can never be passed in ü Scripts can access <Open. Sandbox> without SOP restrictions ü Nesting raises some complex issues 25

Service Instances ü <Service. Instance> loads code from an external site ü <Friv> sections can be controlled by service instances ü Browser-side messaging using new JS: Comm. Server() and Comm. Request() 26

Subspace Collin Jackson and Helen J. Wang. Subspace: Secure cross-domain communications for web mashups. In WWW '07.

Subspace Concept ü Use browser's same-origin policy to enforce isolation of providers' content ü Use domain promotion to allow each provider to share a single Java. Script object with the integrator for communication 28

Subspace www. mashup. com/index. html www. mashup. com/mediate. html www. p 1. mashup. com/index. html p 1. <script src="p 1. com/mashup. js" /> 29

Subspace (Multiple Providers) www. mashup. com/index. html www. mashup. com/mediate. html www. p 1. mashup. com/index. html p 1. <script src="p 1. com/mashup. js" /> p 1. mashup. com/access. html 30

SMash Frederik De Keukelaere, Sumeer Bhola, Michael Steiner, Suresh Chari, and Sachiko Yoshihama. SMash: Secure component model for cross-domain mashups on unmodified browsers. In WWW '08.

SMash Concept ü Use browser's same-origin policy to enforce isolation of providers' content ü Implement a robust message-passing system based on setting fragment identifiers 32

SMash www. mashup. com/index. html p 1. mashup. com/index. html #3330 walnut <script src="p 1. com/mashup. js" /> www. mashup. com/tunnel. html #scroll-up 33

SMash Challenges ü Fragment-identifier size limit ü Synchronization ü Message authenticity ü Message integrity 34

SMash: Direct Style www. mashup. com/index. html p 1. com/index. html www. mashup. com/tunnel. html 35

Caja Mark S. Miller, Mike Samuel, Ben Laurie, Ihab Awad, and Mike Stay. Caja: Safe active content in sanitized Java. Script. A Google research project, June 2008.

Caja Concept ü Use a scripting language with stronger guarantees ü Make it as similar to Java. Script as possible for backwards compatibility 37

Object-Capability Languages ü Objects can only change the world through the references they hold ü Objects can only receive references through method calls ü Objects never start with references ü Encapsulation is used and enforced 38

Difficulties with Java. Script ü Object properties can be enumerated, updated, added, and removed ü Code abstractions can be called as functions, as methods, as constructors, or via reflection ü Dynamic evaluation ü Code in a frame shares an environment 39

Caja Overview ü Caja is a subset of Java. Script: syntax, semantics, and libraries ü Caja code is elaborated into sanitized Java. Script ü Caja modules have their own global envrionment ü Dynamic evaluation is restricted 40

Caja Restrictions ü Properties ending in underscores are private ü Use of functions as constructors only allowed in a restricted way ü Objects may be "frozen" ü Restricted use of functions as objects ü eval only offered for Cajita (no this) 41

Framework Evaluation and Comparison

Some Key Issues ü Browser modification? ü Necessary provider cooperation vs. backwards compatibility ü Flexibility of component interaction ü Amount of trust providers must have in the integrator 43

Mashup. OS: Service Instances ü Browser modification necessary ü Providers must conform to specification ü Authenticity is lightweight and guaranteed by browser ü Flexible message-passing framework but dataonly messages ü Flexible display delegation but security behavior of <Friv> tags a bit unclear ü Providers' privacy not fully protected 44

Mashup. OS: Sandboxes ü Permit backward compatibility with current APIs ü Seem redundant with service instances ü Awkward interaction with SOP ü Terribly complicates browser security, especially in combination with service instances 45

Subspace and SMash ü Both accommodate script-based APIs ü Both restricted to data-only messages ü Dynamically loaded components only possible in SMash ü Higher message throughput in Subspace 46

Direct Use of SMash ü Provider can use XMLHttp. Request ü Providers can authenticate other parties ü Providers have full privacy ü Providers must conform to a standard based on fragment-identifier messaging 47

Caja ü Does not guarantee any particular security properties ü Can be used to program very fine-grained access control ü For direct applicability to mashups, providers would have to use Caja ü Secure messaging easy to implement ü Providers can safely exchange closures ü Providers must trust the integrator 48

Conclusions ü Subspace a nice short-term solution ü Browser modification inevitable ü Message-passing popular for clean access control ü Information flow analysis more appropriate ü Language support would be tremendously helpful 49

Related Work

Browser-Side Messaging ü Douglas Crockford. The <module> tag. http: //www. json. org/module. html, October 2006. ü Ian Hickson and David Hyatt (editors). HTML 5. http: //www. w 3. org/html/wg/html/, June 2008. 51

Fragment-Identifier Messaging ü XDDE ü Google. Pub. Sub: Gadget-to-gadget communication. http: //code. google. com/apis/gadgets/docs/pub sub. html, June 2008. 52

Unexpected Attacks ü Shou Chen, David Ross, and Yi-Min Wang. An analysis of browser domain-isolation bugs and a light-weight transparent defense mechanism. In CCS '07. ü Collin Jackson, Andrew Bortz, Dan Boneh, and John C. Mitchell. Protecting browser state from web privacy attacks. In WWW '06. 53

Safer Java. Script ü Dachuan Yu, Ajay Chander, Nayeem Islam, and Igor Serikov: Java. Script instrumentation for browser security. In POPL '07. ü K. Vikram and Michael Steiner: Mashup component isolation via server-side analysis and instrumentation. W 2 SP 2007. ü Charles Reis, John Dunagan, Helen J. Wang, Opher Dubrovsky, and Saher Esmeir. Browser. Shield: Vulnerability-driven filtering of dynamic HTML. ACM TWEB. 1(3): 11, 2007. 54

Blocking Scripts ü Trevor Jim, Nikhil Swamy, and Michael Hicks. Defeating script injection attacks with browser-enforced embedded policies. In WWW '07. ü Mozilla. Site security policy. http: //people. mozilla. org/~bsterne/sitesecurity-policy/, June 2008. 55

Browser Implementation Design ü Richard S. Cox, Steven D. Gribble, Henry M. Levy, and Jacob Gorm Hansen. A safetyoriented platform for web applications. In SP '06. ü Chris Grier, Shuo Tang, and Samuel T. King. Secure web browsing with the OP web browser. In SP '08. ü Sotiris Ioannidis and Steven M. Bellovin. Building a secure web browser. In FREENIX '01. 56

Thank You