Cross Site Scripting (XSS)
Introducción
La vulnerabilidad de Cross Site Scripting, también conocida como Ataque XSS, permite la secuencia de comandos en aplicaciones web. Este fallo de seguridad nace de una falta de sanitización o parches de seguridad en las entradas de datos de los sitios web (por ejemplo, en los comentarios, registros, carga de archivos, etc.). Por lo tanto, esto le permite a un atacante poder inyectar código malicioso JavaScript y ganar acceso a la máquina víctima (robandos sus datos, credenciales, suplantando la identidad, etc). Esta vulnerabilidad es posible tanto en lenguaje Javascript como así también en, Flash, CSS y VBScript.
Debemos recordar que, con respecto a aplicaciones web, nos referimos a los navegadores (Chrome, Firefox, Opera, etc.). Por tanto, dicha vulnerabilidad se lleva acabo del lado del cliente (usuario) y no específicamente en archivos o datos locales de un servidor (Como es el caso de LFI).
Tipos de Ataques
Podemos dividir la vulnerabilidad de Cross Site Scripting en tres tipos de ataques XSS.
Reflejado
Aquí el atacante necesita engañar a la víctima, ya sea a través de un enlace, un botón, anuncios (cualquier acto de ingenireía social), para que la misma ejecute, sin saberlo, una carga útil (payload). De esta forma, el ciberdelincuente se aprovecharía de la petición del usuario a través de su código malicioso, generando así, que se refleje la salida (datos del usuario) en la máquina del atacante.
Almacenado
Este suele ser uno de los ataques más peligrosos de XSS ya que, como su nombre lo indica, la carga útil del atacante se almacena en la base de datos de la aplicación web. Esto permite realizar cualquier acción maliciosa hacia los navegadores o usuarios que quieran acceder a dicho recurso. Un ejemplo de esto puede ser cuando intentamos cargar datos de registro o comentarios.
Basado en DOM
Esta vulnerabilidad radica en la interfaz de programación DOM (Document Object Model) para documentos HTML y XML. La cual permite identificar de forma jerárquica los objetos que componen un sitio web. De esta forma, y por falta de validación de los inputs de los usuarios, podemos leer, acceder y cambiar la estructura, estilo y contenido del código fuente de una página web (fronted) a través de la inyección de código.
Práctica en TryHackme
A continuación estaremos realizando un laboratorio para entender cómo funciona un esta vulnerabilidad de cross site scripting o ataques XXS en sus diferentes tipos.
Verificación XSS
Lo primero que haremos será inyectar el siguiente payload través del buscador en un sitio web de prueba.
El resultado en nuestro navegador es el siguiente:
Nos devuelve el mensaje que hemos enviado a través de nuestra etiqueta. “alert”. Por lo tanto, podemos confirmar un XSS reflected. En base a esto, obtenemos nuestra bandera del CTF:
Obtener la Dirección IP
En este paso, vamos a utilizar un Payload cuyo propósito será reflejar una ventana emergente con nuestra dirección IP.
Como resultado nos devuelve lo siguiente:
A través de la función alert hemos podido obtener la dirección IP de un usuario (en este caso la nuestra). Por lo tanto, nuestra flag es:
Inyección HTML
Ahora bien, la máquina nos pide que nos registremos a través del siguiente formulario:
Una vez hecho esto, podemos observar que nos encontramos en una página con comentarios de usuarios.
Por tanto, cuando realizamos un comentario estamos enviando datos, precisamente, a la base de datos. En este caso, podríamos empezar a probar payloads del tipo XSS almacenado.
Teniendo esto en cuenta, podríamos verificar si podemos inyectar código HTML. En tal caso haríamos lo siguiente:
Las etiquetas <h1> representan un título dentro de un formulario HTML. Por lo tanto, en los comentarios veríamos lo siguiente:
Se ha cargado satisfactoriamente nuestra inyección HTML y, como resultado, vemos nuestra flag en el recuadro rojo.
Obtener Cookie de Sesión
En base a lo anterior, podríamos seguir probando cosas. Por ejemplo, haremos una prueba para verificar si podemos obtener las cookies de sesión. Recordemos que con ellas podemos llegar muy lejos y obtener mucha información. Por lo tanto, vamos a verificar esto a través del siguiente payload:
Se nos aparecerá las siguientes ventanas en nuestro navegador:
En el primer cuadro, podemos observar nuestra cookie de sesión y en el segundo, nuestra flag.
Ahora bien, llegados a este punto, la máquina nos pide cambiar el título de la página “XSS Playground” por “I am a Hacker”.
Recordemos que por detrás de cada sitio web hay código HTML. Entonces podríamos hacer click derecho, presionamos en “inspeccionar”, damos click en el puntero remarcado y vemos que dicho título le corresponde el id thm-title.
Por lo tanto, vamos a utilizar el siguiente payload para esta operación:
Como resultado tendríamos:
Ganar Acceso al Sistema
Hasta aquí hemos finalizado nuestro laboratorio. No obstante, ¿Recuerda que en los comentarios también figuraba el usuario ‘Jack’? A modo de ejemplo, robaremos su cookie de sesión y accederemos a su cuenta.
Para esto, utilizaremos el siguiente Payload:
Lo que hemos hecho aquí es, a través de código Javascript, obtener la ruta de las cookies de sesión de los usuarios, en este caso, del usuario Jack.
Luego nos dirigiremos a la siguiente URL: https://IP_Machine/logs.
Como vemos, la plataforma nos indica que podemos loguearnos a través de dicha ruta y, a su vez, obtenemos la cookie de sesión. Por lo tanto, ahora debemos cambiar nuestra cookie por la marcada en dicha imagen. Para esto, podemos presionar F12 y en “Storage” realizamos el cambio (también puede hacerlo a través de un proxy con la herramienta Burpsuit).
Una vez hecho esto, actualizamos la página y podremos observar que nos encontramos logueados como el usuario Jack.
¿Cómo prevenimos esta Vulnerabilidad?
Como hemos visto, estos fallos de seguridad ocurren del lado del cliente, es decir, a nivel usuario. Por lo tanto, debemos tener en cuenta un conjunto de reglas a llevar a cabo cuando se trata de un cross site scripting, o ataque xss, por más que el atacante haya tenido acceso a un sitio web. Podemos destacar:
- Sanitizar o filtrar los inputs: Es crucial tener en cuenta que, si abrimos puertas de entrada como comentarios, registros o búsquedas. Las mismas no admitan la ejecución de código de ningún tipo.
- Establecer encabezados de página apropiados: Como bien sabemos, las inyecciones XSS no siempre pueden ser en base a Javascript o HTML. Por lo tanto, para cuidarnos de cualquier solicitud maliciosa debemos indicarle a los navegadores que no interpreten cualquier petición enviada. Para esto, podemos hacer uso de los encabezados Content-Type, X-Content-Type-Options y X-XSS-Protection.
- Codificar salida de datos: Del mismo modo que verificamos la entrada de datos, también debemos hacerlo con la salida. Es fundamental codificar el output ya que, teniendo en cuenta la salida controlable de los datos del usuario a través de respuestas HTTP, esto podría provocar una serie de combinaciones de codificación con lenguajes HTML, Javascript o alguna URL.
Finalmente, recuerde que todo lo mencionado anteriormente debe ir de la mano con la constante actualización de programas y versiones que se estén usando. Como así también, de las políticas de privacidad empleadas.
