XSS Stored
PreviousLaboratorio: DOM XSS en document.write, el receptor usando la fuente location.searchNextLaboratorio: Stored XSS into HTML context with nothing encoded
Last updated
(también conocido como XSS persistente o de segundo orden) surge cuando una aplicación recibe datos de una fuente no confiable e incluye esos datos dentro de sus respuestas HTTP posteriores de manera insegura.
Los datos en cuestión pueden enviarse a la aplicación a través de solicitudes HTTP; por ejemplo, comentarios en una publicación de blog, apodos de usuarios en una sala de chat o detalles de contacto en un pedido de un cliente. En otros casos, los datos pueden llegar de otras fuentes no confiables; por ejemplo, una aplicación de correo web que muestra mensajes recibidos a través de SMTP, una aplicación de marketing que muestra publicaciones en redes sociales o una aplicación de monitoreo de red que muestra datos de paquetes del tráfico de red.
A continuación se muestra un ejemplo sencillo de una vulnerabilidad XSS almacenada. Una aplicación de foro de mensajes permite a los usuarios enviar mensajes que se muestran a otros usuarios:
La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede enviar fácilmente un mensaje que ataque a otros usuarios:
Los scripts entre sitios almacenados (también conocidos como XSS de segundo orden o persistentes) surgen cuando una aplicación recibe datos de una fuente que no es confiable e incluye esos datos dentro de sus respuestas HTTP posteriores de manera insegura.
Supongamos que un sitio web permite a los usuarios enviar comentarios en publicaciones de blogs, que se muestran a otros usuarios. Los usuarios envían comentarios mediante una solicitud HTTP como la siguiente:
Una vez enviado este comentario, cualquier usuario que visite la publicación del blog recibirá lo siguiente dentro de la respuesta de la aplicación:
Suponiendo que la aplicación no realiza ningún otro procesamiento de los datos, un atacante puede enviar un comentario malicioso como este:
Dentro de la solicitud del atacante, este comentario estaría codificado en URL como:
Cualquier usuario que visite la publicación del blog ahora recibirá lo siguiente dentro de la respuesta de la aplicación:
El script proporcionado por el atacante se ejecutará luego en el navegador del usuario víctima, en el contexto de su sesión con la aplicación.
En términos de explotabilidad, la diferencia clave entre XSS reflejado y almacenado es que una vulnerabilidad XSS almacenada permite ataques que están contenidos 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. En lugar de eso, el atacante coloca su exploit en la propia aplicación y simplemente espera a que los usuarios lo encuentren.
La naturaleza autónoma de los exploits de secuencias de comandos entre sitios almacenados es particularmente relevante en situaciones en las que una vulnerabilidad XSS solo afecta a los usuarios que están conectados a la aplicación. Si el XSS se refleja, entonces el ataque debe tener un momento fortuito: un usuario que se vea inducido a realizar la solicitud del atacante en un momento en el que no esté conectado no se verá comprometido. Por el contrario, si el XSS se almacena, entonces se garantiza que el usuario estará conectado en el momento en que se encuentre con el exploit.
Existen 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 puede afectar el impacto de la vulnerabilidad.
Además, si la aplicación realiza alguna validación u otro procesamiento de los datos antes de almacenarlos, o en el momento en que los datos almacenados se incorporan a las respuestas, esto generalmente afectará qué tipo de carga útil XSS se necesita.
El primer paso para comprobar las vulnerabilidades XSS almacenadas es localizar los vínculos entre los puntos de entrada y salida, por los que los datos enviados a un punto de entrada se emiten desde un punto de salida. Las razones por las que esto puede resultar complicado son las siguientes:
En principio, los datos enviados a cualquier punto de entrada podrían emitirse desde cualquier punto de salida. Por ejemplo, los nombres de usuario proporcionados por el usuario podrían aparecer en un registro de auditoría poco claro que solo es visible para algunos usuarios de la aplicación.
Los datos que la aplicación almacena actualmente suelen ser vulnerables a que se sobrescriban debido a otras acciones que se realizan 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 forma exhaustiva los vínculos entre los puntos de entrada y salida, sería necesario 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 consiste en trabajar sistemáticamente a través de los puntos de entrada de datos, enviando un valor específico a cada uno de ellos y monitoreando las respuestas de la aplicación para detectar casos en los que aparezca el valor enviado. Se puede prestar especial atención a las funciones relevantes de la aplicación, como los comentarios en las publicaciones de blogs. Cuando se observa el valor enviado en una respuesta, es necesario determinar si los datos se almacenan en realidad en diferentes solicitudes, en lugar de simplemente reflejarse en la respuesta inmediata.
Cuando el contexto XSS es algún JavaScript existente dentro de un atributo de etiqueta entre comillas, como un controlador de eventos, es posible utilizar la codificación HTML para evitar algunos filtros de entrada.
Cuando el navegador haya analizado las etiquetas y atributos HTML dentro de una respuesta, realizará una decodificación HTML de los valores de los atributos de las etiquetas antes de que se procesen más. Si la aplicación del lado del servidor bloquea o desinfecta ciertos caracteres que son necesarios para una explotación XSS exitosa, a menudo puede omitir la validación de entrada codificando esos caracteres en HTML.
Por ejemplo, si el contexto XSS es el siguiente:
y la aplicación bloquea o escapa de los caracteres de comillas simples, puede usar la siguiente carga útil para salir de la cadena de JavaScript y ejecutar su propio script:
La 'secuencia es una entidad HTML que representa un apóstrofo o una comilla simple. Debido a que el navegador decodifica en HTML el valor del onclickatributo antes de que se interprete el código JavaScript, las entidades se decodifican como comillas, que se convierten en delimitadores de cadena, y por lo tanto el ataque tiene éxito.
Si un atacante puede controlar un script que se ejecuta en el navegador de la víctima, por lo general puede comprometer por completo a ese usuario. El atacante puede llevar a cabo cualquiera de las acciones que se aplican al impacto de las .
Cuando haya identificado vínculos entre los puntos de entrada y salida en el procesamiento de la aplicación, cada vínculo debe probarse específicamente para detectar si existe una vulnerabilidad XSS almacenada. Esto implica determinar el contexto dentro de la respuesta donde aparecen los datos almacenados y probar cargas útiles XSS candidatas adecuadas que sean aplicables a ese contexto. En este punto, la metodología de prueba es en líneas generales la misma que para encontrar .
