Protection and Communication Abstractions for Web Browsers in MashupOS
description
Transcript of Protection and Communication Abstractions for Web Browsers in MashupOS
Protection and Communication Abstractions for Web Browsers
in MashupOS
Helen J. Wang, Xiaofeng Fan, Jon Howell (MSR)Collin Jackson (Stanford)
February, 2008
1
OMash: Enabling Secure Web Mashups via Object
AbstractionsSteven Crites, Francis Hsu, Hao
Chen
UC Davis
3
4
… but most of all, Samy is my hero
5
Outline
• The problem
• The MashupOS project
• Protection
• Communication
• Implementation and demo
• Evaluation
• Related work
• Conclusions6
Client Mashups• Web content has evolved from single-principal services
to multi-principal services, rivaling that of desktop PCs.• Principal is domain
7
Browsers Remain Single-Principal Systems
• The Same Origin Policy (SOP), an all-or-nothing trust model:– No cross-domain interactions allowed– (External) scripts run with the privilege of the enclosing page
8
http://integrator.com/
<iframe src=“http://provider.com/p.html”></iframe>
http://integrator.com/
<scriptsrc=“http://provider.com/p.js”></script>
X
Same Origin Policy
a.com
a.com a.com b.com
Server
Browser
What Domains are of the Same Origin?
web1.acm.org web2.acm.orgyes
cs.ucdavis.edu ece.ucdavis.edumaybe
amazon.co.uk bbc.co.ukno
Same origin?
Insufficiency of the SOP
• Sacrifice security for functionality when including an external script without fully trusting it
• E.g., iGoogle, Live gadget aggregators’ inline gadget
11
Insufficiency of the SOP, Cont.• Third-party content
sanitization is hard– Cross site scripting
(XSS): • Unchecked user input in a
generated page • E.g., Samy worm: infected
1 million MySpace.com users in 20 hours
• Root cause:– The injected scripts run
with the page’s privilege
12
Samy is my hero
Insufficiency of the SOP, Cont.
• Sacrifice functionality for security when denying scripts in third-party content
• E.g., MySpace.com disallows scripts in user profiles
13
DNS Insecurity
• Client vulnerabilities– DNS rebinding (Jackson et al, CCS 07)– Dynamic Pharming (Karlof et al, CCS 07)
• Server vulnerabilities– DNS cache poisoning (Kaminsky, BlackHat
08)
Cross-Site Request Forgery
a.com
a.com b.com
Server
Browser
The MashupOS Project• Enable browser to be a multi-principal OS• Focus of this paper: protection and
communication abstractions• Protection:
– Provide default isolation boundaries
• Communications: – Allow service-specific, fine-grained access control
across isolation boundaries
16
Design Principles• Match all common trust levels to balance
ease-of-use and security– Goal: enable programmers to build robust
services– Non-goal: make it impossible for programmers
to shoot themselves in the foot
• Easy adoption and no unintended behaviors
17
Outline
The problemThe MashupOS project
• Protection
• Communication
• Implementation and demo
• Evaluation
• Related work
• Conclusions18
A Principal’s Resources
• Memory: – heap of script objects including DOM objects
that control the display
• Persistent state: – cookies, etc.
• Remote data access: – XMLHttpRequest
19
Trust Relationship between Providers and Integrators
i.com
i.com
ContentSemantics
Abstraction Run-as
20
p.com i.com
Internet
http://i.com/
HTML
XHR
X
XXHR
No No Isolated <Frame> p.com
<iframe src=“http://p.com/c.html”></iframe>
X
Trust Relationship between Providers and Integrators
i.com
i.com
ContentSemantics
Abstraction Run-as
21
p.com i.com
Internet
http://i.com/
Script
XHR
No No Isolated <Frame> p.com
Yes Yes Open <Script> i.com
<script src=“http://p.com/c.js”></script>
Trust Relationship between Providers and Integrators
i.com
i.com
ContentSemantics
Abstraction Run-as
22
p.com i.com
Internet
http://i.com/
No No Isolated <Frame> p.com
Yes Yes Open <Script> i.com
No Yes
X
Trust Relationship between Providers and Integrators
23
p.com i.com
Internet
http://i.com/
X
XXHR
NoneYes No <Sandbox><OpenSandbox>
Unauthorized
Unauth
XXHR
i.com
i.com
ContentSemantics
Abstraction Run-as
No No Isolated <Frame> p.com
Yes Yes Open <Script> i.com
No Yes
Unauthorized content is not authorized to access any principal’s resources.
<sandboxsrc=“http://p.com/c.html”></sandbox>
Properties of Sandbox• Asymmetric access
– Access: reading/writing script global objects, function invocations, modifying/creating DOM elements inside the sandbox
• Invoking a sandbox’s function is done in the context of the sandbox– setuid (“unauthorized”) before invocation and setuid
(“enclosingPagePrincipal) upon exit
• The enclosing page cannot pass non-sandbox object references into the sandbox.– Programmers can put needed objects inside the sandbox
• Private vs. Open sandboxes
24
Private Sandbox<sandbox src=“file”>
Content if tag not supported</sandbox>
• Belongs to a domain and can only be accessed by that domain– E.g., private location history marked on a map
• Private sandboxes cannot access one another even when nested– Otherwise, a malicious script can nest another
private sandbox and access its private content
25
Open Sandbox<OpenSandbox src=“file”>
Content if tag not supported</OpenSandbox>
• Can be accessed by any domain• Can access its descendant open sandboxes
--- important for third party service composition– E.g., e-mail containing a map; don’t want an e-mail
to tamper hotmail.com; don’t want the map library to tamper the e-mail
26
Provider-Browser Protocol for Unauthorized Content
• Unauthorized content must be sandboxed and must not be renderable by frames– Otherwise, unauthorized content would run as the principal of the frame
• MIME protocol seems to be what we want: – Require providers to prefix unauthorized content subtype with
x-privateUnauthorized+ or x-openUnauthorized+– E.g., text/html text/x-privateUnauthorized+html– Verified that Firefox cannot render these content types with <frame> and
<script>– But, IE’s MIME sniffing allows rendering sometimes
• Alternative: encraption (e.g., Base64 encoding)• Prevent providers from unintentionally publishing unauthorized
content as other types of content: – Constrain sandbox to take only unauthorized content
27
Key Benefits of Sandbox
• Safe mashups with ease
• Beneficial to host third-party content as unauthorized content
28
Sandbox for Safe Mashups with Ease
29
http://Mashup.com/index.htm
<script src=“a.com/a.js”> </script>
<script src=“b.com/b.js”> </script>
<script>// local script to Mashup.com // calling functions in a.js and b.js</script>
<div id=“displayAreaForA”> … </div>
X
X
Hosting Third-Party Content as Unauthorized Content
• Combats cross site scripting attacks in a fundamental way– Put user input into a sandbox– Does not have to sacrifice functionality
• Helps with Web spam– Discount the score of hyperlinks in third party
content
30
Outline
The problemThe MashupOS projectProtection
• Communication
• Implementation & demo
• Evaluation
• Related work
• Conclusions31
Communications
• Message passing across the isolation boundaries enable custom, fine-grained access control
32
Isolated Isolated
a.com b.com
CommRequest
Unauthorized
CommRequest• Server:
server = new CommServer();server.listenTo(“aPort”,
requestHandlerFunction);• Client:
req = new CommRequest();req.open (“INVOKE”,
“local:http://bob.com//aPort”, isSynchronous);
req.send (requestData);req.onreadystatechange = function ()
{ …}33
CommRequest vs. XMLHttpRequest
• Cross domain
• Source labeled
• No cookies sent
• “Server” can be on client
• Reply from remote server tagged with special MIME type
• Syntax similar to socket API and XHR
34
Outline
The problemThe MashupOS projectProtectionCommunication
• Implementation & demo
• Evaluation
• Related work
• Conclusions35
Implementation
• Use frames as our building blocks, but we apply our access control
36
ScriptEngine
MashupOSScript Engine
Proxy
MashupOSMIMEFilter
Script executionDOM object access
DOM object update
Original HTML
MashupOS transformed HTML
HTML Layout Engine
Evaluation: Showcase Application
• PhotoLoc, a photo location service– Mash up Google’s map service and Flickr’s
geo-tagged photo gallery service– Map out the locations of photographs taken
• PhotoLoc doesn’t trust flickr nor gmap
37
PhotoLoc/index.htm<script>
function setPhotoLoc(request) { var coordinate = request.body; var latitude = getLatitude (coordinate); var longitude = getLongitude (coordinate); G.map.setCenter(new GLatLng(latitude, longitude), 6);}var svr = new CommServer();svr.listenTo(“recvLocationPort”, setPhotoLoc);
</script>
<Sandbox src=”f.uhtml” id=F> </Sandbox>
<Sandbox src=”g.uhtml” id=G> </Sandbox>
38
Direct access
CommRequest
Demo
39
Evaluation:Prototype Performance
• Microbenchmarking for script engine proxy– Negligible overhead for no or moderate DOM
manipulations– 33%--82% overhead with heavy DOM manipulations
• Macrobenchmark measures overall page-loading time using top 500 pages from the top click-through search results of MSN search from 2005– shows no impact
• Anticipate in-browser implementation to have low overhead
40
Outline
The problemThe MashupOS projectProtectionCommunicationImplementation & demoEvaluation
• Related work
• Conclusions41
Related work• Crockford’s <Module>
– Symmetric isolation with socket-like communication with the enclosing page
• Wahbe et al’s Software Fault Isolation– Asymmetric access though never leveraged
– Primary goal was to avoid context switches for untrusted code in a process
• Cox et al’s Tahoma browser operating system uses VM to– Protect the host system from browser and web services
– Protect web applications (a set of web sites) from one another
42
OMash: Object Mashup
• A new browser security model
• Use Object-Oriented model (e.g. Java object model)
• Treat each Web page as an object– Encapsulate all scripts and data– Objects declare public interface– Objects communicate only via public interface
Object Abstractions
• Java (analogy) • Web page object
public class FooObject {
public void publicMethod() { }
private int privateData;}
<html><script>function getPublicInterface() { function Interface() { this.publicMethod = function () {…} } return new Interface();}var privateData;</script></html>
Page Objects
• A page consists of – DOM tree– Scripts– Credentials (HTTP auth, cookies)
• A page object can be contained in a– Window– Tab– Frame– Iframe
Public and Private Members
• Public interface– Each object declares getPublicInterface()– Returns a closure of all public methods and
data
• Private data– DOM– Scripts– Credentials
Usage Example
• map.html • integrator.html<html>function getPublicInterface() { function Interface() { this.setCenter = function (lat,long) { … } } return new Interface();}</html>
<iframe src="map.html">...var map = win.getPublicInterface();...map.setCenter(lat, long);}
map.html
integrator.html
Trust Relationships
• Can model trust relationships needed for mashups (as identified by MashupOS)– Isolated– Open– Access-Controlled– Unauthorized
• No access between provider and integrator
Isolated
function getPublicInterface() { function Interface() { } return new Interface();}
Open
• Full access between provider and integrator
function getPublicInterface() { function Interface() { this.getDocument = function () { return document; } } return new Interface();}
• Limited access depending on caller
Access-controlled
function getPublicInterface() { function Interface() { this.auth = function(user,pass) { return token; }
this.do = function (token,...) { check(token); } } return new Interface();}
var api = win.getPublicInterface();
token =api.auth(user, pass);
api.do (token,...)
Provider Integrator
Preventing CSRF
a.com
a.com b.com
Server
Browser
Preventing CSRF
a.com
a.com b.com
Server
Browser
Preventing CSRF
a.com
a.com b.com
Server
Browser No cookie!
Browser Sessions under OMash
• Each cookie– belongs to a window– is shared by subsequent pages from the
same domain in that window
• Each window has an independent session– Desirable side effect:
Can log in to multiple accounts in different windows in the same browser
Cross-window Sessions
• How to track a session across windows?
• Cookie Inheritance– When page P1 loads P2, P2 inherits P1’s
cookies– P1 and P2 now belong to the same session
Implementation
• Proof of concept as Firefox add-on– Make an exception to SOP in Mozilla’s
Configurable Security Policy– Change Cookie Manager to make each
cookie private to a window
• No changes required on the server
Supporting SOP without DNS
• If application prefers using SOP to allow inter-page communication:
• To implement this under OMash– Server embeds a shared secret in all pages– Pages authenticate each other using this
secret
Supporting SOP without DNS
secret = “1234”;function getPublicInterface() { function Interface() { this.foo=function (secret, … ) { check(secret); … } } return new Interface();}
<script>secret = “1234”api = win.getPublicInterface()api.foo(secret, …)</script>
Provider Integrator
Related Work
• MashupOS (Wang et al, SOSP 07)
• SMash (Keukelaere WWW 07)
• Google’s Caja
Conclusion
• OMash a new browser security model– Allows flexible trust relation– Simple– Familiar, easy to understand
• Don’t rely on Same Origin Policy– Prevent CSRF attacks– Allows programmers to define “Same Origin”
flexibly based on shared secrets
Future Work
• Robust implementation of the protection model
• Tools to detect whether a browser extension violates the browser’s protection model
• Tools for ensuring proper segregation of different content types
• Resource management, OS facilities
62
Conclusions
• Web content involves multiple principals• Browsers remain a single principal platform• The missing protection abstraction: Unauthorized
content and <sandbox>– Enable safe mashups with ease– Combats cross-site scripting in a fundamental way
• CommRequest allows fine-grained access control across isolation boundaries
• Practical for deployment
63
Thank you!
64