RSS

OWASP Top Ten: A2 – XSS

21 Dic

El siguiente tipo de ataques que vamos a ver según las realizada por OWASP para su Top Ten es el de XSS (Cross Site Scripting). Se abrevia como XSS para no confundir con CSS (Cascade Style Sheets) utilizado para dar estilos a documentos HTML o XML. Los fallos de XSS ocurren cuando un atacante consigue ejecutar una secuencia de comandos en el navegador de la victima permitiéndole de esta forma secuestrar sesiones, redirigir al usuario a página no confiables, insertar código hostil, etc… En general, todo aquello que se os ocurra con lenguajes de script. Básicamente, se basa en explotar la no validación de entradas de una aplicación, mediante el cual un atacante puede ejecutar código malicioso en los navegadores clientes, apoyándose en los lenguajes de script como pueden ser JavaScript o VBScript. Quizás, el punto más lioso de este ataque y lo que desconcierta la primera vez que la gente tiene noticias de él, es que aunque el sistema vulnerable es el servidor, en este caso la aplicación web, el que sufre los efectos de esto son los usuarios.

Para aclararlo un poco más, vamos a ver un caso en el que se podría producir este tipo de ataques.

Imaginaros que tenemos un foro vulnerable a XSS, particularmente, el cuerpo del mensaje que publicamos no se valida de forma correcta. Yo como usuario del foro podría publicar un post en el que el cuerpo del mensaje fuera un iframe no visible(width, heigth, frameborder iguales a 0) y en el poner una redirección a un página exterior que he creado donde almacena la propiedad “document.cookie” en un fichero de texto. Cuando yo publique el post, todos los usuarios que lo lean, sin darse cuenta, realizarán una petición a mi página con código maliciosa pudiendo, de esta forma, hacerme con los datos de sus cookies y suplantándolos en el foro.

Espero que ahora haya quedado más claro el concepto, sino como siempre, todas las dudas en los comentarios.

Existen tres tipos de ataques XSS:

– Almacenados

– Reflejados

– XSS basado en DOM

Almacenados

En este caso, el atacante ha conseguido guardar en la base de datos de la aplicación vulnerable el código malicioso que afectará al cliente. Este es el caso del ejemplo que he puesto anteriormente.

Reflejados

En este caso será le propio usuario el que tendrá que ejecutar una URL maliciosa. Quizás esto no suene tan fácil, pero entre ingeniería social, y hoy en día, los acortadores URL, esto no es tan difícil. La URL apuntará a nuestra página maliciosa y quizás tenga una redirección a una página válida, para que el usuario no desconfíe.

XSS basado en DOM

En este ataque, a diferencia de los dos anteriores, el código malicioso, no proviene del servidor, sino que es el cliente el que añade nodos al árbol DOM introduciendo en esos nodos el código malicioso.

Para protegernos de este tipo de ataques, lo que deberemos es filtrar todas las entradas de nuestras aplicaciones y escapando todos los datos que recibamos. Además, tendremos que codificar y decodificar, no nos olvidemos nunca que se puede insertar caracteres hexadecimales y demás.

Bueno, espero que os sea de utilidad. Nos vemos.

 

Anuncios
 
Deja un comentario

Publicado por en 21 diciembre, 2010 en OWASP

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: