XSS Moderno: DOM, Stored y Reflected con Ejemplos Reales en Entorno de Pruebas

En 2025 el informe de HackerOne registro XSS como el segundo bug mas reportado en programas publicos, con mediana de USD 750 por hallazgo y picos de USD 20 mil en objetivos enterprise. La familia sigue viva porque los navegadores evolucionaron, pero los pipelines de frontend todavia concatenan strings en innerHTML sin ceremonia. El equipo Basilisk abre un laboratorio con tres aplicaciones intencionalmente vulnerables, registra peticiones en Burp Suite Community 2026.4 y muestra cada vector con payload, contexto y parche. Antes de avanzar, asegura que tu lab este aislado segun Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite, porque ejecutar payloads contra terceros sin autorizacion escrita sigue siendo delito en la mayoria de jurisdicciones latinoamericanas.

Reflected XSS aparece cuando la entrada del usuario regresa en la respuesta HTTP sin codificacion adecuada, generalmente via querystring o formulario GET. En nuestro lab una busqueda en /search?q= concatena el termino dentro de un

, asi que el payload clasico

Stored XSS es el mas peligroso porque persiste en la base y alcanza a cualquier visitante. En DVWA fijamos el nivel medium, enviamos en el campo de comentario el payload y observamos al webhook recibir sesiones de moderadores en segundos. En apps reales la superficie incluye renderers de Markdown, plantillas de email, exports CSV abiertos en Excel e incluso metadatos EXIF leidos por un dashboard interno, como detallamos en Higiene de Metadatos: Limpiando EXIF, PDF y Office antes de Publicar. La unica defensa robusta combina sanitizacion en el input con escape en el output, nunca uno u otro aislado.

DOM-based XSS ocurre enteramente en el cliente, sin que el payload toque el servidor. El clasico location.hash inyectado en document.write todavia existe en widgets legados de chat y en SPAs que usan React dangerouslySetInnerHTML con datos del hash. En el lab usamos el desafio nivel 1 del Google XSS Game adaptado, y la clave para encontrar sinks es abrir DevTools, marcar 'Pause on exceptions' y usar la extension DOM Invader de Burp. El flujo de triaje sigue el mismo principio metodologico de SQL Injection en la Practica: Explotar, Detectar y Mitigar en Lab Controlado: identificar source, rastrear hasta el sink, validar con payload minimo.

La mitigacion moderna ya no se trata de filtrar < y >. Content Security Policy nivel 3 con nonce por peticion bloquea inyeccion inline incluso cuando el atacante consigue colocar HTML en la pagina, siempre que no caigas en la trampa de agregar 'unsafe-inline' como fallback. Trusted Types, soportado en Chromium desde 83 y finalmente en Firefox 135, convierte las asignaciones a innerHTML en type error a menos que pasen por una policy registrada. Combina con DOMPurify 3.2 para sanitizar HTML rico y reduces la superficie en 90% segun benchmarks de Google. Para entornos con APIs internas, alinea con AppSec Shift-Left: SAST, SCA y Escaneo de Secretos sin Frenar al Equipo y corre Semgrep con la regla javascript.lang.security.audit.xss en cada PR.

El takeaway practico: monta hoy un lab con DVWA, Juice Shop y un Next.js minimo, replica los tres vectores hasta lograr un popup en cada uno, despues aplica CSP con nonce, Trusted Types y DOMPurify y reejecuta los mismos payloads. Si todavia disparan, ajusta la policy hasta romperla. Documenta cada iteracion en un runbook propio porque los reportes buenos de XSS en los programas de bounty de Mercado Libre, GitHub o Shopify exigen reproduccion en una frase, impacto comprobado y parche sugerido. Estudia tambien Threat Modeling con STRIDE en Sprints: Ejemplo Completo de un Microservicio para clasificar cada inyeccion dentro del dominio Tampering+Elevation antes de subir el ticket, eso cambia el triage a P1 mas rapido.