[whatwg] Disabling document.domain setting on iframe at sandbox (especially with allow-same-origin)
Ian Hickson
ian at hixie.ch
Thu Aug 8 14:35:46 PDT 2013
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list