XSS: Capturando Cookies de Sesión.

Una de las vulnerabilidades más presentes a nivel mundial en los aplicativos web es el Cross Site Scripting (XSS), esta vulnerabilidad permite inyectar código JavaScript dentro de un determinado input o campo del aplicativo web. La vulnerabilidad se produce porque el desarrollador del sitio web no “escapo” los caracteres especiales dentro de los campos o inputs del sitio web.

¿Cuál es el peligro de dicha vulnerabilidad?

El peligro principal de esta vulnerabilidad es que a través de ella, es posible realizar actos maliciosos como por ejemplo:

Robar cookies de sesión y de esta manera capturar la sesión de un usuario
Modificar el sitio web
Redireccionar a otro sitio web
Infectar a la victima dejando su equipo en modo zombie para una Botnet

Existen 3 tipos de ataques XSS, los cuales son los siguientes:

XSS Reflejado

Se trata de un ataque que no se ejecuta en conjunto con la aplicación web, por ejemplo cuando una página en un sitio se carga, esto significa que el contexto de este ataque solamente llega hasta la petición desarrollada por un cliente, normalmente estos ataques suelen asociarse con el robo de cookies, secuestro de sesiones, acceder a historial de la víctima e inclusive acceder a contraseñas almacenadas en el navegador utilizado.

Este tipo de ataque al igual que prácticamente todas las técnicas asociadas con XSS, se encuentran directamente relacionadas con validaciones de los parámetros de entrada que espera una aplicación web. Filtros y validaciones de los datos que un usuario puede ingresar a una aplicación son frecuentemente la razón principal para que se produzcan esta clase de brechas de seguridad.

XSS Almacenado o Persistente

Se trata de una variación del ataque anteriormente mencionado, sin embargo es el más peligroso, (y obviamente el más deseado por un atacante) dado que el contexto de este ataque no se limita solamente al contexto del navegador web de un usuario, sino que por el contrario puede afectar directamente a todos los usuarios que acceden a la aplicación, por esta razón es una de las vulnerabilidades mas peligrosas. Funciona de un modo similar al anterior, con la diferencia que en este caso, la vulnerabilidad se encuentra almacenada de forma persistente en la aplicación, ejemplos típicos de este tipo de ataques son foros o sitios donde se pueden incluir comentarios, así como otros tipos de entradas que permite al usuario ingresar texto y estás a su vez, permiten la inclusión de código HTML o JavaScript.

XSS basado en DOM

Este tipo de ataque se basa en los dos anteriores, la diferencia radica en que se aprovecha la API DOM que tienen los navegadores web para acceder a determinados objetos del navegador, como por ejemplo, funciones en JavaScript. De esta forma es posible manipular eventos, navegación y otras características que se ejecutan en el lado del cliente. Así que en este punto es importante anotar que el atacante debe tener buenos conocimientos sobre JavaScript y DOM Api.

En esta oportunidad nos enfocaremos en el ataque XSS Almacenado. Tenemos el siguiente escenario de pruebas:

Sesión de Usuario con privilegios básicos

Aquí tenemos una sesión con el usuario gordonb, el cual es un usuario básico, sin privilegios administrativos. En dicho sitio web existe un recurso donde el usuario puede hacer comentarios y/o sugerencias, dicho recurso es el siguiente:

Recurso donde se hacen comentarios

Para verificar si el sitio web es vulnerable a un XSS Almacenado, se agregará al campo un vector de ataque de tipo XSS, el vector básico de ataque es <script>alert('Hacked by Samux')</script>. Al agregar este vector en el campo se logró visualizar lo siguiente:

XSS Almacenado Presente

En este recurso fue posible inyectar código JavaScript, por lo tanto lo siguiente será generar un vector de ataque el cual permitirá robar una cookie de sesión de cualquier usuario que ingrese a este recurso. Para generar este vector de ataque será necesario tener un servidor, o un VPS, o abrir puertos en mi router, el cual servirá para recibir todas las cookies de sesión (Esto es necesario solo si se realiza el ataque de manera real). A continuación tenemos el siguiente vector de ataque:

La dirección IP 192.168.1.44 es nuestro servidor el cual se mantendrá a la escucha para recibir todas las cookies de sesión. Si revisamos nuestro servidor tenemos lo siguiente:

Servidor atacante (192.168.1.44) a la escucha en el puerto 80

Luego al agregar este vector de ataque en la parte de comentarios del recurso del sitio web, nos aparecerá lo siguiente en nuestro servidor atacante:

Cookie de Sesión de usuario atacante

Efectivamente nos aparece una cookie capturada, sin embargo esta cookie es la de la cuenta con la que se inyecto este vector de ataque, por ende solo restaría esperar que un usuario distinto ingrese a este recurso y automáticamente se obtendrá la cookie de sesión. Luego de esperar un cierto tiempo, nos percatamos que alguien ingresó al recurso del sitio web.