Re: [whatwg] Location object identity and navigation behavior

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

Received on Tuesday, 20 November 2012 19:31:58 UTC