Re: [whatwg] window.opener and security

[Ian Hickson]

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
>
> when a new window or tab is opened by a page it normally has a 
> "window.opener" property that points to the window object of the 
> original tab.

Indeed, this is now specced.


> If an origin check fails when comparing the locations of the old window 
> and the popup, the normal cross-domain security policies apply. This 
> means that popup contents from a different site will not be allowed to 
> call methods or manipulate the DOM of the opener.
> 
> However, this cross-domain security policy has one exception: the popup 
> may set the location of its opener. This has phishing potential, 
> particularly for webmail where opening external links in a new window is 
> a very common use case. Hence I think it would be a good idea to let a 
> site opt-out and specify that the popup should not have a window.opener 
> property. For example, one could extend the "features" argument of 
> window.open:
> 
> window.open(url, name, 'openerproperty=0');

Using window.open() for this seems silly, this should just be a link.

I've made rel=noreferrer explicitly not include the opener as well as not 
including the Referer header. Does that address your use case?


On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> (An exception is Opera applying a stricter security policy if the
> opener is an https page so in this case popup can't set location of
> its opener, but I'm not sure if the other UAs do this.)

I have not specified this, so this behaviour is currently non-compliant.


On Tue, 20 Mar 2007, Gareth Hay wrote:
> 
> I don't think you need this property, you are free to send null to the 
> child window's opener as things are now, and I would argue for making 
> the property read-only in any future spec anyway, making the UA 
> responsible for security.

Opening a window then poking with it then navigating it seems like a lot 
of effort when all you want to do is have a link open a window without it 
being associated with the opener.


On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> window.opener should be read-only and attempting to write to it should 
> throw an exception.
> 
> This is a similar issue to window.history, in certain browsers you can 
> write to this with js. It has no effect, but does persist across 
> domains. The webkit team decided to just throw an exception if a write 
> to window.history was detected. I don't know if it ever got implemented, 
> or even if any of the other browser vendors addressed it.

window.opener in WebKit seems to be replaceable.


On Tue, 20 Mar 2007, Rimantas Liubertas wrote:
> 
> It was possible to set window.opener in IE, alas, I do not remember
> which version :(
> But it has been fixed, AFAIK.

Not as far as I can tell.


On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> I don't really see why setting opener would be dangerous, so I disagree 
> that it should throw.

On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> Well, window.opener is conceptually a link from child to parent. Can you 
> give a valid use-case for adoption of the child to another parent?

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> However, here are two use cases for you:
> 
> 1) I don't want the next page to mess with opener:
> 
> window.opener=null;
> location.href='http://some-untrusted-location/';
> 
> (basically what sites should do today to work around the phishing
> potential issue, but AFAIK none do.)
> 
> 2) I have contents in an IFRAME that I want to talk directly to MY opener:
> 
> document.getElementsByTagName('iframe')[0].contentWindow.opener=self.opener;
> 
> What are your "exploit cases" where setting .opener is so dangerous
> that it should throw? Note that making it throw also means being
> backwards incompatible with
> 
> var opener='Once upon a time, ';
> 
> which might be far-fetched but certainly will exist somewhere if
> browsers haven't thrown exceptions so far.

It's not really about use cases frankly, it's more about what browsers do 
today. Use cases are nice for new features but once pages rely on what 
browsers do, things become pretty immutable.

I've filed a bug to make sure that this is fixed once WebIDL allows us to 
fix it easily. (Right now the spec says the attribute is readonly.)

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=5909


