On the Incoherencies in Web Browser Access Control Policies

1. On the Incoherencies in Web Browser Access Control Policies Authors: Kapil Singh, et al Presented by Yi Yang

2. Outline • Introduction • Analysis of browser access control incoherencies • WebAnalyzer Measurement Framework • Experimental Results • Related work & Discussion & Limitations • Conclusions

3. Major Access Control Flaws • Inconsistent principal labeling • Inappropriate handling of principal label changes • Disregard of the user principal

4. What is a Principal • In the Web environment, principal=domain? • Principal and domain are interchangeable. H. Wang, et.al (SOSP’07) • Different labeling for resources. • for the DOM (memory) resource, a principal is labeled by <protocol, domain, port>; • for the cookie resource, a principal is labeled by <domain, path>.

5. document.domain • Gets/sets the domain of the current document. • Eg. a script in the document at x.a.com/index.htmlexecutes document.domain = “a.com”. After that statement executes, the page would pass the origin check with a.com/index.html. • However, a.com cannot set document.domain to b.com

6. Review of Access Control Flaws • Inconsistent principal labeling • Inappropriate handling of principal label changes: • Disregard the “effective” principle IDs set by document.domain. • Disregard of the user principal • eg. clipboard, geolocation, user actions, etc

7. Contributions • Principal-driven analysis of access control incoherencies in today’s browsers. • User principal concept for the browser setting. • Compatibility measurement framework----WebAnalyzer. • Measurements on the compatibility cost of coherent access control policies.

8. II. Analysis of Browser Access Control Incoherencies • Methodology • Browser Resources • The Interplay of the Resources • Effective Principal ID • The User Principal

9. Methodology • Each shared browser resource should have a principal definition and have an access control policy. • For each non-shared browser resource, the resource should have an owner principal with a specific label or be globally accessible. • When two resources interplay, both resources should have the same principal definition. • All access control policies must consider the runtime label of the principals, namely, the “effective” principal ID. • The user principal’s resources should not be accessible by web applications.

10. Manual Analysis Process

11. Browser Resources

12. Browser Resources (cont.)

13. Interplay of the Resources • DOM and Cookies • Cookies and XMLHttpRequest • DOM and Display

14. eg. DOM and Cookie

15. Effective Principal ID • Browsers allow cross-principal sharing for “related” sites by allowing sites to change their principal ID via the document.domain property. • Cookie, XMLHttpRequest, postMessage, etc

16. Cookie

17. XMLHttpRequest

18. postMessage

19. The User Principal • User actions • back(), forward(), history • Browser UI • moveTo(), resizeTo(), etc • User-private State • Geolocation is one of the latest browser features. • Geolocation dialog is active for only one origin at a time. DOS attack

20. WebAnalyzer Measurement Framework • Crawl the web to look for prevalence of unsafe browser features on existing web pages. • IEWA , a specially instrumented version of IE, provides dynamic mediation for all browser resources, and detects when a resource invocation matches one of preset policy rules.

21. Measurement Framework

22. heuristics-driven automated crawling • It’s hard to fully study all possible website features. • Simple heuristics to simulate user interaction. • find and click at most 5 random links; • produce 5 random navigation events; • check search form, fill it and submit it.

23. IV. Experimental Results • Experimental Goal: study the prevalence of unsafe browser features on a large set of popular website. • Overview • 100,000 most popular websites ranked by Alexa, 89,222 websites are available. • Cost of removing a feature to be the number of Alexa-ranked, top 100,000 sites that use the feature.

24. Interplay of browser resources summary of display

25. Changing effective Principal ID Summary: while disallowingdocument.domain completely carries a substantial cost (1.9% of sites), browsers can eliminate its impact on XMLHttpRequest, local storage, and postMessageat a much lower cost.

26. Resources belonging to the user principal Overall, we found that 12 of the 16 user-principal APIs we examined can be removed while collectively affecting only 0.80% of unique sites.

27. Unsafe features & site popularity

28. Compared with user driven analysis

29. V. Discussion & Limitations • Benefits of heuristics-driven automated crawling. • Limits of automated crawler-based measurements. • Picking the right browser. • Studying other web segments.

30. VI. Related Work • Previous work has looked at weaknesses in cross-frame communication mechanisms, client-side browser state, cookie path protection, display protection, and other issues. • DOM access checker is a tool designed to automatically validate numerous aspects of domain security policy enforcement to detect common security attacks or information disclosure vectors. • Browserscopeis a community-driven project for tracking browser functionality. Its security test suite checks whether new browser security features are implemented by a browser.

31. VII. Conclusions • incoherencies in access control policies • user principal • measured the cost of removing unsafe policies

32. Thanks