[whatwg] Proposal: location.parentOrigin

On Wed, Apr 4, 2012 at 11:20 AM, Adam Barth <w3c at adambarth.com> wrote:
> 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.

I should note that WebKit already implements location.origin (and
HTMLAnchorElement.origin), which returns the Unicode serialization of
the URL's origin.  If we go with the array approach, we might want to
add the plain origin property to the spec as well (with the normal
security rules).

Adam

Received on Wednesday, 4 April 2012 15:22:25 UTC