On Tue, 20 Mar 2007, liorean wrote:
> 
> The original problem is that browsers allow cross domain setting of 
> windowobject.location. Whether windowobject in this case comes from 
> window.opener isn't really relevant, except that it provides a method of 
> getting a windowobject reference.
> 
> Hallvord's solution is a workaround - it addresses the ability to get 
> that windowobject reference, even though it doesn't address the core 
> problem. [...]
> 
> A much better solution, in my opinion, would be to make the location 
> object safe from cross domain attacks by making it only writable from 
> same domain, or if the document does not have a domain yet. (window.open 
> without

Re: [whatwg] window.opener and security

[liorean]

On 20/03/07, Thomas Broyer <[EMAIL PROTECTED]> wrote:

2007/3/20, liorean:
> Some thing I would like to add here, is that your "solution" doesn't
> do anything to solve the actual l problem case. Even if window.opener
> would be read only, that is just a reference to a window object. Even
> if that property would be read only you could still write to the
> location property of the window object it references. For your
> solution to work the read only attribute would have to cascade to all
> properties, something defying the nature of JavaScript.

I'm not so sure.

And this would be similar to a node being read-only in the DOM (see
the NO_MODIFICATION_ALLOWED_ERR DOMException in
)


In the case of writing to windowobject.location, yes. Then it would
work just like that, because just like the DOM exception you talk
about, the cross domain security checks lay in a deeper layer than
JavaScript.

However, consider an access to foo.bar.baz. JavaScript will first
access the first variable foo it can find in the current scope. When
found, it will access the first bar property it can find in the
prototype chain of the object referenced by that variable. And
finally, it will access the first baz it can find in the prototype
chain of the object referenced by that property.

In other words, the access to baz will operate on an object already
extracted from the bar property of an already extracted object from
the foo variable. All of these accesses only operate on one object,
how that object was originally gotten to has already been forgotten
when that access takes place.

Similarly, for window.opener.location="http://phishing.exampe.net/evil";

1. Access the "window" variable in current scope chain.
2. Set the working object to the value of that  variable.
3. Access the "opener" property of the working object.
4. Set the working object to the value of that property.
5. Set the "location" property of that object to the string
"http://phishing.exampe.net/evil";

In this, the setting of location happens on a window object.
JavaScript has no memory of how it got that window object, so
JavaScript itself cannot treat it specifically depending on how that
was. However, the implementation of the property getters/setters in
this example can themselves apply security checks and/or give a
wrapped object with security restrictions. That's where the solution
to this fix belongs.


> A much better solution, in my opinion, would be to make the location
> object safe from cross domain attacks by making it only writable from
> same domain, or if the document does not have a domain yet.
> (window.open without address) I do think this would break some sites,
> however.

Yep, e.g. redirecting to a mirror-site.

But this is a very interesting idea (similar to XMLHttpRequest not
allowing cross-domain requests; you'd just need a page on the same
level to issue redirects at the HTTP-level to word-around that new
limitation; and this is a really sane work-around IMO).

I would personally combine both suggestions: window.opener, window.top
and other windowobject accessors return readonly objects when called
from a page within a different domain; and within the page, constrain
window.location setting (imagine someone hacks Google and adds a
window.location=XXX in Google Analytics script).


Or, they don't actually access window objects. They return security
restriction wrapper objects for those window objects, and these give
similar security restriction wrapped objects (recursively for
arbitrary depth) to all JavaScript instances not being contained in
their window object. This way the read/write access can be dynamically
changed depending on any security restriction factor. It incurs a
slight cost for all cross frame/window scripting (compared to scripts
contained in the same window object), but I would think some mechanism
like this is already in place in browsers, at least for some specific
objects.
--
David "liorean" Andersson

Re: [whatwg] window.opener and security

[Gareth Hay]

If the primary domain is www.example.com and the other domain is
help.example.com the UA clearly should allow them to communicate by
request. Believe me, nulling window.opener if origin check fails will
break MANY sites.


This is not the point I am making, and I feel we are not  
understanding one another.

I don't think I understand you, and you don't understand me.

I have personally written many applications which use window.open  
windows, iframes, and such, and have *never* needed to 'spoof' the  
browser into re-assigning a window.


The *potential* for security breach is if cross-domain scripting is  
allowed, after a user has left your site.
If the UA nulls window.opener at that point, then it won't break  
anything.
How many 3rd party websites are designed to run in a popup from  
another domain?


As I said, the WebKit folks seem to think my idea of read-only was a  
good one.



Breaking *any* website is a problem. Yes, security is important. But
this is a problem with a clear and limited (ab)use case - mainly
webmails - and we can add a feature giving those relatively few
webmail sites some easy-to-use opt-in security.


I disagree, Apache security fixes are rolled out, and the developer  
is expected to cope, PHP roll out security fixes, and the developer  
has to cope.
If the problem here is that a webmail vendor will not adjust his code  
to work in a secure environment, then I am astounded.


If this post really isn't about security, then I think you need to  
address the subject and actually detail what it is about.

Re: [whatwg] window.opener and security

[Thomas Broyer]

2007/3/20, liorean:


Some thing I would like to add here, is that your "solution" doesn't
do anything to solve the actual l problem case. Even if window.opener
would be read only, that is just a reference to a window object. Even
if that property would be read only you could still write to the
location property of the window object it references. For your
solution to work the read only attribute would have to cascade to all
properties, something defying the nature of JavaScript.


I'm not so sure.

And this would be similar to a node being read-only in the DOM (see
the NO_MODIFICATION_ALLOWED_ERR DOMException in
)


A much better solution, in my opinion, would be to make the location
object safe from cross domain attacks by making it only writable from
same domain, or if the document does not have a domain yet.
(window.open without address) I do think this would break some sites,
however.


Yep, e.g. redirecting to a mirror-site.

But this is a very interesting idea (similar to XMLHttpRequest not
allowing cross-domain requests; you'd just need a page on the same
level to issue redirects at the HTTP-level to word-around that new
limitation; and this is a really sane work-around IMO).

I would personally combine both suggestions: window.opener, window.top
and other windowobject accessors return readonly objects when called
from a page within a different domain; and within the page, constrain
window.location setting (imagine someone hacks Google and adds a
window.location=XXX in Google Analytics script).

--
Thomas Broyer

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

>> 1) Either it is your responsibility to handle the nulling of the
>> property *or*
>> 2) It is the UA's.
>
> The UA can not do this. It would break legacy pages by resetting
> window.opener if content comes from a different server.



