Vaibhav Rastogi and Yi Yang

 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

 Web 2.0 – rich applications  An abstraction that solves many problems with one shot  A simple change that provides a solution to many problems

 Third party JavaScript  Ads, gadgets, widgets, Facebook Applications  Restrict interaction with the host website  Problem  Essentially of maintaining different origins

 Solution  SOP assigns the same origin  WebSandbox, AdSafe. ▪ Complex solutions ▪ Performance problems  More natural solution  Have a different origin

 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

 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

 Opening two Gmail accounts in one browser without hassle  Current solutions are tricky

 Cookies play an important role  Cross domain sharing  Eg. google.com and mail.google.com  Cross site sharing  Eg. cnn.com and twitter.com

 Compared to the current sharing mechanisms, our originID approach  Less workload  More secure  Fine-grained origins  Consistent principle labeling

 DOM  Cookies  AJAX  Others, like history, display…

 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

 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

 Two approaches for representing origins 1. A four tuple 2. A random string originID = “20-9fkd9kw9j3030d9g0425d“ ▪ analogous to session cookies  Approaches are lightweight

 Resources to be shared are placed in the same origin

 Resources to be separated are placed in different origins

 If no origins are specified the default is the prevalent Same Origin Policy  Current websites do not break

 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

 Attacks by using legacy origins  Solution: Disallow interaction of pages with origin with pages using legacy SOP

 Allowing Specification of origin in  HTML  HTTP headers originID :  Disabled document.domain

 WebKit Implementation Document HTML Parser Frame / Frame Loader Security Origin (DOM/Ajax) Cookie Origins HTTP Request/Response handler

 Modified the origin policy itself to work using originIDs (approach 1)  Cookies  Origin specified with a URL (domain + path)  Work ongoing

 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

 Thoughts about implementation in another browser like Chromium  Completing the implementation  Evaluating each of the applications of the work