Explica el XSS almacenado, reflejado y basado en el DOM.
Respuesta breve
Todo XSS inyecta un script controlado por el atacante en el navegador de una víctima. El XSS almacenado persiste la carga útil en el servidor (por ejemplo, un comentario) y afecta a todos los que la ven; el XSS reflejado rebota la carga útil desde el servidor en una sola respuesta, normalmente mediante un enlace manipulado; el XSS basado en el DOM nunca llega a la lógica del servidor — JavaScript vulnerable del lado del cliente escribe entrada no confiable en la página.
El cross-site scripting (XSS) es la clase de errores en la que un atacante consigue que su JavaScript se ejecute en la sesión de navegador de otro usuario, dentro del origen de confianza de tu sitio. Una vez que eso ocurre, el script puede leer cookies, el DOM y tokens, hacer peticiones autenticadas y suplantar a la víctima. Las tres variantes difieren en dónde vive la carga útil y cómo llega a ejecutarse — y esa diferencia guía tanto la detección como la solución.
Almacenado (persistente)
La carga útil se guarda en el servidor — en una base de datos, un campo de comentario, un nombre de perfil — y se sirve de vuelta a cada usuario que carga ese contenido. Es la forma más peligrosa porque no necesita interacción por víctima y puede propagarse como un gusano. Un único <script> inyectado en una publicación de foro puede afectar a miles de sesiones.
Reflejado (no persistente)
La carga útil se incluye en una petición (un parámetro de consulta, un campo de formulario) y se refleja inmediatamente en la respuesta sin almacenarse. El atacante debe atraer a cada víctima para que haga clic en un enlace manipulado o envíe un formulario malicioso. Es de un solo disparo por víctima, pero devastador en el phishing.
Basado en el DOM
Aquí el servidor puede ser completamente inocente. JavaScript del lado del cliente vulnerable lee entrada controlable por el atacante (como location.hash) y la escribe en un sumidero peligroso como innerHTML, document.write o eval. La carga útil puede no aparecer en ningún cuerpo de petición HTTP que el servidor procese, por lo que los WAF y registros del lado del servidor pueden pasarla por alto. El propio script inyectado procede de las mismas familias de payloads de XSS independientemente de cómo llegue al sumidero.
Por qué importa la distinción
El almacenado y el reflejado se mitigan en gran medida con codificación de salida contextual en el servidor y una Content-Security-Policy fuerte. El XSS del DOM debe corregirse en el código del cliente — usando API seguras como textContent y setAttribute en lugar de innerHTML.
Los entrevistadores buscan el enfoque dónde/cómo, nombrar un sumidero concreto para el XSS del DOM, y la conciencia de que el XSS almacenado suele ser la máxima prioridad por su radio de impacto.
Posibles preguntas de seguimiento
- ¿Por qué el XSS basado en el DOM es a veces invisible para un WAF del lado del servidor?
- ¿Qué sumideros (innerHTML, document.write) hacen posible el XSS del DOM?
- ¿Cómo priorizarías la corrección del XSS almacenado vs reflejado?