If this is a security point, which I take from the subject
"window.opener and security" it is, there is no problem with a UA
breaking an implementation that relied on insecurity.


Breaking *any* website is a problem. Yes, security is important. But
this is a problem with a clear and limited (ab)use case - mainly
webmails - and we can add a feature giving those relatively few
webmail sites some easy-to-use opt-in security.


I can't think of a single reason that when a user navigates to
another domain, you would want that domain to access your
window.opener, so the UA clearly could do this.


If the primary domain is www.example.com and the other domain is
help.example.com the UA clearly should allow them to communicate by
request. Believe me, nulling window.opener if origin check fails will
break MANY sites.

And now I'm going to shut up. Really :)

--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Gareth Hay]

I was clearly mislead by the "window.opener and security" title then

On 20 Mar 2007, at 15:51, liorean wrote:


On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

As was clearly stated, I showed a workaround and then suggested it
should be up to the UA to handle this situation.
It is not helpful to deliberately misunderstand points, and quote
them out of context. I suggest you re-read my mail.


You showed a workaround for a different problem than that which
Hallvord initially tried to solve.

The original problem is that browsers allow cross domain setting of
windowobject.location. Whether windowobject in this case comes from
window.opener isn't really relevant, except that it provides a method
of getting a windowobject reference.

Hallvord's solution is a workaround - it addresses the ability to get
that windowobject reference, even though it doesn't address the core
problem.

On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.

I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming
correctly and using an unload to null the property when someone
navigates away.


I do agree about the responsibility side here. It's just doesn't
address the core problem at all.


**AND** you seem to want this extension to cure a problem, that is
also cured by window.opener.opener


No. He just gave a counterexample to your suggestion, a use case your
solution would have broken. It wasn't relevant for his original
proposal.



Some thing I would like to add here, is that your "solution" doesn't
do anything to solve the actual l problem case. Even if window.opener
would be read only, that is just a reference to a window object. Even
if that property would be read only you could still write to the
location property of the window object it references. For your
solution to work the read only attribute would have to cascade to all
properties, something defying the nature of JavaScript.

