Marc Delisle wrote:

Sebastian Mendel a écrit :

...

Hi,

as i try to merge all the sql query box and window stuff in some functions i came across that script-noscript constructs for the form-tag

are there any known problems with

onsubmit="this.target=window.opener.parent.frames[2].name;"

?

I am not familiar with this, but for example in browse_foreigners.php, there is some code that checks opener:

if (opener && opener.document && opener.document.insertForm) {

so maybe opener is not always available. So maybe it would be safer to call a js function that makes some checks before referencing to window.opener.something.

yes, of course, its only available if this windows was opened by another window and you need to check if this opener window is still open

but if this works, we can get rid of all this javascript stuff just only added to prevent window spoofing

http://xforce.iss.net/xforce/xfdb/18397

or is there something i missed?

btw. at the moment any other page can also access the hash inside the queryframe window, as phpmain is scured through this hashed name, but the used hash can be accessed directly by the window name of the queryframe window

so phpMyAdmin is vulnerable to window spoofing at the moment!

or?

only the popup window needs a secured name (with hash), all other windows/frames can be accessed by opener or parent, what is not available to an attacker

Michal Čihař schrieb:

Hi Sebastian

as first thing I have to admit, that I never got to read and understand that query window stuff. It's just too much javascript for me ;-).

However searching CVS logs, I found that hash was originally added because of mixing query frames among different phpMyAdmin instances (bug 723713, [1]).If you can make it work without it, I thing everybody will be happy (at least I hate our current frameset generating magic).

damn good that im not the only one having trouble with current frameset/javascript implementation for this querywindow stuff ... ;-)

so, till today no one adressed or even recognized the problem with window hijacking?

and second: the queryframe is only introduced for the querywindow? so if the querywindow doesnt need this frame anymore we can get rid of this?

my solution would be:

replace ANY window names with crypted! (window hijacking)

left frame gererates window object querywindow

var querywindow = open(...);

every access required to the qerywindow will got through this frame

frames[0].querywindow...

access from the querywindow will user opener

opener.frame[0] ... the left frame opener.frame[1] ... the phpmain frame

Michal Čihař schrieb:

...

and second: the queryframe is only introduced for the querywindow? so if the querywindow doesnt need this frame anymore we can get rid of this?

my solution would be:

replace ANY window names with crypted! (window hijacking)

left frame gererates window object querywindow

var querywindow = open(...);

every access required to the qerywindow will got through this frame

frames[0].querywindow...

access from the querywindow will use opener

opener.frames[0] ... the left frame opener.frames[1] ... the phpmain frame

Isn't queryframe reloaded sometimes? You'd lose querywindow reference in this case.

its bind to the window/frame, not to the document