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
