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

[Jason Mobarak]

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 pageWithAttackJS.js would more likely be liveglue.js?

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

I don't quite understand why this works.  If the first two segments of 
the vhost request are the protocol and the host why isn't it the case 
that these segments are consumed, the URL is re-written to:

http://foo.bar/vhost/http/google.com

...and it fails because foo.bar doesn't exist?  Why are the segments 
still consumed after this point, or...?

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