[whatwg] Need to define same-origin policy for WebIDL operations/getters/setters

[Ian Hickson]

On Tue, 8 Jan 2013, Boris Zbarsky wrote:
> On 1/7/13 11:28 PM, Ian Hickson wrote:
> > Per spec, even Windows actually don't have an origin. Things that have 
> > origins are URLs, Documents, images, audio and video elements, fonts, 
> > and scripts. Many of those things can have origins that are not that 
> > of the most obvious related (or in some cases any) Document.
> 
> Yes, I know what the spec says.
> 
> What I'm saying is that the spec is not doing anyone any favors by using 
> "origin" to mean different things for different objects.

I don't think it "means different things", but I guess that's semantics.


> In particular, for images/audio/video the "origin" in the spec is the 
> origin that's relevant for the _data_, not necessarily for the element 
> itself.

In the spec's security model, origins are never relevant for elements 
except when we're looking at the element's data.


> > Right. Specifically, the new security check (for compat we still need 
> > the old one too, though I guess in many cases it's now redundant)
> 
> It's not redundant, because nothing says that 
> subframeDoc.getElementsByTagName is actually the WebIDL-defined method; 
> it could be something the script in the subframe set up.  So you have to 
> block access to it no matter what.

Agreed; by being redundant in many cases I didn't mean that we could do 
away with it, just that in many cases you effectively have to do the check 
twice (since in most cases the property isn't overridden).


> > needs to be in getElementsByTagName()'s definition or in call()'s 
> > definition. (If the latter, we also need to put it in a number of 
> > other places, like the stuff that interacts with getters/setters.)
> 
> I would vastly prefer that this check be in the definition of the 
> [[Call]], because then it can be done on the binding level, when you're 
> checking the this object anyway.

Doing it in [[Call]] and the various equivalents for IDL attributes would 
be fine by me.


> > So e.g. we could put it in "call()" and define it as checking whether 
> > you can obtain the property on the target object before actually 
> > executing any code.
> 
> Is that actually needed?  There are properties you can obtain on objects 
> cross-origin (like window.top) that I see no need to allow via this 
> backdoor since no content depends on it now.  So I would prefer simply 
> checking whether the origin of the caller matches the origin of "this".

Well right now "this" doesn't necessarily have an origin. Also, consider 
Location. If you have a Location object and then navigate its browsing 
context and then call something on it, you need to check that the calling 
script doesn't match the origin of the new active document, not the origin 
of the Location object's Window's Document.


> > I don't want us to literally put the checks (in the spec) in each 
> > method / property of the four objects with these checks (Document, 
> > Window, Location, Storage), since that's a _lot_ of places to put 
> > these checks. We could put them in prose in the same places that have 
> > the "access" checks now. Or we could put them elsewhere. Where the 
> > current checks are makes the most sense to me, but I'm not sure 
> > exactly how to phrase them.
> 
> Or you could spec what Gecko does, which is that any WebIDL call gets 
> such a check, and then it's just defined in WebIDL.  ;)

Doing a check on _every_ call seems rather expensive for implementations 
that don't use Gecko's security model compared to only doing a check on 
those interfaces that matter.


> Given any script-exposed object, it already has to be associated with a 
> specific global.  WebIDL makes this a requirement, since you have to 
> find the right prototype object for it.

A Location object has multiple prototypes (one for each origin that 
accesses it).


> At that point, you have a Window to work with, and a Window has an 
> associated Document, and that has an origin.  For object-access checks 
> (again, as opposed to data-access checks), this is the right origin to 
> use.

For Storage, the access check has to be the actual origin of the Document, 
not the effective script origin as it does for Window and Document.


> > I don't see why EventTarget would be subject to this (it's implemented 
> > by things that need checking, but presumably everything that's 
> > implemented in that way should just be handled by that host interface 
> > the same way as everything on that host interface that isn't white 
> > listed).
> 
> EventTarget isn't implemented.  It's inherited from.

You're right, my bad.


> > The only interfaces that are of interest here (that need them and 
> > their inherited and implemented interfaces checked) are Document, 
> > Window, Location, and Storage. At least, in the HTML spec, as far as I 
> > can tell.
> 
>   var myGetter = Object.getOwnPropertyDescriptor(Node.prototype,
>                                                 "firstChild").get;
>   var node = myGetter.call(crossOriginDoc);
> 
> This should throw; we agree on that, right?

Assuming the script's effective script origin is not the same as the 
crossOriginDoc's effective script origin, it doesn't matter _what_ 
myGetter points to. It should always throw, either TypeError (or some 
such) if myGetter points to something that's not on Document somehow, or 
SecurityError, if myGetter points to something that _is_ on Document. 
Doesn't matter if it's actually from Node, Document, EventTarget, 
GlobalEventHandlers, XPathEvaluator, any of the partial document 
interfaces, etc; all that matters is that it wouldn't throw TypeError and 
would throw SecurityError if you tried to get it straight of the prototype 
of crossOriginDoc.


> So I'm not sure what we're disagreeing about here.

I'm not really disagreeing with anything. :-)

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