XSS reflejado, almacenado y basado en DOM

La diferencia entre los tres tipos no es qué hace el navegador, sino por dónde llega la entrada. En el reflejado, el valor viaja en la petición y vuelve en la respuesta a esa misma petición. En el almacenado, la aplicación lo guarda y lo sirve después a quien abra la página, sin que esa persona haya enviado nada. En el basado en DOM, el servidor ni siquiera lo ve: un script del navegador lo toma de la dirección o de otra fuente y lo escribe en la página.

Esa diferencia decide a quién alcanza el fallo y cómo se arregla. Abre respuestas-html.txt y lee con cuidado el caso X-2: dónde se envió, dónde apareció y quién lo vio.

Un control que funciona también se anota: se dice en el informe qué se probó y qué estaba bien resuelto, para que nadie lo reabra sin motivo. En XSS, el control correcto es la codificación de la salida: los caracteres que tienen significado en HTML se convierten en sus equivalentes de texto, y el navegador los muestra tal cual en lugar de interpretarlos.

Compara la fuente de cada campo en respuestas-html.txt. Uno de los cuatro convierte lo recibido en texto visible.

En X-4, la fuente que envía el servidor no contiene la marca y, sin embargo, el árbol del navegador sí. Esa es la señal de un XSS basado en DOM: ver la fuente de la página no basta, hay que inspeccionar lo que el navegador construye después de ejecutar los scripts. La causa se busca en el script que toma la entrada de una fuente (aquí, la dirección) y la escribe en la página con una función que interpreta HTML.

Lee promo-js.txt. La corrección es escribir ese valor como texto, no como HTML.

La corrección del XSS es codificar según el contexto donde se escribe el valor: una codificación para el cuerpo de la página, otra para un atributo, otra para un script. Es lo que recoge CWE-79 como defensa más eficaz. En el navegador, la regla equivalente es escribir con una API que trate el valor como texto en lugar de como HTML.

Quitar de la entrada las etiquetas «conocidas» no funciona: siempre hay otra forma de escribir formato, y un dato que hoy es un nombre mañana se escribe en otro contexto. Una política de contenido (CSP) y la cookie de sesión con el atributo HttpOnly reducen el daño, pero son capas adicionales.

El impacto de un XSS almacenado depende de cuántas personas abren la página donde quedó guardado. Esa cifra se calcula de la evidencia: en el registro de visitas, cada fila es una vista de la ficha en la que apareció la marca, y una misma sesión puede aparecer varias veces. El informe cuenta sesiones distintas, no filas, porque lo que importa es cuántas personas distintas lo vieron.