- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 4 Apr 2012 11:20:37 -0700
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
Received on Wednesday, 4 April 2012 11:20:37 UTC