|
Excelente texto que nos explica como realizar este ataque de varioas formas distintas asi como el modo de prevenirlo.
Texto Completo:
=-[ 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 "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.
( http://es.wikipedia.org/wiki/XSS )
( http://enciclopedia.us.es/wiki.phtml?title=XSS )
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 preprocesadores
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.
Particularizando 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 automaticamente 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 aprovechamiento 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 vulnerabilidades
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 vulnerabilidades 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
automaticamente 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...).
# telnet xxx 80
Trying xxx...
Connected to xxx.
Escape character is '^]'.
GET index.html HTTP/1.0
Referer:
User-agent: |
Hacking y Seguridad 
