Creo que definitivamente no lo es, porque XSS que no se guarda en ningún lugar dañaría SOLAMENTE al atacante.
¿Tengo razón o hay algún caso en el que XSS podría dañar la aplicación que no es de db? (Me refiero a que los datos no se guardan en ninguna parte)
Muy mal, la forma básica de XSS es Reflected XSS, donde la carga útil se envía en la URL (por ejemplo) desde la propia víctima.
Esto es más comúnmente usado en ataques de phishing, donde el atacante crea el enlace malicioso y lo envía por correo en ataques de ingeniería social a sus víctimas, o lo publica en foros públicos, etc.
En general, XSS no tiene nada que ver con la base de datos (a menos que sea XSS persistente / almacenado).
Consulte XSS en OWASP para obtener más detalles.
Hay muchas maneras en que XSS puede explotar y hacer mucho daño sin tener que ser almacenado en una base de datos. ¡Recuerde que el XSS puede incluso almacenarse en cookies !
Sin embargo, si solo se trata de un XSS no persistente reflejado, todavía es muy peligroso, pero más desde el punto de vista de la ingeniería social. Esto se debe a que tiene que distribuir la carga útil XSS en lugar de que se propague por sí sola. Los medios de distribución de la carga útil pueden ser, por ejemplo:
Un buen ejemplo de los peligros de XSS con o sin una base de datos adjunta se puede ver en el Proyecto BEEF . Esto muestra algunas de las cosas que se pueden hacer en un navegador de usuarios una vez que se ha visto afectado por un problema de XSS.
Si mira los videos de YouTube en esta página hay algunos buenos ejemplos de lo que se puede hacer.
Me imagino que si XSS es una vulnerabilidad, el siguiente paso es analizar la inyección de código. Vamos a usar SSI por ejemplo. Si esto funciona:
<javascript>alert('x');</javascript>
Entonces es posible que esto funcione también:
<!--#exec cmd="ls /" -->
No importa qué, debes sanear tu entrada.
Más información sobre la inyección de SSI aquí .
Lea otras preguntas en las etiquetas web-application appsec xss