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

On Mon, 7 Jan 2013, Boris Zbarsky wrote:
> On 1/7/13 6:41 PM, Ian Hickson wrote:
> > Most things don't have an origin.
> 
> Pretty much everything has an origin in practice: it's associated with 
> some Window, hence can be treated as having the same origin as that 
> Window.

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.


> > Origin checks are only done in some very specific places where you try 
> > to get an object's properties; what we're saying here is that for 
> > those properties, you also need to do the check when you run the code 
> > behind those properties (e.g. call a method), against the "this".
> 
> I'm not quite sure we're talking about the same thing here.  Can you 
> give an example of what you're thinking?

Suppose you try to get the property from a Document whose origin doesn't 
match your script's origin.

Right now, this throws a SecurityError, because of:

# User agents must throw a SecurityError exception whenever any properties 
# of a Document object are accessed by scripts whose effective script 
# origin is not the same as the Document's effective script origin.
 -- http://www.whatwg.org/specs/web-apps/current-work/#security-document

The check we need to add is for when you actually invoke the properties, 
in case you got the property from another Document and then apply it to 
this one. The check is the same -- if the Document that is the "this" to 
which the property is being applied doesn't match the origin of the script 
that is doing the applying, throw SecurityError.


> What _I'm_ thinking is that there needs to be a security check when 
> someone does 
> Document.prototype.getElementsByTagName.call(subframe.contentDocument). 
> This is not the same security check as the one performed by 
> subframe.contentDocument.getElementsByTagName (note lack of call; it 
> never gets that far in the cross-origin case).  This is independent of 
> whether we're doing security checks on all property access or on some of 
> them.

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) 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.)

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.

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.


> Implementing different security models on the IDL level is a footgun of 
> enormous size.  We should simply have IDL methods throw if called with 
> not-same-origin "this" or arguments, except for a whitelist.

Except for having to define the origin of things for this purpose, yes, 
that's what I'm essentially saying.


> Not that we can have the argument about which interfaces are subject to 
> this security check if you want to only limit it to some objects; or 
> example you could argue that this is only needed on Window, EventTarget, 
> Document, Node, and a few others.  That's a separate argument from 
> whether the security checks for those interfaces should be opt-in or 
> opt-out.

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). 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.

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

Received on Tuesday, 8 January 2013 04:28:43 UTC