Proposal: Security checks after same-origin revocation with document.domain

Hi,

I'm writing to propose a spec change with respect to the security checks
performed on cross-origin DOM property access. I'm basing this on the
discussion here:
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0020.html

The DOM security model uses set of white-listed objects and properties for
cross-origin access. In general, only the Window, Location, and Document
objects can be reached. So whether or not security checks are performed for
other objects is generally not script-visible, and thus, for the most part,
a detail of the implementation.

This is good, because different implementations have reasons for performing
or not performing checks on arbitrary objects. WebKit and IE, if I
understand correctly, skip them for performance reasons. For Mozilla, on
the other hand, these checks are a very fundamental part of Gecko's
security architecture. We compartmentalize scopes into different heaps, and
then enforce static security policies at the boundaries. Having arbitrary
cross-origin access deny-by-default prevents third-party addons from
introducing a certain class of security vulnerabilities, and is generally
useful for defense-in-depth.

In an ideal world, we could all do our own thing here. Unfortunately,
there's one situation where this behavior _is_ script-visible. That
situation arises with document.domain. If two same-origin scripts become
cross-origin via document.domain, one script could have grabbed
document.firstChild from the other scope before the revocation occurred.
What happens next depends on the application of security checks to
arbitrary objects. Per spec, document.firstChild becomes a back door into
the other scope, granting unfettered access as long as the script is
careful enough to avoid touching Window, Location, and Document.

I think this is suboptimal behavior. If we value revocation enough to spec
it, we shouldn't allow it to be circumvented so easily. Under the current
model, a non-malicious script could accidentally compromise its initial
origin A when setting document.domain to a less-friendly origin B if it
happened to hold a reference to an object from another scope in A.

This is a pretty special case, so I don't imagine that anyone will redesign
their engine around it. But in order to achieve uniform behavior, somebody
will need to special-case the document.domain situation. If this somebody
were Mozilla (which it is, under the current spec), I would probably add
some sort of transitive DocumentDomainSecurityHolePreserver that waives
security checks for objects that used to be same-origin before
document.domain changed, and all objects reachable from those objects.
Special-casing things to make them insecure is not ideal, so I'd prefer if
other vendors could special-case document.domain to keep things secure. I
don't imagine it would have a noticeable performance impact if done
correctly, and it would leave the Web in a better place.

Cheers,
Bobby Holley, Mozilla