W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2007

[whatwg] window.opener and security

From: Gareth Hay <gazhay@gmail.com>
Date: Tue, 20 Mar 2007 15:58:32 +0000
Message-ID: <C08805C6-4FB0-4C4D-AC9E-132C3799D35B@gmail.com>
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 <gazhay at gmail.com> 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 <gazhay at gmail.com> 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
Received on Tuesday, 20 March 2007 08:58:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:53 UTC