Browser Frame Injection Vulnerability, review needed

[Germain Garand]

Le Vendredi 09 Juillet 2004 13:42, Waldo Bastian a écrit :
> With "frameset's domain" I mean "the domain of the document that contains
> the frameset", as opposed to "the domain of the document in the frame"

yes, so they are unrelated... there are no valid reason why the latter should 
masquerade as originating from the former.

DOM-2 specification about domain:
"The domain name of the server that served the document, or null if the server 
cannot be identified by a domain name"

By that definition, window.frame[x].domain should definetly not be inherited 
from window.domain

Otherwise, I found 6550+6586 behave nicely for available testcases (tested 
with disabled slotChildDocCreated connection), but I think some issues remain
with KHTMLPart::recursiveFrameRequest implementation.

There is no indication if the request somehow succeeded by issuing a 
requestObject call inside one of the recursive call, or if it failed because 
of domain restriction, or even if no frame was found at all.
So when it eventually returns 0L, you don't know if something is still to be 
done.
See e.g urlSelected => will continue and issue an openURLRequest in case 
recursiveFrameRequest returns null.

Testcase for this problem:
http://www.helsinki.fi/jarj/vasa/?debug=true

Try the links in the left side menu (they point to sibling frame, but with 
different host).
Then duplicate the tab and try again: sometimes, the frame will get loaded in 
the other tab, sometimes in both.

From the debug output of this testcase, it looks like the security checks of 
ecma/kjs_window.cpp are also somehow conflicting/duplicated... I'll try to 
make a testcase that doesn't involve javascript.