- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 20 Nov 2012 02:20:11 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Johnny Stenback <jst@mozilla.com>, Bobby Holley <bobbyholley@gmail.com>, Adam Barth <w3c@adambarth.com>
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