El XSS basado en DOM se produce cuando se ejecutan scripts maliciosos a través de JavaScript del lado del cliente que modifica el DOM de forma insegura. A diferencia del XSS tradicional, estos ataques no necesitan interactuar con el servidor. Suelen explotar JavaScript vulnerable que procesa datos de fuentes inseguras como los parámetros de la URL. La prevención requiere un manejo cuidadoso de la entrada del usuario en el código del lado del cliente y una codificación de salida adecuada.
El cross-site scripting basado en el DOM es un fallo del lado del cliente en el que la vulnerabilidad reside por completo en el JavaScript de la página en lugar de en la respuesta del servidor. La página lee datos de una fuente que el atacante puede influir, habitualmente el fragmento de la URL (location.hash), la cadena de consulta, document.referrer o el almacenamiento web, y los pasa a un sink peligroso como innerHTML, el método write del documento o eval sin sanearlos. El navegador entonces interpreta los datos del atacante como marcado o código y los ejecuta. Como el valor contaminado puede que nunca salga del navegador, el payload puede situarse tras el hash en una URL, algo que los servidores no reciben, de modo que el servidor nunca ve el ataque y no puede registrarlo ni filtrarlo.
El XSS en el DOM otorga los mismos poderes dentro del origen que otros XSS: leer tokens y datos de la página, falsificar peticiones y reescribir la interfaz, todo bajo el origen de confianza del sitio. Es fácil pasarlo por alto porque las defensas del lado del servidor, los firewalls de aplicaciones web y el registro de peticiones no se aplican a datos que permanecen en el navegador o se esconden en el fragmento de la URL. Las aplicaciones de página única modernas están especialmente expuestas, ya que el enrutamiento, el uso de plantillas y el renderizado ocurren todos en el cliente y dependen en gran medida de valores de la URL y del almacenamiento. A medida que los frameworks trasladan más lógica al navegador, los sinks basados en el DOM se multiplican, y una sola asignación insegura a innerHTML en un componente muy usado puede exponer cada página que lo renderice.
Evita el XSS en el DOM manteniendo los datos no confiables fuera de los sinks peligrosos: prefiere textContent en lugar de innerHTML, evita eval y los métodos heredados de escritura del documento, y canaliza cualquier HTML que debas insertar a través de un saneador de confianza o de la Sanitizer API del navegador y Trusted Types. El data binding de los frameworks y una Content Security Policy reducen la superficie restante. cside no reescribe la lógica del DOM de tu aplicación, pero sí vigila lo que se ejecuta en el navegador en tiempo real. Su método Script analiza los payloads de los scripts de terceros, puede bloquear comportamientos maliciosos y registra lo que realmente se ejecutó, de modo que un script inyectado o comprometido que intente exfiltrar datos se detecta por su comportamiento y no por su origen, y esa evidencia respalda PCI DSS 6.4.3 y 11.6.1.
En el XSS reflejado el servidor inyecta el payload en el HTML que devuelve. En el XSS basado en el DOM la respuesta del servidor está limpia, y el fallo está en el JavaScript del lado del cliente que lee un valor controlado por el atacante y lo escribe en un sink peligroso. El exploit puede vivir en el fragmento de la URL, que el servidor nunca recibe.
Porque el payload a menudo nunca llega al servidor. Los valores colocados tras el hash en una URL permanecen en el navegador, y otras fuentes como el almacenamiento local o el referrer se procesan puramente en el cliente. Un firewall solo inspecciona el tráfico que ve, así que es ciego ante los ataques ejecutados enteramente dentro del DOM.
We answer client-side security questions every day. Bring yours.