Vaibhav Rastogi and Yi Yang

 Web 2.0 – rich applications  A website hosts content it may not be responsible for  Third party gadgets  Third party libraries  2 websites want to enable sharing of a script  Allow a script hosted on one site access other scripts

 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

 The mechanism for sharing should  Same for all resources  Extensible to new resources  Current consideration of resources  DOM objects  Cookies  Network access – AJAX  JavaScript functionality  Others such as display, clipboard, history

 Origins depicted by   Allow origins to be specified at arbitrary levels of granularity  In HTML, originID may be included as attributes …  With each origin is a policy file associated with a server

 If no origins are specified the default is the prevalent Same Origin Policy  Current websites do not break  An origin is inherited from the parent if no origin is specified

 Server side resources  HTML, CSS, JavaScript  Server supplies the originIDs and policies  Generated resources  DOM and JS objects  AJAX  Origins normally inherited from server side resources ▪ More finer grained policies may still be specified

 Finer grained origins  No XSS  The default policies of not associating any origin with a script makes XSS impossible

 Tamper proof  Non forgeable  Attacker should not be able to change or add origins  Non repudiation  Host cannot repudiate setting up of origins  May not be required

 Public Key Infrastructure  Similar to SSL  MAC(resource|originID) specifies the actual origin  Heavy weight  Requires every website to use SSL type PKI

 What makes a good string representation of a resource?  Do policy files themselves need to be secured?