1. Vaibhav Rastogi and Yi Yang

2.  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

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

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

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

6.  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

7.  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

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

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

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

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

12.  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

13.  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

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

15.  Resources to be shared are placed in the same origin

16.  Resources to be separated are placed in different origins

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

18.  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

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

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

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

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

23.  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

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