Re: resolving references when object from other security context is in scope

On 6/7/13 7:27 AM, Hallvord Reiar M. Steen wrote:
> The browsers I test with differ and I'm not sure if this is covered by
> any spec, so it's a bit hard to decide what the right pass condition is.

Thank you for bringing this up.  This would be great to have test 
coverage for, especially because at least some UAs have bugs in this 
area.  :(

The only spec that even tries to cover this is the whatwg/html5 spec, in 
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#security-document 
and 
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window 
and 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location

The problem is that it does so in a very handwavy manner, which means 
that it doesn't really allow answering questions like your question with 
"with".

I think the right way to go is to define the behavior of these 
cross-origin object references in terms that an ECMAScript 
implementation would understand (e.g. [[GetOwnProperty]] and 
[[DefineOwnProperty]] or the like), and then the rest of the behavior 
will fall out of that, for the cases you're trying to test.  For actual 
DOM methods/getters/setters called via .call or .apply there need to be 
additional checks on "this", of course.

> var variableInParent=1;
> with(iframe.contentWindow){
>      variableInParent++;
> }
>
> In this case, some browsers throw and some browsers permit referencing
> the variable in the global scope.

Yeah, this is not defined anywhere, and should be.

> Also, defining new variables in the with block that previously exist
> neither in the global scope nor in the IFRAME's shows inconsistency
> across browsers:
>
> with(iframe.contentWindow){
>      previouslyUndefinedVariable='test';
> }
>
> Those browsers that throw for the second sample above also throw for
> this. (This does seem a bit concerning because in those browsers this
> can be used to spy on what *names* another site has defined in its JS.

I'm not sure I follow.  It sounds like they throw no matter whether 
"previouslyUndefinedVariable" is defined in iframe.contentWindow or not, 
right?  Or am I misreading something?

> Is there any spec I can read to figure out what the right behaviour is?

There isn't.  One needs to be written.

-Boris

Received on Friday, 7 June 2013 15:56:08 UTC