[whatwg] Disabling document.domain setting on iframe at sandbox (especially with allow-same-origin)

[Ian Hickson]

On Fri, 2 Aug 2013, Boris Zbarsky wrote:
> On 8/2/13 6:55 PM, Ian Hickson wrote:
> > How does it solve it? (What _is_ the "mail.google.com vs 
> > calendar.google.com case"?)
> 
> The case is when mail.google.com tries to attack calendar.google.com, 
> and they can't be in different processes as mitigation because you never 
> know when they'll both set domain to "google.com"...

Ah, ok. It's clearer to describe that as the "victim.example.com vs 
hostile.example.com" case, since the fact that calendar.google.com 
redirects to www.google.com and mail.google.com doesn't is mostly just an 
accident of history at this point.

Yes, the model I described in es-discuss doesn't attempt to mitigate that 
case. It groups similar-origin browsing contexts that share an event loop. 
It has the advantage (over models that do mitigate that specific case) 
that it happens to be compatible with the legacy security model (the one 
implemented, until recently, by all browsers); it has the disadvantage 
that near siblings, origin-wise, only have one level of protection against 
each other, not the full defense-in-depth. Honestly, though, at the point 
where you're able to trick a similar-origin site into changing 
document.domain so you can attack it, it's not clear to me that the extra 
level of defense is worth much. You can already, e.g., do XHR to the other 
origin, at that point, or read or write to its localStorage, or read its 
cookies, or send postMessage() with their origin credentials, or speak to 
their workers. I dunno, it seems like the fact that you can't get to 
objects in other iframes of that origin at that point is mostly moot.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'