On the incoherencies in web browser access control
On the Incoherencies in WebBrowser Access Control Policies Author: Kapil Singh and Others PPT made by : Prosunjit Biswas
Focused Major Problems• Inconsistent Principal Labeling• Inappropriate handling of principal label changes• Disregard of the User Principal This paper does not really define what the mean by principal in the context of web browser
Inconsistent Principle Labeling• For DOM resource Principal is defined by – <Protocol, domain, port>• For Cookie Resource, principal is defined by – <domain, path> Comment: The cookie resources are also under the policy of SOP. But cookie was implemented in wrong fashion across browsers which is recognized as unsafe practice.
Inappropriate Handing of Principal label change• Principal label is changed dynamically by the Document.Domain property.• By principal they meant something whose identify was changed dynamically.• A principle should be identified by some unique ID should not be changed or reused.
Disregard of the user Principal• User Principle -> User of the Browser.• Some Resource should belong to user principal exclusively (Ex. Browsing history, Browser UI, etc) Seems quite valid point.
Access Control Coherency Principal• Each Shared Browser Resources should have its sharer and access control policy Defined. (Some thing we can do here. We can define possible label of principal and zone of resources )• Non Shared Resource should either be only accessible by its owner principal or globally accessible.• Two Resource can Interplay when they have same principal definition.• All access Control policy should consider runtime label of principals• User Principal resources should not be accessible by web applications.
Resources Interplay violating Principal Definition/ Restrictions• 1) DOM and Cookie Interaction• 2) Cookie and XMLHTTP Request• 3) DOM-Display
DOM & Cookie Interaction• Cookie are accessible From JS through Document.cookie.• Cookie does not differentiate protocol definition (ex. http, https) which exposes cookie to be set by different services ( on different port) of the same domain. Secure cookie solve this problem (which is only accessible by https protocol).• Multiple cookie can be set with same name and same domain property. Which leads to inconsistencies in browser state.
Cookie & XmlHttpRequest• Secure cookie is not supposed to be read from JS , although XmlHttpRequest could read cookies by getResponseHeader method. This problem has been solved by by browsers individually ( ex. Firefox) by disallowing any reading of cookie from XmlHttpRequest objects.
DOM & Display• Multiple Principal interacting in same window – Ex: Parent window and Descendant window (an Iframe). Parent window can access any component from Descendant window violating SOP. – Interference of parent & Descendant at pixel label leads to ClickJacking attack. – Something we can do here. Can we name each resource ( Both DOM & BOM & JS) as WindowId/DocId/Origin /SubDom*/ResourceID – They can access each other if the prefix of ResourceId of the two resource are same.
Effective Principal ID Inconsistency• Cookie & DOM access inconsistency – If we change Principal ID ( Document.domain) of a page, the page is not accessible through DOM any more, but the cookie still accessible because the change is not reflected in Cookie.
Effective Principal ID Inconsistency• PostMessage, Storage Vs. DOM access Inconsis – DOM considers the change of Document.domain while PostMessage & Storage( Local & Session) does not consider change by document.domain. – This leads to inconsistencies.