<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On 20 okt 2005, at 01.07, David Reid wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV><DIV>On Oct 19, 2005, at 2:48 PM, David Remahl wrote:</DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The attacker makes the victim go to this URL:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN><A href="http://goody.com/vhost/http/evil.net/pageWithAttackJS.html">http://goody.com/vhost/http/evil.net/pageWithAttackJS.html</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">which gets rewritten (by the reverse proxy) to:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN><A href="http://internalserver:1234/vhost/http/goody.com/vhost/http/evil.net/pageWithAttackJS.html">http://internalserver:1234/vhost/http/goody.com/vhost/http/evil.net/pageWithAttackJS.html</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The web server looks up the vhost child of the root resource which consumes the next two components. It sets the host to goody.com, as it should be and passes control back to the root resource. The remaining URI at this point is:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN><A href="http://goody.com/vhost/http/evil.net/pageWithAttackJS.html">http://goody.com/vhost/http/evil.net/pageWithAttackJS.html</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">This once more invokes the vhost functionality, the following results and is accessed:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-converted-space"> </SPAN><A href="http://evil.net/pageWithAttackJS.html">http://evil.net/pageWithAttackJS.html</A></DIV></BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Your example is a little confusing. VHostMonsterResource does expose applications using nevow.url to link hijacking. So for your example to work /pageWithAttackJS.html would have to be on the target server, and generated links on that page would get rewritten as <A href="http://evil.net">http://evil.net</A>/. Potentially these generated links could include a <script> tag. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So now that everyone is on the same page, i've attached a proof of concept tac that better demonstrates the problem. If you start the tac and go to it with <A href="http://localhost:8080/vhost/http/foo.bar/vhost/http/google.com/">http://localhost:8080/vhost/http/foo.bar/vhost/http/google.com/</A> you should see the google logo loaded. if you do not include the final vhost call nothing should load.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So the problem is two fold, VHostMonsterResource is to trusting of the Host: header. The solution to that is to use something like web2.vhost.VHostURIRewrite which sets the host:port for the request mangling at configuration time. This might not be ideal in all enviroments if you have multiple hosts forwarding to the same application.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Another problem is that URL generation is to trusting of the context. Being able to easily generate links relative-to-root (rendering without the scheme and netloc portions) would also prevent this type of link hijacking. (Though it would be potentially vulnerable to attacks from a sister application.) But relative-to-root URL generation (as sane default) would negate the need for vhost.VHostMonsterResource in most cases.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>However as for fixing VHostMonsterResource, I'd rather just see it die the slow painful death it deserves. But I think if you're going to limit VHostMonsterResource to one proxy url, you might as well switch to a configuration time rewriter. Another solution is to simply tag the request as rewritten so it doesn't get mangled a second time, raising the appropriate error code)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-David</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN></SPAN><SPAN><DIV><xss-nevow.tac></DIV></SPAN></DIV></BLOCKQUOTE><BR></DIV><DIV>Thanks for your reply!</DIV><DIV><BR class="khtml-block-placeholder"></DIV><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><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If anyone is still unclear on my idea of the attack, I'll construct another PoC, since the two exploits are fundamentally different.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm not familiar with web2.vhost.VHostURIRewrite, but will check it out..."Configuration time", you say. I assume that means at the start of the handling of a request, not when the application is set up and configured? If so, that sounds like a good solution in many cases.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Only allowing a single "invocation" of the monster resource is insufficient in certain situations, namely when <A href="http://internalserver:1234">http://internalserver:1234</A>/ is accessible from the outside and not _exclusively_ by the reverse proxy. This might also be a problem with the VHostURIRewrite approach?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>/ Thanks, David</DIV></BODY></HTML>