On 11/20/12 2:38 AM, Ian Hickson wrote:
IMHO there's no point us trying to keep things locked down when you set
document.domain.
I believe sites actually rely on a certain amount of lockdown in
situations like this... Adam can fill you in, I'm sure.
But in general, as people work more and more on Widgety and Appy stuff
in HTML, with various expanded privileges, granted permissions, etc, the
assumption that the security model is completely symmetric just becomes
false. I'd rather we didn't paint ourselves into a corner by assuming
otherwise here and requiring behavior that UAs would simply refuse to
implement because they view it as insecure.
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?
If they're not calling each other, how are they both on the stack?
This only requires one of them calling the other. It doesn't require
"the other" being able to call back into "one".
Maybe that's not what you meant, though. So let me give you a concrete
not-exactly-hypothetical example.
Say I'm implementing a debugger in a web browser, and I implement my UI
in HTML+JS as browsers are tending to do now. When I examine properties
with scripted getters in this debugger, what should happen? I will bet
money that the debugger is not, generally, running with the permissions
of the page, because it needs to be able to do things that web pages
aren't allowed to do. However the getters in question had better run
with the permissions of the page; otherwise you open up the debugger to
attacks from the web page. This problem is not solvable using the
"separate worlds" approaches browsers use to provide extensions with an
unmodified view of the DOM, since the debugger really does want to see
what's going on in the web page itself; it just doesn't want to allow
the page to escalate permissions.
Now I know there are several possible objections to this use case, so
let me just pre-address some:
1) "It's not the web, so we don't have to specify it." That's true,
sure. I suspect as time goes on we might in fact need to specify
something like this for apps, however. And more importantly, just
because it's not the web doesn't mean UAs are not implementing it, and
if they're implementing it they need to make it work with their security
model, whatever it is.
2) "The debugger can have some magic to make it all work." Yes, but
then the question is how it interacts with the web security model and
how the result can be implemented.
3) "The debugger should set the entry script before invoking the
getter." This is a plausible approach, but it makes it very error-prone
and complicated to create things like the above-described debugger: you
have to manually keep track of which objects come from where instead of
just having the web platform implementation (which already has that
information) keep track of it for you.
4) "Entry script should always be set when crossing origins" (for some
definition of "crossing origins"). This seems plausible as well. Maybe
it's doable.
One other note: Gecko's current model is at least somewhat influenced by
the fact that in the past Gecko had expanded privileges on a
per-function basis. This obviously made using the entry script a
non-starter... Maybe it's more of a starter now. I'll let Bobby worry
about it. ;)
-Boris
