XSS almacenado
En esta sección, explicaremos las secuencias de comandos entre sitios almacenadas, describiremos el impacto de los ataques XSS almacenados y detallaremos cómo encontrar vulnerabilidades XSS almacenadas.
¿Qué es Stored Cross-Site Scripting?
Las secuencias de comandos entre sitios almacenadas (también conocidas como XSS persistentes o de segundo orden) surgen cuando una aplicación recibe datos de una fuente que no es de confianza e incluye esos datos en sus respuestas HTTP posteriores de una manera no segura.
Supongamos que un sitio web permite a los usuarios enviar comentarios en publicaciones de blog, que se muestran a otros usuarios. Los usuarios envían comentarios mediante una solicitud HTTP como la siguiente:
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Length: 100
postId=3&comment=This+post+was+extremely+helpful.&name=Carlos+Montoya&email=carlos%40normal-user.net
Después de enviar este comentario, cualquier usuario que visite la publicación del blog recibirá lo siguiente dentro de la respuesta de la aplicación:
<p>This post was extremely helpful.</p>
Suponiendo que la aplicación no realiza ningún otro procesamiento de los datos, un atacante puede enviar un comentario malicioso como este:
<script>/* Bad stuff here... */</script>
Dentro de la solicitud del atacante, este comentario estaría codificado en URL como:
comment=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E
Cualquier usuario que visite la publicación del blog ahora recibirá lo siguiente dentro de la respuesta de la aplicación:
<p><script>/* Bad stuff here... */</script></p>
El script proporcionado por el atacante se ejecutará en el navegador del usuario víctima, en el contexto de su sesión con la aplicación.
Detecte más de 7000 vulnerabilidades con el escaneo DAST + IAST combinado
Impacto de los ataques XSS almacenados
Si un atacante puede controlar un script que se ejecuta en el navegador de la víctima, normalmente puede comprometer completamente a ese usuario. El atacante puede realizar cualquiera de las acciones aplicables al impacto de las vulnerabilidades XSS reflejadas .
En términos de explotabilidad, la diferencia clave entre el XSS reflejado y el almacenado es que una vulnerabilidad XSS almacenada permite ataques que están autocontenidos dentro de la propia aplicación. El atacante no necesita encontrar una forma externa de inducir a otros usuarios a realizar una solicitud particular que contenga su exploit. Más bien, el atacante coloca su exploit en la propia aplicación y simplemente espera a que los usuarios lo encuentren.
La naturaleza autónoma de las vulnerabilidades de secuencias de comandos entre sitios almacenadas es particularmente relevante en situaciones en las que una vulnerabilidad XSS solo afecta a los usuarios que actualmente están conectados a la aplicación. Si se refleja el XSS, entonces el ataque debe programarse de forma fortuita: un usuario al que se le induce a realizar la solicitud del atacante en un momento en el que no ha iniciado sesión no se verá comprometido. Por el contrario, si se almacena el XSS, se garantiza que el usuario iniciará sesión en el momento en que se encuentre con el exploit.
XSS almacenado en diferentes contextos
Hay muchas variedades diferentes de secuencias de comandos entre sitios almacenadas. La ubicación de los datos almacenados dentro de la respuesta de la aplicación determina qué tipo de carga útil se requiere para explotarla y también podría afectar el impacto de la vulnerabilidad.
Además, si la aplicación realiza alguna validación u otro procesamiento en los datos antes de almacenarlos, o en el momento en que los datos almacenados se incorporan a las respuestas, esto generalmente afectará el tipo de carga útil de XSS que se necesita.
Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!
Cómo encontrar y probar vulnerabilidades XSS almacenadas
Muchas vulnerabilidades XSS almacenadas se pueden encontrar utilizando el escáner de vulnerabilidades web de Burp Suite .
La prueba manual de vulnerabilidades XSS almacenadas puede ser un desafío. Debe probar todos los «puntos de entrada» relevantes a través de los cuales los datos controlables por el atacante pueden ingresar al procesamiento de la aplicación y todos los «puntos de salida» en los que esos datos pueden aparecer en las respuestas de la aplicación.
Los puntos de entrada al procesamiento de la solicitud incluyen:
- Parámetros u otros datos dentro de la cadena de consulta de URL y el cuerpo del mensaje.
- La ruta del archivo URL.
- Encabezados de solicitud HTTP que podrían no ser explotables en relación con XSS reflejado .
- Cualquier ruta fuera de banda a través de la cual un atacante puede enviar datos a la aplicación. Las rutas que existen dependen completamente de la funcionalidad implementada por la aplicación: una aplicación de correo web procesará los datos recibidos en los correos electrónicos; una aplicación que muestra un feed de Twitter podría procesar datos contenidos en tweets de terceros; y un agregador de noticias incluirá datos que se originen en otros sitios web.
Los puntos de salida para los ataques XSS almacenados son todas las posibles respuestas HTTP que se devuelven a cualquier tipo de usuario de la aplicación en cualquier situación.
El primer paso para probar las vulnerabilidades XSS almacenadas es ubicar los enlaces entre los puntos de entrada y salida, mediante los cuales los datos enviados a un punto de entrada se emiten desde un punto de salida. Las razones por las que esto puede ser un desafío son las siguientes:
- Los datos enviados a cualquier punto de entrada podrían, en principio, ser emitidos desde cualquier punto de salida. Por ejemplo, los nombres para mostrar proporcionados por el usuario podrían aparecer dentro de un registro de auditoría oscuro que solo es visible para algunos usuarios de la aplicación.
- Los datos almacenados actualmente por la aplicación a menudo son vulnerables a sobrescribirse debido a otras acciones realizadas dentro de la aplicación. Por ejemplo, una función de búsqueda puede mostrar una lista de búsquedas recientes, que se reemplazan rápidamente a medida que los usuarios realizan otras búsquedas.
Para identificar de manera integral los vínculos entre los puntos de entrada y salida, se necesitaría probar cada permutación por separado, enviar un valor específico al punto de entrada, navegar directamente al punto de salida y determinar si el valor aparece allí. Sin embargo, este enfoque no es práctico en una aplicación con más de unas pocas páginas.
En cambio, un enfoque más realista es trabajar sistemáticamente a través de los puntos de entrada de datos, enviando un valor específico a cada uno y monitoreando las respuestas de la aplicación para detectar casos en los que aparece el valor enviado. Se puede prestar especial atención a las funciones relevantes de la aplicación, como los comentarios en las publicaciones del blog. Cuando el valor enviado se observa en una respuesta, debe determinar si los datos se almacenan en diferentes solicitudes, en lugar de simplemente reflejarse en la respuesta inmediata.
Cuando haya identificado enlaces entre los puntos de entrada y salida en el procesamiento de la aplicación, cada enlace debe probarse específicamente para detectar si hay una vulnerabilidad XSS almacenada. Esto implica determinar el contexto dentro de la respuesta donde aparecen los datos almacenados y probar las cargas útiles de XSS candidatas adecuadas que son aplicables a ese contexto. En este punto, la metodología de prueba es básicamente la misma que para encontrar vulnerabilidades XSS reflejadas .
Si te ha gustado, ¡compártelo con tus amigos!
