[Twisted-web] Preventing XSS when using Nevow's vhost
functionality
David Reid
dreid at dreid.org
Wed Oct 19 17:07:58 MDT 2005
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
More information about the Twisted-web
mailing list