[whatwg] Proposal: location.parentOrigin

On Tue, 3 Apr 2012, Adam Barth wrote:
> On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 3 Apr 2012, Adam Barth wrote:
> >> On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> > On Tue, 3 Apr 2012, Adam Barth wrote:
> >> >> Talking with some folks off-list, there are also use cases for knowing
> >> >> the origin of the top-most document.
> >> >
> >> > Could you elaborate on those use cases? (And also those for parent.origin,
> >> > though those seem more obvious, e.g. disabling features to protect against
> >> > clickjacking in unauthorised embeddings.)
> >>
> >> The use case is the same as in the previous email, specifically:
> >>
> >> ---8<---
> >> Some widgets want to behave differently depending on the context in
> >> which they are embedded. ?For example, a payment widget might want to
> >> send the user to a confirmation page for most web sites but might be
> >> confortable with a more streamlined user experience when embedded on a
> >> whitelist of sites with which they have a contractual relationship.
> >> --->8---
> >>
> >> The payment widget might care about all of its ancestors. ?For example,
> >> suppose the payment operator has a relationship with store.example.com.
> >> They might wish to fall back to using a confirmation page if
> >> store.example.com is embedded as a frame in another web site (e.g.,
> >> pintrest).
> >
> > Why don't they just ask the parent frame for their parent's origin, since
> > they trust them?
> 
> From my original email:
> 
> ---8<---
> 3) The widget could use postMessage to communicate with the embedder
> and to establish the origin of the embedder.  However, this requires
> running code in the embedder that knows how to respond to the messages
> appropriately.  If the widget provider supplies the code, then the
> embedder needs to trust the widget provider to run code in its origin,
> which is undesirable.  If the embedder provides the code, then that
> greatly increases the complexity of embedding the widget (see 2(b) for
> a related discussion).
> --->8---

(This is what I get for jumping in a thread half-way rather than doing my 
usual "wait til the end and read everything then reply to everything"...)

So is there any concern that there might be a hostile origin between a 
trusted top-level origin and a trusted parent origin?

   Top-level browsing context: victim-of-injection.example.org
   Contains: evil.invalid
   Contains: victim-host-of-victim-of-clickjacking.example.net
   Contains: victim-of-clickjacking.example.com

Should we just expose the chain of ancestor origins in an array?

My concern with exposing parent.location.origin to cross-origin frames 
based not on an origin check but on a "are you contained" test is that it 
is hard to define exactly who is allowed to access the member. For 
example, what if the entry script is actually in another window, but it 
calls a method in the iframe, and that method tries to walk the chain? 
Does it fail? What if the iframe calls a method on the window, and the 
window then tries to walk the chain? What if the window walks the chain 
without calling a method in the iframe?

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

Received on Wednesday, 4 April 2012 11:06:35 UTC