1. On the Incoherencies in Web
Browser Access Control Policies
Author: Kapil Singh and Others
PPT made by : Prosunjit Biswas

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

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

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

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

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

7. Browser Resources

8. Resources Interplay violating Principal
Definition/ Restrictions
• 1) DOM and Cookie Interaction
• 2) Cookie and XMLHTTP Request
• 3) DOM-Display

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

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

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

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

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