1 / 25

OMash : Enabling Secure Web Mashups via Object Abstractions

OMash : Enabling Secure Web Mashups via Object Abstractions. Steven Crites, Francis Hsu , Hao Chen UC Davis. Mashups and the Same Origin Policy. Mashups integrate content from multiple websites Content protection relies on Same Origin Policy (SOP)

imala
Download Presentation

OMash : Enabling Secure Web Mashups via Object Abstractions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OMash: Enabling Secure Web Mashups via Object Abstractions Steven Crites, Francis Hsu, Hao Chen UC Davis

  2. Mashups and the Same Origin Policy • Mashups integrate content from multiple websites • Content protection relies on Same Origin Policy (SOP) • Currently, contents get complete or no isolation • MashupOS proposes more flexible trust relationship [SOSP 07] • Isolated • Open • Access-Controlled • Unauthorized

  3. Same Origin Policy Server a.com    Browser   a.com a.com b.com

  4. Problems with SOP –What Domains are of the Same Origin? Same origin? web1.acm.org web2.acm.org yes maybe ece.ucdavis.edu cs.ucdavis.edu amazon.co.uk no bbc.co.uk

  5. 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)

  6. Cross-Site Request Forgery Server a.com Browser b.com a.com

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

  8. Object Abstractions • Java (analogy) • Web page object public class FooObject { public void publicMethod() { } private intprivateData; } <html> <script> function getPublicInterface() { function Interface() { this.publicMethod = function () {…} } return new Interface(); } varprivateData; </script> </html>

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

  10. Public and Private Members • Public interface • Each object declares getPublicInterface() • Returns a closure of all public methods and data • Private data • DOM • Scripts • Credentials

  11. Usage Example • map.html • integrator.html <html> function getPublicInterface() { function Interface() { this.setCenter = function (lat,long) { … } } return new Interface(); } </html> <iframesrc="map.html"> ... var map = win.getPublicInterface(); ... map.setCenter(lat, long); } integrator.html map.html

  12. Trust Relationships • Can model trust relationships needed for mashups (as identified by MashupOS) • Isolated • Open • Access-Controlled • Unauthorized

  13. Isolated • No access between provider and integrator function getPublicInterface() { function Interface() { } return new Interface(); }

  14. Open • Full access between provider and integrator function getPublicInterface() { function Interface() { this.getDocument = function () { return document; } } return new Interface(); }

  15. Access-controlled • Limited access depending on caller Provider Integrator function getPublicInterface() { function Interface() { this.auth = function(user,pass) { return token; } this.do = function (token,...) { check(token); } } return new Interface(); } varapi = win.getPublicInterface(); token = api.auth(user, pass); api.do (token,...)

  16. Preventing CSRF Server a.com Browser a.com b.com

  17. Preventing CSRF Server a.com Browser a.com b.com

  18. Preventing CSRF Server a.com Browser No cookie! a.com b.com

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

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

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

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

  23. Supporting SOP without DNS Provider Integrator 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>

  24. Related Work • MashupOS (Wang et al, SOSP 07) • SMash (Keukelaere WWW 07) • Google’s Caja

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

More Related