Mini-Paper: XSS con Reverse Proxys...

El Cross Site Scripting (XSS) requiere que el sitio web objetivo sea susceptible (por lo menos hasta cierto punto) a la inyección de html y script injection.. Este requisito está restringido debido a limitaciones incorporadas de DOM: navegadores Modernos restringen javascript, en una ventana de interactuar con otra ventana, a menos que ambos pertenescan al mismo dominio(protocol + server name + port). Este mini-paper describe cómo vencer este requisito, y muestra un ataque posible de XSS en una aplicación, incluso si no es XSS-VULNERABLE en un todo.

El ataque básico es sencillo de crear y verificar. Requiere a un servidor Apache que recibe una página de HTML con el código del ataque, y eso corre un reverse http proxy. Los reverse proxy se configuran para retransmitir algunos pedidos de http al sitio web de la víctima.

La página del ataque contiene un iframe que señala en la dirección proxys-retransmitido en el servidor Apache local. Creando un iframe que es ,según cabe suponer, en el mismo dominio del atacante, se puede conseguir acceso al contenido del iframe.

***Reverse Proxy XSS attack***

Veamos un ejemplo sencillo. El sitio de la víctima contiene una página web:
http://www.victim.com/v_page.html

v_page codigo:

HTML>
BODY>
form name="f1" id="f1">
input name="in1" id="in1" value="somethingOther">
/form>
/BODY>
/HTML>

El sitio del atacante se llama http://www.victima.com.victin.com El servidor apache del atacante es configurado para servir el HTML document desde el directorio/xss, y tiene las siguientes
definiciones inversas de proxys:

ProxyPass /http://www.victima.com/
ProxyPassReverse / http://www.victim.com/

Dentro del directorio local XSS, existe un documento llamado ¨pagina_X.html¨, con el siguiente codigo:

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>

Cuándo alguien realiza el acceso a la dirección: http://www.victim.com.victin.com/xss/x_page.html
el navegador cargará la página del sitio web atacante y la tentativa para conseguir acceso a su contenido.Mientras la carga triunfa, el intento del acceso falla.
Sin embargo, cuando la página atacante se modifica para referirse al relevo de proxys:

iframe name="win1111" id="win1111" src="/v_page.html">

Esta vez,el script no fallará. Permitirá al atacante conseguir acceso y modificar el contenido
del sitio web de la víctima.
Este arreglo permitirá también el acceso completo de la sesión de http en el sitio de víctima (URLs y cookies).

Anton Rager's XSS-Proxy se pueden utilizar en este ataque para mejor control de la sesión asaltada.

En un ataque de pharming, un DNS cache se puede envenenar para señalar www.victim.com directamente al sitio web del atacante, mientras el maneja la resolución correcta
de IP en los archivos del host local. Un ataque de phishing/pharming consiste generalmente en que un intruso crea un facsímile del sitio web de víctima. Con reverse proxys,
ese facsímile es no requerido, haciendo más fácil de crear un ambiente genérico para ataques de tipo http MITM.

** Referencias **
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

Salu2