> For the complete documentation index, see [llms.txt](https://w0lf-f4ng.gitbook.io/cheat-sheet/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://w0lf-f4ng.gitbook.io/cheat-sheet/pentesting-web/vulnerabilidades/cross-site-scripting-xss/stored-xss.md). # Stored XSS Stored XSS (o Persistent XSS) se produce cuando el payload inyectado es almacenado en la base de datos del back-end y es consumido por cada visitante de la página web. ## Impacto del ataque de un Stored XSS Si un atacante puede controlar un script que es ejecutado en el navegador de la víctima, puede comprometer a dicho usuario. En este caso, el atacante puede llevar a cabo cualquier acción aplicada al Impacto del ataque de un Reflected XSS. En términos de explotabilidad, la diferencia clave entre el Reflected XSS y el Stored XSS es que una vulnerabilidad Stored XSS permite ataques que están autocontenidos dentro de la propia aplicación. ## Stored XSS en contexto HTML sin nada codificado > El siguiente sitio posee un Stored XSS en la función de comentarios. Al revisar el sitio, vemos que este es un blog, el cual, posee múltiples post:

Al ingresar a uno de los posts, vemos que tiene la opción de dejar comentarios:

Validamos si podemos modificar estos campos usando etiquetas HTML agregando el tag H1 en el nombre y en el comentario:

Como se puede apreciar, la etiqueta se refleja en la sección comentario y no en el nombre, debido a que, en el nombre, los caracteres se encuentran codificados en HTML:

Ahora le agregamos el siguiente payload para poder explotar el XSS: ```html ```

Este se ve reflejado en la respuesta:

Y cada vez que alguien consuma este post, el script será ejecutado:

## Stored XSS en el tag anchor con atributo href con comillas dobles codificado en HTML > El siguiente sitio posee un Stored XSS en la función de comentarios. Al revisar el sitio, es un blog, el cual, posee múltiples post:

Al ingresar a uno de los posts, vemos que tiene la opción de dejar comentarios:

Ingresamos datos para validar como son procesados:

Vemos que se reflejan los datos ingresados en los parámetros `Comment`, `Name` y `Website`:

En el parámetro `Website` usamos el siguiente payload `javascript:alert(1)`:

Este payload no es codificado en la respuesta:

Al momento de hacer clic en el enlace, se explota el XSS:

## Explotación de XSS para robar cookies Al revisar el sitio, es un blog, el cual, posee múltiples post:

Al ingresar a uno de los posts, vemos que tiene la opción de dejar comentarios:

En la sección comentarios agregamos el siguiente payload con una dirección de la herramienta [Collaborator](https://portswigger.net/burp/documentation/desktop/tools/collaborator): ```html ```

Vemos que lo ingresado se refleja en la respuesta:

Al revisar Collaborator, vemos que en el body del request se mandan las cookies del usuario que está revisando el post:

Estas cookies las podemos agregar a nuestro cookie jar para personificar a dicho usuario:

## Explotando XSS para capturar contraseñas Al revisar el sitio, es un blog, el cual, posee múltiples post y un login:

En el login, vemos que se encuentran los inputs para el username y el password:

En los posts posee una opción para dejar comentarios:

En la porción de comentarios agregamos el siguiente payload para obtener las credenciales de algún usuario: ```html ```

Al revisar los mensajes recibidos en el Collaborator, vemos que tenemos las credenciales del usuario `administrator`:

Ingresamos las credenciales en el portal de login y accedemos a la cuenta de dicho usuario: