El punto 1. es más un problema de self-XSS (basado en DOM). Y como dijiste, los puntos 2 y 3 son realmente iguales (el ataque ocurre al visitar una URL).
Una solicitud GET a través de un enlace es la forma más común de ejecutar un ataque XSS. El enlace podría, por ejemplo, enviarse a una víctima por correo electrónico o publicarse en un foro.
Pero hay otras formas. La característica definitoria del XSS reflejado es que la entrada es reflejada , lo que significa que el servidor toma algún tipo de valor de una solicitud HTTP, la inserta en un contexto HTML en la respuesta y el navegador luego la presenta. , ejecutando así el código inyectado.
XSS reflejados basados en POST
El XSS reflejado también se puede realizar a través de solicitudes POST (que no están protegidas contra CSRF). Por ejemplo:
<form action="https://example.com/vulnerable" method="POST">
<input type="hidden" name="number" value="[XSS payload]" />
</form>
<script>document.forms[0].submit();</script>
De la misma manera, una solicitud GET podría enviarse a través de un formulario (cambiando el method a GET ). Un atacante podría elegir este método si se requiere una solicitud POST, o si cree que es más probable que un usuario visite una página donde pueda publicar guiones, y menos probable que haga clic en un enlace al sitio de la víctima.
Explotación de Self-XSS
Su punto 1. podría explotarse si el sitio se puede enmarcar. Algunos navegadores (p. Ej., La última vez que verifiqué Firefox) permiten arrastrar texto a iframes (aunque no fuera de ellos).
Al realizar un ataque de clickjacking, un atacante podría hacer que una víctima "ingrese" la carga útil XSS y la ejecute.
Otra forma de ejecutar un auto-XSS sería simplemente pedirle al usuario que publique la carga útil ("¿puede publicar este post largo, en formato HTML [que contiene una carga XSS] en su sitio web?", "¿Puede cargar este ¿imagen inofensiva [cuyo nombre de archivo contiene una carga XSS] en tu blog? ", etc.).
Tokens de sesión como (no) protección
¿Los tokens de sesión nos protegen de estos enfoques?
Si sus tokens de sesión siempre se incluyen en la URL, y la página no refleja ninguna entrada cuando falta el token de sesión (y el token de sesión se genera de forma segura), entonces eso sí proteger contra XSS reflejados (no propios) que envían a la víctima un enlace malicioso. De la misma manera, los tokens CSRF protegen las solicitudes contra XSS reflejadas (no propias).
Sin embargo, ahora tienes un nuevo problema. Los datos confidenciales en las direcciones URL se desaconseja. Puede filtrarse fácilmente a través de los remitentes, cuando los usuarios comparten enlaces, etc. Y una vez que eso suceda, cualquiera podría tener acceso a esa cuenta de usuario.