1 / 33

On the Incoherencies in Web Browser Access Control Policies

IEEE Symposium on Security and Privacy, Oakland, CA, May 17-20, 2010. On the Incoherencies in Web Browser Access Control Policies. eKapil Singh , Alexander Moshchuk , Helen J. Wang and Wenke Lee Georgia Institute of Technology, Atlanta, GA Microsoft Research, Redmond, WA. by Mike Hsiao.

donkor
Download Presentation

On the Incoherencies in Web Browser Access Control Policies

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. IEEE Symposium on Security and Privacy, Oakland, CA, May 17-20, 2010 On the Incoherencies in Web Browser Access Control Policies eKapilSingh, Alexander Moshchuk, Helen J. Wang and WenkeLee Georgia Institute of Technology, Atlanta, GA Microsoft Research, Redmond, WA by Mike Hsiao

  2. Outline • Introduction • An Analysis of Browser Access Control Incoherencies • The WebAnalyzer Measurement Framework • Experimental Results • Discussion and Limitation • Related Work • Conclusions On the Incoherencies in Web Browser Access Control Policies

  3. I. Introduction • A unique contribution of this paper is to identify the compatibility cost of removing these unsafe browser features. • Web browsers’ access control policies have evolved piecemeal in an ad-hoc fashion. • To do this, the authors have built WebAnalyzer, a crawler-based framework for measuring real-world usage of browser features, and used it to study the top 100,000 popular web sites ranked by Alexa. • Their methodology and results serve as a guideline for browser designers to balance security and backward compatibility.

  4. Introduction (cont’d) • Web browsers have gradually evolved from an application that views static web pages to a rich application platform on which mutually distrusting web site principals co-exist and interact. • Browsers’ access control policies have also been evolving. • Unfortunately, this happened in a piecemeal and ad-hoc fashion alongside the introduction of new browser features (AJAX, local storage, …). • Consequently, incoherencies in browsers’ access control policies exist. • The authors would like to uncover and analyze the incoherencies, and measure the cost of eliminating them in today’s web.

  5. Introduction – access control policy Principal and domain are interchangeable. H. Wang (SOSP’07) • An access control policy configures how a principal accesses certain resources. • how principals are identified • how resources are labeled with principal IDs • how these labels may be changed and handled • The authors focus on three major sources of these problems • inconsistent principal labeling • inappropriate handling of principal label changes • disregard of the user principal

  6. Introduction – inconsistent principal labeling • Today’s browsers do not have the same principal definition for all browser resources • Resources: Document Object Model (DOM), network, cookies, other persistent state, and display. • Take DOM resource for example, a principal is labeled by the origin defined in the same origin policy (SOP) in the form of <protocol, domain, port> • But for the cookie resource, a principal is labeled by <domain, path> • Forexample, when cookies became accessible through DOM’sdocument object, DOM’s access control policy, namely the SOP, undermines some of cookie’s access control policies.

  7. Introduction – inappropriate handling of principal label changes • A web application is allowed to change its principal’s label at runtime by document.domain • a.abc.com can be changed to abc.com • but abc.com cannot be changed to xyz.com • Nevertheless, the access control state is often kept static and it leads to access control incoherencies.

  8. Introduction – disregard of the user principal • The author introduce the concept of a user principal in the browser setting. • The user principal represents the user of a browser. • Certain resources should belong to the user principal exclusively. • Clipboard, geolocation, user actions (navigation, history) • These resources should not be accessible by web applications without user permission. • Unfortunately, today’s DOM APIs expose some of these resources to web applications.

  9. WebAnalyzer • A scalable, crawler-based browser-feature measurement framework • It can inspect web pages by rendering them in instrumented browsers (IE, Firefox, Chrome). • WebAnalyzer • captures the DOM interactions of a page by interposing between the JavaScript engine and the DOM renderer, • captures the protocol-level behavior through an HTTP proxy • analyzes the visual appearance of a page by extracting its page layout.

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

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

  12. Analysis Process • The authors look for violations of these principles and check for incoherencies when violations take place.

  13. Browser Resources • Shared? Non-shared? • A DOM object is a memory resource shared among principals labeled with SOP origins, namely, <protocol, domain, port>. • A cookie is a persistent state resource. The principal is labeled with the host name and path, but without the protocol and the port number • Local storage is the persistent client-side storage shared among principals defined by SOP origins.

  14. Browser Resources (cont’d) • Session storage is storage for a tab. • Each tab has a unique set of session storage areas, one for each SOP origin. • The sessionStorage values are not shared between tabs. • The lifetime of this storage is the same as that of the tab. • Display • A web site principal delegates its display area to another principal in the form of cross-domain iframes (or objects, images). • Such an iframe (window) is co-owned by both the host page’s principal, called landlord, and the nested page’s principal, called tenant (both labeled with SOP origins).

  15. Access Control Policy For A Window’s Landlord and Tenant • Display

  16. Browser Resources (cont’d) • XMLHttpRequest allows a web site principal to use scripts to access its document origin’s remote data store by issuing an asynchronous or synchronous HTTP request to the remote server. • Some propose XMLHttpRequest2 and XDomainRequest to break SOP. • PostMessage is a recently proposed client-side cross origin communication mechanism that is now implemented in all major browsers.

  17. The interplay of the resources – DOM and Cookies

  18. The interplay of the resources – Cookies and XMLHttpRequest • Cookies and XMLHttpRequest interplay because XMLHttpRequest can set cookie values by manipulating HTTP headers through scripts. • XMLHttpRequest’s owner principal is labeled by the SOP origin, while cookie has a different principal definition. • If a server flags a cookie as “HttpOnly”, the browser prevents any script from accessing the cookie using the document.cookie property. • But certain methods of the XMLHttpRequest object facilitate access to cookies.

  19. The interplay of the resources – DOM and Display • One incoherence takes place on URL location of a window. • Example • An attacker site nests a legitimate trading site as its tenant. • The trading site further nests an advisory site and uses a script to interact with the advisory window to issue trades to the trading site backend (e.g., making a particular trade based on the advisory’s recommendation shown in the URL fragment). • With just one line of JavaScript, the attacker could navigate the advisory window (which is a descendant) and create unintended trades.

  20. The effective domain does not change for cookie access, the page still maintains access to the cookies belonging to its original domain. Effective Principal ID - Cookie

  21. Change of origin for scripts does not change the effective principal ID for XMLHttpRequest usage Effective Principal ID - XMLHttpRequest

  22. postMessage also ignores any document.domain changes:if x.a.com changes domain to a.com and sends a message to y.b.com, y.b.com still sees the message’s origin as x.a.com. Effective Principal ID - postMessage

  23. The User Principal • User actions • focus, blur, click, history (back, forward) • Browser UI • moveTo, resizeTo, open, close; multiple tab? • User-private State • Clipboard: window.clipboardData.getData("Text") • Geolocation: navigator.geolocation

  24. III. WebAnalyzer Measurement Framework Top 100,000 NOT browser-centric! IWebBrowser2 simulate a click on at most five random links Snapshot every 5 seconds

  25. IV. Experimental Results - Overview • Site • 100,000 most popular site ranked by Alexa, as seen on November 2009. • Compatibility Cost • The authors conservatively assume that disallowing a feature will significantly hinder a site’s functionality, whereas it could simply cause a visual nuisance. • High-level results • 89,222 out of 100,000 • DNS lookup failure, no JavaScript, 404 error, response time over 2 minutes

  26. Experimental Results - interplay • 81% of the web site reads document.cookie; 76% write. • 67% of sites use Cookie’s domain attribute; 46% changes it. • 5.48% sent HTTP cookies over HTTPS. • 0.07% set secure flag in Cookie. • 16.2% use HttpOnly cookies.

  27. Experimental Results - interplay • 7.7% iframe navigation. • All child navigation; no descendant navigation. • 41% at least has one iframe; the average number is 3.2. • 6.2% contain at least one overlapping pair of iframes. • 29% transparent iframes; 1.2% cross-origin. • Most of them are ads banners • 0.3% interplay between cookie and XmlHttpRequest.

  28. Experimental Results – change principal ID • In Section II-D, we showed that document.domain is an unsafe and undesirable part of today’s web. • 1.9% change document.domain • 1.76% access cookie after changing domain • 0.08% use XMLHttpRequest after changing domain; 0% postMessage. • Disallowing document.domain has low cost.

  29. Experimental Results – user • 1.8% color link • 2.6% focus-changing • 3.2% steeing top level window location • 149 sites (0.17%) already use the new Geolocation. • 5% use JavaScript within CSS.

  30. Experimental Results – other • Fragment identifier 3.8%. • 0.95% use postMessage (HTML5) • Another safer alternative for cross-domain communication, XDomainRequest, is also being slowly adopted (0.14%). document.domain Fragment identifier Post Message

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

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

  33. VII Conclusions • Examining the current state of browser access control policies and analyzed the incoherencies. • inconsistently labeling resources with principal IDs, • inappropriately handling principal identity changes via document.domain • neglecting access control for certain resources belonging to the user principal • It provides the much-needed answer to the browsers’ compatibility vs. security dilemma by identifying unsafe policies that can be removed with little compatibility cost.

More Related