[whatwg] window.opener and security

liorean liorean at gmail.com
Tue Mar 20 08:51:44 PDT 2007


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



More information about the whatwg mailing list