A much better solution, in my opinion, would be to make the location
object safe from cross domain attacks by making it only writable from
same domain, or if the document does not have a domain yet.
(window.open without address) I do think this would break some sites,
however.

Hallvord's solution of allowing sites to disable the window.opener
property and thereby preventing the writing to window.opener.location
does solve the problem for that particular window object, as an opt-in
security measure. The main problem I see with this approach is that if
people aren't nulling the window.opener property already I don't think
they would opt in for another alternative method of doing it. Actually
fixing cross domain writing to the location object would.
--
David "liorean" Andersson

Re: [whatwg] window.opener and security

[Gareth Hay]

On 20 Mar 2007, at 15:45, Hallvord R M Steen wrote:


1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.


The UA can not do this. It would break legacy pages by resetting
window.opener if content comes from a different server.

If this is a security point, which I take from the subject  
"window.opener and security" it is, there is no problem with a UA  
breaking an implementation that relied on insecurity.
I can't think of a single reason that when a user navigates to  
another domain, you would want that domain to access your  
window.opener, so the UA clearly could do this.



I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming
correctly and using an unload to null the property when someone
navigates away.


Wouldn't it then be cleaner to be able to tell the UA in advance that
the window should not have an .opener property?


Isn't this about security?
There is no security risk allowing your own window to access .opener.
When you switch domains, the UA either nulls it, or as is the current  
case, on WebKit at least, it throws exceptions when you try to access  
it.


I don't see the need for this property at all.


**AND** you seem to want this extension to cure a problem, that is
also cured by window.opener.opener


You mean window.top.opener . No, that issue is in no way related to
the suggested extension.


i didn't mean window.top.opener

document.getElementsByTagName('iframe') 
[0].contentWindow.opener=self.opener;

Re: [whatwg] window.opener and security

[liorean]

On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

As was clearly stated, I showed a workaround and then suggested it
should be up to the UA to handle this situation.
It is not helpful to deliberately misunderstand points, and quote
them out of context. I suggest you re-read my mail.


You showed a workaround for a different problem than that which
Hallvord initially tried to solve.

The original problem is that browsers allow cross domain setting of
windowobject.location. Whether windowobject in this case comes from
window.opener isn't really relevant, except that it provides a method
of getting a windowobject reference.

Hallvord's solution is a workaround - it addresses the ability to get
that windowobject reference, even though it doesn't address the core
problem.

On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.

I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming
correctly and using an unload to null the property when someone
navigates away.


I do agree about the responsibility side here. It's just doesn't
address the core problem at all.


**AND** you seem to want this extension to cure a problem, that is
also cured by window.opener.opener


No. He just gave a counterexample to your suggestion, a use case your
solution would have broken. It wasn't relevant for his original
proposal.



Some thing I would like to add here, is that your "solution" doesn't
do anything to solve the actual l problem case. Even if window.opener
would be read only, that is just a reference to a window object. Even
if that property would be read only you could still write to the
location property of the window object it references. For your
solution to work the read only attribute would have to cascade to all
properties, something defying the nature of JavaScript.

A much better solution, in my opinion, would be to make the location
object safe from cross domain attacks by making it only writable from
same domain, or if the document does not have a domain yet.
(window.open without address) I do think this would break some sites,
however.

Hallvord's solution of allowing sites to disable the window.opener
property and thereby preventing the writing to window.opener.location
does solve the problem for that particular window object, as an opt-in
security measure. The main problem I see with this approach is that if
people aren't nulling the window.opener property already I don't think
they would opt in for another alternative method of doing it. Actually
fixing cross domain writing to the location object would.
--
David "liorean" Andersson

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

1) Either it is your responsibility to handle the nulling of the
property *or*
2) It is the UA's.


The UA can not do this. It would break legacy pages by resetting
window.opener if content comes from a different server.


I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming
correctly and using an unload to null the property when someone
navigates away.


Wouldn't it then be cleaner to be able to tell the UA in advance that
the window should not have an .opener property?


