<<< Date Index >>>     <<< Thread Index >>>

Re: Reverse Proxy Cross Site Scripting



Hi

Please see my comment below,

Thanks,
-Amit



On 15 Jan 2006 at 12:49, Shalom Carmel wrote:

>            A Mini-paper
>           Reverse Proxy Cross Site Scripting
> 
> Author: Shalom Carmel
> Date: January 13, 2005
> 

[...]

> 
> The attacker site is called http://www.victim.com.victin.com
> The attacker's apache server is configured to serve html documents from
> directory /xss , and has the following reverse proxy definitions:
> 
> ProxyPass / http://www.victim.com/
> ProxyPassReverse / http://www.victim.com/
> 

[...]

> When someone accesses the address
> http://www.victim.com.victin.com/xss/x_page.html
> the browser will load the page from the attacked web site and attempt to
> access
> its contents. While the loading will succeed, the access wil fail.
> 
> However, when the attacking page is modified to refer to the proxy relay,
> 
> <iframe name="win1111" id="win1111" src="/v_page.html">
> 
> This time, the script will not fail. It will enable the attacker to access
> and modify the contents of the victim web site.

As far as my understanding goes, this is NOT a cross site scripting. The 
browser fetches 
the URL http://www.victim.com.victin.com/v_page.html, so it's still in the 
www.victim.com.victin.com site (it has not CROSSED to the www.victim.com 
site!). This is an 
important distinction. The x_page.html does indeed have access to the frame, 
and that's 
because the frame is in the same site (from the browser's perspective) - 
www.victim.com.victin.com. the browser will not allow x_page (or v_page!) to 
access any 
content from www.victim.com (again, from the browser's perspective!), such as 
cookies, 
URLs, etc. 

What you do have here is a man-in-the-middle attack. That is, you lured the 
client to 
browse to your server (www.victim.com.victin.com), which is a proxy for 
www.victim.com. 
This is a well known attack (e.g. http://www.schneier.com/essay-083.html), and 
you can 
implement it more elegantly by not doing anything at the client side, just 
monitor (and 
possibly modify) the HTTP requests/responses through Apache hooks, all at the 
server side.

To summarize: MITM <> XSS. With MITM, the browser will see original content 
from 
www.victim.com, but it will not associate it with www.victim.com, but rather, 
to 
www.victim.com.victin.com. Two different domains (from the browser's 
perspective). So (for 
example) you may be able to lure the client to login to this fake site (and 
record the 
credentials on the way). On the other hand, if (say) the client is already 
logged in to the 
real www.victim.com (in another window), you won't be able to access his/her 
credentials. 
With XSS, you will be able to access those credentials.

Hope that clarifies things.