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.