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

[David Remahl]

On 20 okt 2005, at 01.07, David Reid wrote:

> 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
>
> <xss-nevow.tac>

Thanks for your reply!

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".

If anyone is still unclear on my idea of the attack, I'll construct  
another PoC, since the two exploits are fundamentally different.

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.

Only allowing a single "invocation" of the monster resource is  
insufficient in certain situations, namely when http://internalserver: 
1234/ is accessible from the outside and not _exclusively_ by the  
reverse proxy. This might also be a problem with the VHostURIRewrite  
approach?

/ Thanks, David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-web/attachments/20051020/4b522254/attachment-0001.htm