**AND** you seem to want this extension to cure a problem, that is
also cured by window.opener.opener


You mean window.top.opener . No, that issue is in no way related to
the suggested extension.

--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

> > > 
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem
>
> javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))

I don't know what GMail is doing, but I think a
window.open('','_self') would destroy the original window.opener.


That's a nice idea. It works in Firefox but fails in IE and Opera.

--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Gareth Hay]

It would appear that at least the WebKit team agree about the  
window.opener being read-only.


It has resisted all attempts by me to null it or re-assign it, and as  
soon as the domains no longer match exceptions are thrown.


From a security point of view I think this is sufficient to prevent  
your phishing example.

Re: [whatwg] window.opener and security

[Gareth Hay]

I think you are deliberately missing the point now...

On 20 Mar 2007, at 14:50, Hallvord R M Steen wrote:


On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapping to null window.opener.


Yet you are arguing that it should be impossible to set window.opener.
If you had your way that unload handler would simply throw an
exception...

As was clearly stated, I showed a workaround and then suggested it  
should be up to the UA to handle this situation.
It is not helpful to deliberately misunderstand points, and quote  
them out of context. I suggest you re-read my mail.



I will not follow up this discussion further because it is not
relevant for the proposed window.open extension. I still think it
would be useful to allow a page to open a popup without a
window.opener property to protect itself from malicious address
modification.


I also clearly stated on topic why I don't think this is required. So  
that you didn't miss the point again, (deliberately or not)


1) Either it is your responsibility to handle the nulling of the  
property *or*

2) It is the UA's.

I personally think the UA should handle it (as stated previously)
**BUT** if they do not, you *ARE* responsible for programming  
correctly and using an unload to null the property when someone  
navigates away.


**AND** you seem to want this extension to cure a problem, that is  
also cured by window.opener.opener


Gareth

Re: [whatwg] window.opener and security

[Martijn]

2007/3/20, Hallvord R M Steen <[EMAIL PROTECTED]>:

On 20/03/07, timeless <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> > 
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem

> I believe you'll find that Gmail does not have this problem, because
> when it uses window.open, it opens a gmail page which then triggers a
> server side redirect, and that destroys the window.opener link.

This is incorrect. window.opener survives the redirect and still
points to the opener window.

javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))


I don't know what GMail is doing, but I think a
window.open('','_self') would destroy the original window.opener.

Regards,
Martijn

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

Anyway, for use case 1 - If you are worried about phishing attacks,
you should be using some sort of
onunload handler trapping to null window.opener.


Yet you are arguing that it should be impossible to set window.opener.
If you had your way that unload handler would simply throw an
exception...

I will not follow up this discussion further because it is not
relevant for the proposed window.open extension. I still think it
would be useful to allow a page to open a popup without a
window.opener property to protect itself from malicious address
modification.

--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

On 20/03/07, timeless <[EMAIL PROTECTED]> wrote:

On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:
> 
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem



I believe you'll find that Gmail does not have this problem, because
when it uses window.open, it opens a gmail page which then triggers a
server side redirect, and that destroys the window.opener link.


This is incorrect. window.opener survives the redirect and still
points to the opener window.

javascript: void(window.open( 'http://hallvord.com/temp/redir.php'))


--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Gareth Hay]

Well, I don't think it is off-topic.
You are trying to justify writing to a property I think should be  
read-only.

I am asking you why you think this should be possible.

Anyway, for use case 1 - If you are worried about phishing attacks,  
you should be using some sort of
onunload handler trapping to null window.opener. Then you can be sure  
it won't be absued by anyone, even

if the user leaves your site by typing in a new uri.

For case 2, you have an iframe in a popup wanting to communicate with  
the opener?

what is wrong with window.opener.opener ?

I personally think that as soon as the domain changes the UA should  
null window.opener, but if it doesn't you can work around it as I  
said, and I think you have a non-existent problem in case 2.


*back to topic*

I don't think you need this property, you are free to send null to  
the child window's opener as things are now, and I would argue for  
making the property read-only in any future spec anyway, making the  
UA responsible for security.


