La confusión con la inyección SQL es comprensible porque en ambos ataques el atacante puede introducir contenido malicioso mediante formularios o parámetros de una URL. La diferencia está en QUÉ SE INYECTA Y DÓNDE SE EJECUTA.
¿Por qué la respuesta correcta es Cross-Site Scripting?
El enunciado nos da la pista fundamental cuando indica que el código malicioso:
Es almacenado por el servidor y posteriormente EJECUTADO EN EL NAVEGADOR DE LOS USUARIOS que visualizan el contenido.
Eso describe concretamente un XSS almacenado o persistente (Stored XSS).
Por ejemplo, un atacante podría introducir código JavaScript malicioso en el campo de comentarios de una página web. Si el servidor almacena ese contenido sin neutralizarlo, cada vez que otro usuario consulte esos comentarios, EL CÓDIGO SE EJECUTARÁ EN SU NAVEGADOR.
¿Por qué no es una inyección SQL?
En una inyección SQL también se aprovecha una entrada de datos, como un formulario o un parámetro de URL, pero el objetivo es diferente:
INYECCIÓN SQL: introducir instrucciones SQL para manipular las consultas que realiza la aplicación contra la BASE DE DATOS.
XSS: introducir código, normalmente JavaScript, destinado a ejecutarse posteriormente en el NAVEGADOR DE LA VÍCTIMA.
Por tanto, que el ataque utilice un formulario o un parámetro de URL no determina por sí solo qué tipo de ataque es. Hay que observar cuál es su finalidad.
Truco para distinguirlos en un test
XSS → CÓDIGO QUE SE EJECUTA EN EL NAVEGADOR.
SQL INJECTION → INSTRUCCIONES QUE ATACAN O MANIPULAN LA BASE DE DATOS.
REPLAY DE SESIÓN → REUTILIZACIÓN DE DATOS O CREDENCIALES CAPTURADOS PREVIAMENTE.
En esta pregunta, además, la expresión «almacenado por el servidor y posteriormente ejecutado en el navegador de cualquier usuario» permite identificar de forma bastante clara un XSS ALMACENADO O PERSISTENTE.