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.

Relevant Pages

  • RE: Link from corporate site to internal corp. network
    ... By hijacking any Web browser located on your internal network, an attacker ... Moving beyond a single server ... If the client in use is Microsoft Internet Explorer, ...
    (Security-Basics)
  • Re: [Full-disclosure] Cross Domain XMLHttpRequest
    ... As much as I loathe the origin-based security model of modern web ... there are semi-valid reasons why XMLHttpRequest is restricted ... A remote attacker can interact with much of the Internet on its own. ... you do not want your browser to roam the Internet on ...
    (Full-Disclosure)
  • Re: Session Hijacking over HTTP
    ... IMHO when attacker controls HTTP flow it can read and modify all data ... customization and addons for browser so the user can not bypass SSL ... HTTP after authentication. ... WHat is the best way to protect session cookies from hijacking esp. ...
    (Pen-Test)
  • Re: How to completely destroy a script and make it disappear forever.
    ... An attacker can use a local proxy to talk to your server ... over SSL, and have plain HTTP traffic between the browser and the proxy. ...
    (comp.lang.javascript)
  • Re: preserve POST data when using the back-button
    ... Chris Morris wrote: ... email them to the attacker or try to ... exploit a JS-based bug in the user's browser. ... It's a very common form of reported vulnerability for two reasons: ...
    (comp.infosystems.www.authoring.html)