Gareth

On 20 Mar 2007, at 13:21, Hallvord R M Steen wrote:


On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?


Again: We are off-topic. This isn't what I'm trying to discuss in  
this thread.


However, here are two use cases for you:

1) I don't want the next page to mess with opener:

window.opener=null;
location.href='http://some-untrusted-location/';

(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)

2) I have contents in an IFRAME that I want to talk directly to MY  
opener:


document.getElementsByTagName('iframe') 
[0].contentWindow.opener=self.opener;


What are your "exploit cases" where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with

var opener='Once upon a time, ';

which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.

Now if you  have time I'd like some comments on the proposal

window.open(url,name, 'openerproperty=0');

;)


On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:

> On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
>> window.opener should be read-only and attempting to write to it
>> should throw an exception.
>
> I don't really see why setting opener would be dangerous, so I
> disagree that it should throw. Anyway, that is a different  
issue. What
> I'm talking about is the built-in behaviour - the browser itself  
sets
> window.opener in all popups, and there is currently no way to  
open a

> popup that is prevented from changing the location of its opener.
>
> (An exception is Opera applying a stricter security policy if the
> opener is an https page so in this case popup can't set location of
> its opener, but I'm not sure if the other UAs do this.)
>





--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[timeless]

On 3/20/07, Hallvord R M Steen <[EMAIL PROTECTED]> wrote:

http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem


I believe you'll find that Gmail does not have this problem, because
when it uses window.open, it opens a gmail page which then triggers a
server side redirect, and that destroys the window.opener link.

IOW, AFAIU it's a solved problem. It's probably safe to assume it
isn't patented.

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another
parent?


Again: We are off-topic. This isn't what I'm trying to discuss in this thread.

However, here are two use cases for you:

1) I don't want the next page to mess with opener:

window.opener=null;
location.href='http://some-untrusted-location/';

(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)

2) I have contents in an IFRAME that I want to talk directly to MY opener:

document.getElementsByTagName('iframe')[0].contentWindow.opener=self.opener;

What are your "exploit cases" where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with

var opener='Once upon a time, ';

which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.

Now if you  have time I'd like some comments on the proposal

window.open(url,name, 'openerproperty=0');

;)


On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:

> On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:
>> window.opener should be read-only and attempting to write to it
>> should throw an exception.
>
> I don't really see why setting opener would be dangerous, so I
> disagree that it should throw. Anyway, that is a different issue. What
> I'm talking about is the built-in behaviour - the browser itself sets
> window.opener in all popups, and there is currently no way to open a
> popup that is prevented from changing the location of its opener.
>
> (An exception is Opera applying a stricter security policy if the
> opener is an https page so in this case popup can't set location of
> its opener, but I'm not sure if the other UAs do this.)
>





--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Gareth Hay]

Well, window.opener is conceptually a link from child to parent.
Can you give a valid use-case for adoption of the child to another  
parent?


On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:


On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

window.opener should be read-only and attempting to write to it
should throw an exception.


I don't really see why setting opener would be dangerous, so I
disagree that it should throw. Anyway, that is a different issue. What
I'm talking about is the built-in behaviour - the browser itself sets
window.opener in all popups, and there is currently no way to open a
popup that is prevented from changing the location of its opener.

