Hay dos formas en que XSS y SQLi podrían interactuar. El comentario que citó es de esta pregunta y es claramente con respecto al primer punto.
SQLi a través de XSS
Si sabe que una aplicación es vulnerable a la inyección de SQL, pero no tiene los permisos necesarios para acceder al componente vulnerable, es posible que pueda aprovechar una vulnerabilidad de XSS existente y así obtener un usuario más privilegiado para realizar el SQL inyección para usted.
Como señala, la búsqueda de vulnerabilidades en componentes a los que no tiene acceso puede no ser tan fácil. Sin embargo, todavía hay al menos dos casos en que esto puede suceder fácilmente:
- software de código abierto
- Acceso temporal al código fuente (tal vez a través de un auditor externo, a través de filtraciones de correo electrónico, a través de un ex empleado descontento, a través de vulnerabilidades en su control de fuente, ...)
Para inyecciones muy simples, un atacante también puede simplemente adivinar un ataque (tal vez un atacante sepa que su aplicación no se defiende contra SQLi en absoluto, pero todas las inyecciones en los componentes a los que tienen acceso están usando una base de datos de usuarios con permisos restringidos ; aquí podrían ser capaces de adivinar los nombres de script y parámetros de otros componentes y explotarlos a través de XSS).
Teóricamente, también podría imaginar una configuración en la que los usuarios más privilegiados siempre estén utilizando una conexión de base de datos con un usuario más privilegiado de la base de datos, por lo que incluso una inyección en componentes públicos puede ser más potente si se explota a través de un usuario más privilegiado a través de XSS. / p>
Los últimos ejemplos son un poco artificiales, pero ciertamente posibles. Probablemente hay otros ejemplos también.
XSS a través de SQLi
En este caso, tiene una inyección SQL, pero no puede lograr nada interesante con ella. La inyección puede realizarse con un usuario de base de datos muy restringido, que, por ejemplo, solo puede leer datos ya disponibles públicamente (pero no puede leer otros datos, escribir datos, escribir o leer archivos del sistema, ejecutar comandos, etc.) tampoco existen vulnerabilidades en los dbms puedes explotar).
En este caso, es posible que pueda realizar un ataque XSS reflejado o almacenado a través de SQLi.