Hemos llegado a una de las vulnerabilidades más conocidas y explotadas, y que a pesar de ello, persiste su existencia en muchas aplicaciones web… La vulnerabilidad XSS se presenta cuando un atacante logra inyectar código HTML y/o javascript en una aplicación que no realiza una adecuada validación de los datos de entrada.
El código de un ataque XSS es ejecutado cuando la víctima visita el sitio vulnerado.
Existen 3 tipos principales de XSS:
- Reflejado.- Es cuando el atacante envía un link ya con el código incrustado, mismo que será ejecutado una vez que la víctima abra el link. Para que esto funcione, se utiliza un poco de ingeniería social, quizás acortadores de URLs para engañar más fácilmente a la víctima.
- Persistente.- Es cuando el atacante puede plantar un script persistente en una página web, así, cada persona que visite esa página, ejecutará el código en su navegador.
- De modelo de objetos de documento (DOM).- Para este tipo de XSS no se requieren peticiones HTTP, el script es directamente inyectado como un resultado de modificar el DOM del sitio web vulnerable, lo que hace que se ejecute del lado del cliente, es decir, en el navegador de la víctima.
Nota.- El Modelo de Objetos del Documento (DOM) es una interfaz de programación de aplicaciones (API) para documentos válidos HTML y bien construidos XML. Define la estructura lógica de los documentos y el modo en que se accede y manipula.
Riesgos
Existen diferentes riesgos asociados a esta vulnerabilidad, como son:
- Comprometer una cuenta de usuario
- Obtener información del sitio web vulnerable
- Modificar el sitio web vulnerable (defacement)
- Redireccionar a las víctimas hacia sitios maliciosos
- Ejecutar algún tipo de malware en el equipo de la víctima
Explotando XSS
Ahora vamos a ver cómo se puede explotar esta vulnerabilidad, para ello vamos a una página que ya hemos utilizado anteriormente para ejemplificar la explotación de vulnerabilidades, Altoromutual.
1.- Ya que estamos en el sitio de Altoromutual, vamos a ingresar con las credenciales que ya conocemos:
- usuario.- jsmith
- password.- demo1234
2.- Ahora tenemos que buscar un campo de entrada de datos para probar si es vulnerable a XSS. La primera parte que podemos observar como entrada de datos, es el buscador interno del sitio, así que vamos a probar si es vulnerable. Para esto vamos a escribir el siguiente código en el buscador:
<script>alert(«Almost a Hacker»);</script>
Lo que estaremos ejecutando es una ventana de alerta que dirá «Almost a Hacker«.
Nota.- Si lo estás intentando en Chrome seguramente obtendrás un error ya que dicho navegador bloquea la ejecución de XSS. Te recomiendo que por ahora, cambies a Firefox.
Esta es la manera más fácil de demostrar que un sitio web es vulnerable a XSS, inclusive es la manera más común de evidenciarlo en un reporte de alguna prueba de intrusión, sin embargo, si quisiéramos hacer algo malicioso, o quizás alguna demo para un cliente que es vulnerable y no nos cree, o simplemente argumenta que esto no es peligroso, podemos demostrarle cómo podríamos redirigir a una víctima a otro sitio. Vamos a ver cómo lograrlo.
3.- Vamos nuevamente al buscador interno y ahora cambiaremos nuestro script a ejecutar y pondremos el siguiente:
<script>document.location=»http://78.media.tumblr.com/3fa4284da13b4364acd457b8613ad79f/tumblr_n9r93n6Ydc1r9ccqpo1_400.gif»</script>
Lo que estamos haciendo aquí es, mediante «document.location«, redirigir a la víctima a una página que nosotros queramos, que es justamente lo que tenemos entre comillas dobles. El resultado será el siguiente:
Ahora que si aún así no nos creen, o siguen argumentando que eso no representa ningún riesgo, podemos ir más allá, y mediante el envío de correos hacia los usuarios de la aplicación, enviar un link malicioso que los redirija hacia nuestro sitio malicioso. Vamos a ver cómo hacerlo.
4.- Volvemos al buscador del sitio y haremos una búsqueda de cualquier cosa, únicamente para generar un link válido de búsqueda, por ejemplo, busquemos «Almos a hacker«:
5.- Como podemos observar, no hay ningún resultado, pero ya hemos generado una URL válida donde podemos hacer un ataque XSS, y para esto vamos a modificar todo lo que está después de txtSearch= y ahí vamos a meter nuestro código a ejecutar (el mismo del paso 3), quedando de la siguiente forma:
¿Qué es lo que pasa si alguien visita ese link? Pues que directamente será redirigido al sitio malicioso.
Y si además de esto, convertimos este link en uno más corto para que nadie vea realmente hacia donde te dirige… Vamos a utilizar el servicio bit.ly para acortar la URL maliciosa que hemos creado.
En este campo es donde vamos a pegar nuestra URL maliciosa.
Y como podemos ver, ya se ha generado un link, más corto, que la víctima no sabrá a dónde lo está redirigiendo. El nuevo link es este: http://bit.ly/2Fj5Pl5
Existen muchos vectores de ataque que se pueden utilizar con XSS, como el robo de cookies de sesión por ejemplo, o la modificación del sitio web.
Mitigación
Se recomienda hacer una correcta validación de datos del lado del cliente y servidor, acotando los caracteres permitidos por la aplicación por medio de listas blancas, evitando así que las páginas a la vista de los usuarios puedan ser modificadas para realizar ataques de phishing o robo de sesiones válidas. Si estás en posibilidades, o tu empresa lo está, utiliza un WAF (Web Application Firewall) como método de defensa adicional ante estos ataques.
