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

On Fri, 2 Aug 2013, Boris Zbarsky wrote:
> On 8/2/13 10:35 PM, Ian Hickson wrote:
> > Honestly, though, at the point where you're able to trick a 
> > similar-origin site into changing document.domain so you can attack it
> 
> document.domain was not involved in any way in the cross-site issues 
> I've pointed out to you recently.

Sure. I was talking about the script-visible difference in the models, as 
opposed to the defense-in-depth aspects. My argument is that not having 
the defense in depth in the limited case of similar-origin frames is the 
cost of having defense-in-depth for all the other cases without any 
script-visible differences in the overall model. The question of whether 
this is a trade-off that's worth it or not is the question that decides 
what model the spec will follow -- right now, only Mozilla has indicated 
that this is a trade-off that is worth it, with all the other browsers 
instead following a process isolation model that, in its logical extension 
to origin isolation, only protects up to the similar-origin barrier (and 
in the meantime, doesn't protect at all).


On Sat, 3 Aug 2013, David Bruant wrote:
>
> Indeed and that's the reason what I describe works I believe. Let's say 
> we have pages from 2 domains "a.example.org" and "b.example.org". One 
> has an iframe to the other. iframe process isolation is not possible, 
> because at any point, both could set their domains to "example.org" (or 
> process isolation is possible, but the deoptimization would have a 
> violent cost)
> 
> "a.example.org" can sandbox the iframe to "b.example.org" and process 
> isolation becomes possible again, because the parent and iframe are 
> guaranteed to be of a different origin. However, this looses the origin 
> of the iframe which breaks localstorage, etc. This can be solved with 
> allow-same-origin, but process isolation is lost back because we're 
> pretty much back in the previous case.
> 
> What I'm suggesting is the following: poison the document.domain setter 
> in sandboxed iframes regardless of whether there is allow-same-origin. 
> This way, in the "a.example.org"/"b.example.org" case, the iframe can be 
> process isolated (because guaranteed to be of a different origin). This 
> also applies to "example.org" with a "b.example.org" iframe. The only 
> case this doesn't allow to optimize is "a.example.org" with an iframe to 
> "example.org", where "a.example.org" might set document.domain to 
> "example.org".

On Sat, 3 Aug 2013, Boris Zbarsky wrote:
> 
> It doesn't matter, because _both_ have to set document.domain.  As in, 
> a.example.org setting .domain to "example.org" does not make it 
> same-origin with example.org unless the latter also explicitly sets 
> .domain to "example.org".  Which we would disallow in sandboxed iframes.

On Sat, 3 Aug 2013, David Bruant wrote:
>
> oh ok. I guess I misunderstood the spec after all, but that supports the 
> idea of poisonning the document.domain setter, yay!

I'm certainly open to the idea of making document.domain not work in 
sandboxed <iframe>s. Any objections? Who is ready to implement this?

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

Received on Thursday, 8 August 2013 21:36:10 UTC