OWASP Top Ten: A2 – XSS

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.

 

OWASP Top Ten: A2 – XSS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.