[whatwg] Proposal: location.parentOrigin

[Adam Barth]

On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson <ian at hixie.ch> wrote:
> 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?

That could work.  Using an array might be a good way to encourage
developers to check all the ancestors rather than arbitrarily picking
the parent or the top.

> 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?

When doing access checks, browsers already need to pin down exactly
which script is performing the access.  The spec doesn't get 100% of
these details correct, but normally the differences aren't observable.
 You can actually observe the difference if you plan a bunch of nutty
tricks with document.domain, but I can send an email about these
details later.

To answer your question, I would do the access check based on the
document associated with the "current script", which is the document
that contained the definition of the most recently executing
user-defined closure.  This is the security context most often used
for security checks (even though the entry script is commonly used for
things like relative URL resolution).

However, I think you're right that exposing an array is a better
approach to nudge developers into writing robust code.

Adam