[whatwg] Location object identity and navigation behavior
ian at hixie.ch
Tue Nov 20 09:46:38 PST 2012
On Tue, 20 Nov 2012, Boris Zbarsky wrote:
> 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.
I would certainly be interested in concrete examples of this. I would be
shocked if such sites weren't already vulnerable to something or other.
> 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.
non-symmetric model work. JS just allows too much introspection. Any time
you pass a string from one to the other, you're also passing a way for the
callee to call back into the caller, for example (via the string's
methods). Passing any sort of structured objects similarly means passing
mehods. Callbacks are also a very widely used pattern.
We have mechanisms for safe passing of data from one context to another,
such as postMessage(). Doing it by having one-way glass in JS just seems
like asking for trouble.
> 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.
Yeah, like running getters with the ability to abort them if they don't
> 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
> 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,
I'd go even further. Debuggers are a rare exception, IMHO, which can't be
fully specified because the whole point is that they want to examine
everything that _is_ specified. I have no problem leaving the specific
case of debuggers, profilers, and similar development tools out of what we
need to specify to get interoperability.
But your underlying point, that we can't rely on the entry script and the
real origin, is sound. In particular, anything that's to be affected by
document.domain has to use the calling script, not the entry script, and
has to use the effective origin, not the real origin. It would be useful
if someone (other than me) were to review the spec's uses of the term
"entry script" and "origin" and verify that the checks all make sense.
Anyway, we're kind of getting away from the original topic here, which
isn't fully resolved; Location.
In thinking about this further last night, it struck me that while the
proposed proxy mechanism was IMHO overly complex, there might be a simpler
mechanism that still gets all the compatibility needs, and works for
Mozilla, and isn't quite so crazy. I'm not a huge fan of this, but I'd be
interested in what Adam thinks of it.
Right now, as specced, each Document gets a Location object, but they all
act the same: they all work on the active document and they all do
security checks based on the active document, not the Location's Document.
But what if, instead, we had one Location per Document, and it worked on
that Document (not the active document), with the security policy being
like Window, specific to its Document's effective origin, but instead of
ever getting references to it, you only got references to a proxy that
acted on the active document's Location?
Then you wouldn't need to do anything with properties added by the author,
either, they'd just work normally (like on Window).
I'm not a big fan of this, but if this simplified model works for WebKit,
maybe it's worth it?
It's still less intuitive than just having unique Location objects,
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg