<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Oct 19, 2005, at 4:39 PM, David Remahl wrote:</DIV><BLOCKQUOTE type="cite"><DIV>I'm not sure your PoC encapsulates precisely the problem I described, but it is a valid variant which doesn't require as many preconditions (but is not possible to exploit in some browsers, such as Safari, that won't trust JS from another host even if directly referenced from goody). I think I should clarify that in my example, goody.com and evil.net are two sites that _are_ indeed served by the same nevow application. They each have their own little space on the same server, but they don't administer the application serving their content. I guess that's what you refer to as "sister applications".</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I just wrote this very long email about your suggested exploit, and then realized that the example configuration I imagined wouldn't cause the type of behavior you describe.   I can imagine a very complicated configuration that invovling 3 vhost.VHostMonsterResources and 1 NameVirtualHost might allow someone to suddenly jump between two domains in the NameVirtualHost (at the urging of an attacker) but I haven't tried to put together a PoC. If this is in fact the configuration you're suggesting I only have this to say I can not think of a single use case for vhost.NameVirtualHost vhost.VHostMonsterResource being used today in a configuration such as what I believe you to be describing.  But if there is a use-case I'm honestly not sure there is a way to make it work without properly.</DIV><DIV><BR class="khtml-block-placeholder"></DIV></DIV><DIV>-David</DIV><DIV><FONT class="Apple-style-span" color="#0000DD"></FONT></DIV></BODY></HTML>