Embed Size (px)
Citation preview
A Framework for Fine Grained Origins
Vaibhav Rastogi and Yi Yang
Objective
SOP is outdated Netscape introduced this policy when
most content on the Internet was static Differences amongst different resources
leads to vulnerabilities Design a new framework to capture
finer grained origins and sharing
Motivation
Web 2.0 – rich applications An abstraction that solves many
problems with one shot A simple change that provides a
solution to many problems
Separation
Third party JavaScript Ads, gadgets, widgets, Facebook
Applications Restrict interaction with the host website
Problem Essentially of maintaining different
origins
Separation
Solution SOP assigns the same origin WebSandbox, AdSafe.▪ Complex solutions▪ Performance problems
More natural solution Have a different origin
Sharing
Current solutions Either unsafe or complex
document.domain Used by several websites for cross
domain sharing Unsafe; attacks studied in class Some websites confirmed to be using
document.domain▪ cnn.com, sina.com.cn, yandex.ru
Sharing
document.domain Wrote a script to find sites which
explicitly set document.domain in source Post Message channel
Achieve arbitrary requirements of security
May be complex to program
Coexisting Web Sessions
Opening two Gmail accounts in one browser without hassle Current solutions are tricky
Current sharing mechanisms
Cookies play an important role
Cross domain sharing Eg. google.com and mail.google.com
Cross site sharing Eg. cnn.com and twitter.com
Resources to be secured
DOM
Cookies
AJAX
Others, like history, display…
Related Work
Secure browser designs Gazelle and OP Criticize SOP but stick to it
MashupOS Propose a new origin policy: VOP sandbox tag provides separation Does not generalize for collaboration Origins may not be changed dynamically
Related work
On the Incoherencies in Web Browser Access Control Policies Current SOP mechanisms thoroughly
criticized ConScript
Controlling JavaScript functionality Solves the separation problem to some extent
Object Views Finer grained sharing for JavaScript objects Cookies and other resources still a problem
Approach
Two approaches for representing origins1. A four tuple
<proto, domain, port, originID>
2. A random stringoriginID = “20-9fkd9kw9j3030d9g0425d“▪ analogous to session cookies
Approaches are lightweight
Approach
Resources to be shared are placed in the same origin
Approach
Resources to be separated are placed in different origins
Approach
If no origins are specified the default is the prevalent Same Origin Policy Current websites do not break
Security Analysis
Approach 1 at least as secure as the SOP
Approach 2: a new attack Sniff the originID on the wire Send malicious content with the same
originID The same attack also exists with cookies
Security Analysis
Attacks by using legacy origins
Solution: Disallow interaction of pages with origin with pages using legacy SOP
Implementation
Allowing Specification of origin in HTML
<html originid=“93681056194027”> HTTP headers
originID : 93681056194027 Disabled document.domain
Implementation
WebKit Implementation
Document
HTML Parser
Frame / Frame Loader
Security Origin (DOM/Ajax)
Cookie Origins
HTTP Request/Response
handler
Implementation
Modified the origin policy itself to work using originIDs (approach 1)
Cookies Origin specified with a URL (domain +
path) Work ongoing
Evaluation
Used test pages to allow collaboration of DOM from different origins
Real pages: cnn.com Uses document.domain to allow
cooperation between different frames Disabled document.domain▪ Parts of page missing
Used proxy to add originID headers on the fly▪ Page loading fine again
Future plans
Thoughts about implementation in another browser like Chromium
Completing the implementation
Evaluating each of the applications of the work
