XSS en React: dangerouslySetInnerHTML y scripts de terceros

React escapa automáticamente todos los valores renderizados mediante JSX antes de insertarlos en el DOM. Cuando escribe {userInput} en JSX, React realiza el equivalente a asignar mediante textContent; el valor se trata como texto, nunca como HTML. De forma predeterminada, esto evita la mayoría de los ataques XSS en las aplicaciones de React.

dangerouslySetInnerHTML={{ __html: htmlString }} es el mecanismo de escape de React que omite el escape automático. El nombre es intencionadamente alarmante: indica que usted asume la responsabilidad de la seguridad de la cadena HTML. React establece innerHTML directamente y ejecuta cualquier HTML, incluidos scripts y controladores de eventos.

Realmente necesita dangerouslySetInnerHTML al renderizar HTML procedente de un editor de texto enriquecido (como TipTap o Quill), de un CMS que almacena HTML o de un convertidor de Markdown a HTML. Estas fuentes producen marcado HTML real que debe renderizarse como HTML, no como texto escapado.

Si la cadena HTML contiene <script>stealCookies()</script> o <img src=x onerror="stealData()">, establecerla como innerHTML ejecuta el código del atacante. Cualquier contenido proporcionado por el usuario que se pase directamente a dangerouslySetInnerHTML sin sanitización constituye una vulnerabilidad XSS crítica.

DOMPurify es el sanitizador de HTML estándar del sector para navegadores. Analiza la cadena HTML en un contexto aislado, elimina elementos y atributos peligrosos (etiquetas de script, controladores de eventos y URL javascript:) y devuelve una cadena HTML segura. Uso: DOMPurify.sanitize(dirtyHtml) antes de pasarla a dangerouslySetInnerHTML.

Los scripts de terceros (analítica, widgets de chat y redes publicitarias) se ejecutan con los mismos permisos que el JavaScript de su aplicación. Un script de terceros comprometido o malicioso puede leer document.cookie, acceder a localStorage, leer los campos de los formularios y realizar solicitudes a servidores externos, todo ello sin que el usuario lo advierta.

Content Security Policy es una cabecera HTTP que declara qué scripts pueden ejecutarse. Aunque se inyecte una carga útil XSS en el DOM, una CSP configurada correctamente puede bloquear su ejecución al restringir los scripts en línea y permitir únicamente fuentes de scripts incluidas en la lista de confianza. CSP es la segunda línea de defensa después de la sanitización de entradas.

Los paquetes de npm son un vector de ataque XSS real. Una dependencia puede incluir código malicioso que exfiltre variables de entorno o datos de usuarios. El incidente de node-ipc de 2022 y el compromiso de ua-parser-js de 2021 demostraron que paquetes ampliamente utilizados pueden ser tomados y manipulados con código malicioso. Audite las dependencias con npm audit y utilice archivos de bloqueo.

Un ataque XSS exitoso permite al atacante robar el token JWT del usuario almacenado en sessionStorage (enviándolo a un servidor controlado por el atacante), realizar acciones como el usuario autenticado (llamadas a la API utilizando la sesión del usuario), modificar el DOM para mostrar contenido de phishing o registrar cada pulsación de tecla que el usuario realice en la aplicación.

La API del navegador Trusted Types exige que todos los puntos de inserción del DOM (innerHTML, eval, script.src) reciban objetos con tipos especiales en lugar de cadenas sin procesar. Esto impide que las cargas útiles XSS basadas en cadenas lleguen al DOM desde la propia plataforma. React está trabajando para ofrecer compatibilidad con Trusted Types y CSP puede exigir su uso.

El patrón seguro para renderizar HTML de un CMS es el siguiente: obtenga el HTML, páselo por DOMPurify.sanitize() con una lista de elementos y atributos seguros permitidos y, después, renderícelo con dangerouslySetInnerHTML={{ __html: cleanHtml }}. Nunca omita el paso de sanitización, aunque confíe en el CMS, porque la propia base de datos del CMS podría estar comprometida.

¿Qué hace DOMPurify cuando se llama a DOMPurify.sanitize(htmlString)?

React escapa automáticamente los valores de JSX, lo que evita la mayoría de los ataques XSS. dangerouslySetInnerHTML omite esta protección para permitir el renderizado legítimo de HTML; sanitice siempre la entrada con DOMPurify primero. Los scripts de terceros y los paquetes de npm comprometidos son vectores de XSS en la cadena de suministro. Content Security Policy proporciona una segunda capa de defensa. Un ataque XSS exitoso permite robar tokens, suplantar identidades y mostrar phishing.