Re: [whatwg] Location object identity and navigation behavior

On 11/20/12 1:23 AM, Ian Hickson wrote:
> Could you elaborate in the bug? I've no idea what you think is wrong.

Done, but what's wrong is that the security checks described in the spec 
check the origin of the wrong document.

>> You can maintain a stack of entry scripts.  You can't use a global,
>> because you need to push and pop entry scripts as various things happen
>> (e.g. invoking event listeners sets the entry script to the event
>> listener function's script for the duration of the event listener
>> invocation).
>
> The way the spec does it, the stack is implemented as the actual call
> stack, with nested calls to "jump to a code entry-point" storing the old
> value, updating the global, running the script, then restoring the global
> to the stored old value.

Sure, that works.  One way or another, you need to have a stack.  ;) 
And if part of your WebAPI/DOM/etc implementation itself is done in JS 
you have to be careful to not update the entry-point stuff when calling 
into that JS, of course.

>> The thing that _really_ requires stack introspection is when you need to
>> look at the caller script instead of the entry script.  Which is what
>> you need to do when performing Location security checks (or indeed, any
>> security checks).
>
> Can you show an example of when that is needed?

Uh... any time you do a security check, in general.

> As far as I can tell, the entry script always has the same origin as the
> running script.

All you need for script A to be able to call script B as the spec us 
currently written is that sometime in the past the effective script 
origin of A matched the effective script origin of some script C and 
that at some point in the past (possibly a completely different point) 
the effective script origin of B matched the effective script origin of 
C (which may not have been the same at that point as when C matched A!). 
  There is no requirement that A ever matched B, or even that the sets 
of effective script origins A and B have had in the past have nonempty 
intersection.

And even that may not be true depending on whether UAs allow 
"privileged" JS in various settings.  If they do, then the entry script 
becomes very useless for origin determination unless crossing origin 
barriers resets the entry script.  Which, again, is not the case in 
Gecko right now.  But that's obviously Gecko's problem, for the moment.


> I guess this isn't necessarily true of the effective
> origin, which is what we're using for the Location object security? Is
> that the problem here?

I think the problem is that you're assuming invariants that just don't 
hold.  There is no current requirement in the spec that there be any 
relationship between either the origin or effective script origin of the 
entry script and the origins of the currently running script.

> If so, why don't we just make it be an origin check of the entry script
> instead of an effective origin check?

Because that would be totally wrong; see above.

> If that would make it simpler for Gecko

As things stand, it wouldn't, particularly.  It would actually introduce 
security bugs.

> if you have both calling each other then you can almost
> certainly trick the script into doing what you want either way.

Who said anything about both calling each other?  Gecko's security model 
is asymmetric in practice.

-Boris

Received on Tuesday, 20 November 2012 08:29:59 UTC