(An exception is Opera applying a stricter security policy if the
opener is an https page so in this case popup can't set location of
its opener, but I'm not sure if the other UAs do this.)

Re: [whatwg] window.opener and security

[Hallvord R M Steen]

On 20/03/07, Gareth Hay <[EMAIL PROTECTED]> wrote:

window.opener should be read-only and attempting to write to it
should throw an exception.


I don't really see why setting opener would be dangerous, so I
disagree that it should throw. Anyway, that is a different issue. What
I'm talking about is the built-in behaviour - the browser itself sets
window.opener in all popups, and there is currently no way to open a
popup that is prevented from changing the location of its opener.

(An exception is Opera applying a stricter security policy if the
opener is an https page so in this case popup can't set location of
its opener, but I'm not sure if the other UAs do this.)


This is a similar issue to window.history, in certain browsers you
can write to this with js. It has no effect, but does persist across
domains. The webkit team decided to just throw an exception if a
write to window.history was detected. I don't know if it ever got
implemented, or even if any of the other browser vendors addressed it.

On 20 Mar 2007, at 11:40, Hallvord R M Steen wrote:

> Hi,
> when a new window or tab is opened by a page it normally has a
> "window.opener" property that points to the window object of the
> original tab.
>
> This happens whether the new window is opened by a JavaScript calling
> window.open or by a link or form with target attribute set.
>
> If an origin check fails when comparing the locations of the old
> window and the popup, the normal cross-domain security policies apply.
> This means that popup contents from a different site will not be
> allowed to call methods or manipulate the DOM of the opener.
>
> However, this cross-domain security policy has one exception: the
> popup may set the location of its opener. This has phishing potential,
> particularly for webmail where opening external links in a new window
> is a very common use case. Hence I think it would be a good idea to
> let a site opt-out and specify that the popup should not have a
> window.opener property. For example, one could extend the "features"
> argument of window.open:
>
> window.open(url, name, 'openerproperty=0');
>
> Thoughts?
>
> References:
> http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-
> security-an-unfixable-problem
>
> --
> Hallvord R. M. Steen





--
Hallvord R. M. Steen

Re: [whatwg] window.opener and security

[Rimantas Liubertas]

2007/3/20, Gareth Hay <[EMAIL PROTECTED]>:

window.opener should be read-only and attempting to write to it
should throw an exception.


It was possible to set window.opener in IE, alas, I do not remember
which version :(
But it has been fixed, AFAIK.


Regards,
Rimantas
--
http://rimantas.com/

Re: [whatwg] window.opener and security

[Gareth Hay]

window.opener should be read-only and attempting to write to it  
should throw an exception.


This is a similar issue to window.history, in certain browsers you  
can write to this with js. It has no effect, but does persist across  
domains. The webkit team decided to just throw an exception if a  
write to window.history was detected. I don't know if it ever got  
implemented, or even if any of the other browser vendors addressed it.


On 20 Mar 2007, at 11:40, Hallvord R M Steen wrote:


Hi,
when a new window or tab is opened by a page it normally has a
"window.opener" property that points to the window object of the
original tab.

This happens whether the new window is opened by a JavaScript calling
window.open or by a link or form with target attribute set.

If an origin check fails when comparing the locations of the old
window and the popup, the normal cross-domain security policies apply.
This means that popup contents from a different site will not be
allowed to call methods or manipulate the DOM of the opener.

However, this cross-domain security policy has one exception: the
popup may set the location of its opener. This has phishing potential,
particularly for webmail where opening external links in a new window
is a very common use case. Hence I think it would be a good idea to
let a site opt-out and specify that the popup should not have a
window.opener property. For example, one could extend the "features"
argument of window.open:

window.open(url, name, 'openerproperty=0');

Thoughts?

References:
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and- 
security-an-unfixable-problem


--
Hallvord R. M. Steen

[whatwg] window.opener and security

[Hallvord R M Steen]

Hi,
when a new window or tab is opened by a page it normally has a
"window.opener" property that points to the window object of the
original tab.

This happens whether the new window is opened by a JavaScript calling
window.open or by a link or form with target attribute set.

If an origin check fails when comparing the locations of the old
window and the popup, the normal cross-domain security policies apply.
This means that popup contents from a different site will not be
allowed to call methods or manipulate the DOM of the opener.

However, this cross-domain security policy has one exception: the
popup may set the location of its opener. This has phishing potential,
particularly for webmail where opening external links in a new window
is a very common use case. Hence I think it would be a good idea to
let a site opt-out and specify that the popup should not have a
window.opener property. For example, one could extend the "features"
argument of window.open:

window.open(url, name, 'openerproperty=0');

Thoughts?

References:
http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and-security-an-unfixable-problem

--
Hallvord R. M. Steen