[Twisted-web] Preventing XSS when using Nevow's vhost functionality

[David Reid]

On Oct 19, 2005, at 2:48 PM, David Remahl wrote:
> The attacker makes the victim go to this URL:
>     http://goody.com/vhost/http/evil.net/pageWithAttackJS.html
> which gets rewritten (by the reverse proxy) to:
>     http://internalserver:1234/vhost/http/goody.com/vhost/http/ 
> evil.net/pageWithAttackJS.html
>
> 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:
>     http://goody.com/vhost/http/evil.net/pageWithAttackJS.html
>
> This once more invokes the vhost functionality, the following  
> results and is accessed:
>     http://evil.net/pageWithAttackJS.html

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 http:// 
evil.net/.  Potentially these generated links could include a  
<script> tag.

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 http://localhost:8080/vhost/http/foo.bar/vhost/ 
http/google.com/ you should see the google logo loaded. if you do not  
include the final vhost call nothing should load.

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.

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.

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)

-David


-------------- next part --------------
Skipped content of type multipart/mixed