bugtraq - Re: Reverse Proxy Cross Site Scripting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 17 Jan 2006 10:13:40 +0200
From: "Amit Klein (AKsecurity)" <aksecurity@...pop.com>
To: bugtraq <bugtraq@...urityfocus.com>,
	Shalom Carmel <shalom@...era.com>
Subject: 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.