El fuerte aumento de las inyecciones DOM: por qué las soluciones antifraude tradicionales están fallando

La mayoría de los sistemas antifraude y de seguridad hoy analizan únicamente la transacción ya finalizada: las señales que contiene y en qué medida el comportamiento del usuario coincide con los patrones establecidos. Durante años, los ataques de cross-site scripting (XSS) se consideraban relativamente fáciles de detectar y controlar. El código malicioso se inyectaba a través de parámetros de solicitud, se ejecutaba en el navegador y dejaba rastros evidentes — en la URL, en los registros del servidor y en el comportamiento de la página. Los escenarios clásicos, como el XSS almacenado y el XSS reflejado, normalmente podían identificarse y bloquearse a nivel de aplicación, mediante firewalls de aplicaciones web (WAF) o mediante lógica del lado del servidor.

Hoy, la propia estructura de estos ataques ha cambiado. La amenaza ha evolucionado hacia XSS basado en DOM, y el vector de ataque se ha desplazado directamente al navegador. En lugar de una inyección evidente, los atacantes ahora interfieren con la página después de que se ha cargado — manipulando el DOM (Document Object Model), que controla la estructura de la interfaz, los elementos dinámicos y el comportamiento de las aplicaciones web.

A medida que las arquitecturas de front-end se vuelven más complejas, aumenta la dependencia de scripts de terceros y se generaliza el uso de herramientas especializadas para manipular el navegador, las transacciones se forman cada vez más dentro de un entorno del navegador que ya ha sido alterado. El servidor recibe lo que parece ser una solicitud perfectamente válida, y los sistemas de monitoreo observan señales “normales”, aunque en realidad el usuario esté interactuando con una página o funcionalidad modificada.

En este artículo analizamos:

• Cómo el XSS ha evolucionado hacia inyecciones en el DOM y la toma de control del lado del cliente (también conocida como ataques Man-in-the-Browser o MITB);
• Cómo y en qué medida este problema se manifiesta en distintas regiones del mundo;
• Por qué los enfoques clásicos de seguridad y antifraude no detectan estos escenarios;
• Qué estrategias de defensa realmente funcionan.

El análisis tradicional de transacciones no contempla la etapa en la que la transacción se forma — y es precisamente ahí donde ahora se concentra una proporción creciente de ataques, con un crecimiento exponencial.

¿Qué es la toma de control del lado del cliente (ataque MITB)?

Los ataques modernos ocurren cada vez más no mediante cambios visibles en la barra de direcciones, sino de forma silenciosa dentro del navegador del usuario — sin recargas de página, sin modificaciones de URL y sin huellas evidentes en el servidor. El usuario opera en un entorno alterado del lado del cliente, mientras que el servidor y muchos sistemas antifraude siguen viendo una sesión aparentemente legítima.

Este es el cambio clave: la amenaza ha pasado de anomalías detectables en el servidor a manipulaciones invisibles de la lógica de la interfaz y del comportamiento del usuario directamente en el navegador. En este contexto, “toma de control” significa una apropiación encubierta del entorno del lado del cliente.

Cómo el XSS se trasladó al navegador: de vulnerabilidades del servidor a ataques DOM

El XSS clásico era sencillo. El código malicioso entraba a través de un parámetro en la URL — por ejemplo, ?search=<script>...</script> — se ejecutaba inmediatamente en el navegador y dejaba señales visibles.

Las inyecciones DOM funcionan de manera distinta. En lugar de ataques ruidosos basados en URL, los atacantes modifican elementos críticos de la página después de que esta se ha cargado. Por ejemplo, pueden cambiar document.querySelector('.payment-form').action de modo que el formulario de pago siga funcionando con normalidad, pero todos los datos se redirijan silenciosamente a un destino controlado por el atacante o se alteren mediante señales artificiales que afectan al scoring de riesgo.

Esta sustitución puede producirse mediante extensiones maliciosas del navegador, scripts de terceros comprometidos, paquetes NPM contaminados, navegadores especializados o infectados, malware a nivel de dispositivo o cualquier código que obtenga acceso al DOM.

Desde la perspectiva del servidor, el problema es que suele recibir una solicitud completamente normal. Los sistemas backend registran actividad normal del usuario. Incluso los WAF no detectan URL sospechosas, firmas de ataque ni errores. En esta nueva realidad, las herramientas antifraude tradicionales orientadas al servidor son prácticamente ciegas ante la interferencia.

Las APIs del navegador más peligrosas en manos de atacantes

Los atacantes no necesitan inventar nuevas herramientas. Simplemente reutilizan APIs estándar del navegador — las mismas que se usan para operaciones legítimas de la interfaz — y las convierten en mecanismos de interceptación y sustitución.

El objetivo principal son los eventos. El escenario más evidente es la interceptación del evento submit. En ese momento, el usuario ya ha completado el formulario, los datos están listos para enviarse y, desde la lógica de la aplicación, todo parece correcto. Es ahí donde el código malicioso obtiene el máximo control: puede copiar los datos, modificarlos o secuestrar completamente el envío y redirigirlo.

El usuario no percibe nada inusual — ve la pantalla habitual de confirmación (“Pago exitoso”). Sin embargo, el evento submit es solo una parte. En la práctica, los atacantes pueden acceder a cadenas completas de acciones del usuario o a suficientes eventos como para comprometer la cuenta.

El código malicioso moderno rara vez se limita a una sola acción. Junto con el ataque principal — como cambiar form.action o interceptar datos — genera actividad en segundo plano: crea y elimina nodos del DOM, añade manejadores de eventos, envía solicitudes de red aparentemente inofensivas, provoca recálculos innecesarios de la interfaz o sobrescribe APIs clave del navegador y WebView. Todo esto se integra en el flujo normal de eventos del lado del cliente, dificultando que los sistemas de monitoreo detecten anomalías.

Dinámica de crecimiento de las inyecciones del lado del cliente

En los últimos tres meses, hemos observado diferencias significativas en el nivel de inyecciones del lado del cliente entre regiones. En algunos mercados, esto ya se ha convertido en un problema sistémico con alta penetración; en otros, sigue siendo un fenómeno puntual.

Al trabajar en múltiples países, hemos identificado una tendencia clara: cuanto más invierten las empresas y los reguladores en medidas de protección, biometría y períodos de espera para mitigar ingeniería social, mayor es el crecimiento de las inyecciones DOM peligrosas. Esto indica que, a medida que se refuerzan las defensas tradicionales, los atacantes migran hacia el lado del cliente.

A continuación, se presenta un desglose por regiones clave que muestra dónde el riesgo es más alto actualmente y dónde comienza a acelerarse.

Tácticas de estas amenazas de alto riesgo

El código malicioso moderno no depende de una sola acción. Además de manipulaciones centrales como cambiar form.action o interceptar datos, genera actividad adicional: crea y elimina nodos DOM, añade manejadores, envía solicitudes inocuas, provoca recálculos innecesarios de la interfaz o sobrescribe APIs básicas. Este “ruido” se mezcla con eventos legítimos del lado del cliente, dificultando su detección en logs y sistemas de monitoreo.

Un ejemplo de alto riesgo: Web3 y billeteras cripto

Una categoría especialmente peligrosa involucra interfaces de billeteras cripto. Aquí, el código malicioso sustituye la dirección del destinatario, el código QR o los elementos de confirmación. El usuario confía en la interfaz familiar y rara vez verifica cada detalle. Se trata de un ataque dirigido a una interfaz aparentemente confiable: visualmente nada cambia, pero los datos críticos ya han sido alterados. Dado que las transacciones en blockchain son irreversibles, las consecuencias son definitivas.

Este riesgo suele estar asociado a plugins maliciosos del navegador. Las APIs más utilizadas incluyen:

Storage API

localStorage, sessionStorage e IndexedDB: se utilizan para almacenar tokens, identificadores de sesión y parámetros del servicio. El código malicioso puede leer estos valores para secuestrar la sesión o modificarlos en el momento adecuado. Una vez obtenido el token, el atacante puede actuar en nombre del usuario sin necesidad de reautenticación.

Canvas API

En interfaces donde los datos críticos se renderizan mediante canvas, los atacantes pueden alterar información como números de tarjeta, montos o direcciones de billetera.

Navigator.sendBeacon

Una API legítima utilizada para analítica y telemetría, ideal para la exfiltración silenciosa de datos. Permite enviar información al cerrar la pestaña, cuando el usuario ya no espera actividad de red.

Por qué los sistemas antifraude clásicos no detectan estas amenazas

Las soluciones antifraude tradicionales se centran en una pregunta principal: “¿Es este un usuario real?”. Las inyecciones DOM operan en un nivel completamente distinto. El usuario puede ser totalmente legítimo, iniciar sesión desde un dispositivo habitual y seguir un patrón de comportamiento estándar. El riesgo aparece después de que la página se carga, cuando la lógica de la interfaz se altera silenciosamente dentro del navegador. La sesión parece normal para el sistema antifraude — la dirección IP, la huella digital del dispositivo y el comportamiento coinciden con el perfil del usuario. Mientras tanto, el envío del formulario es interceptado, los datos son sustituidos y parte de la información se redirige a otro destino.

Por qué las señales de comportamiento basadas en machine learning no ayudan

Los modelos antifraude basados en comportamiento analizan señales como el tiempo de llenado de formularios, movimientos del mouse, ritmo de escritura, pausas, tasas de error y la velocidad al hacer clic en “Pagar”. Las inyecciones DOM sofisticadas están diseñadas para imitar perfectamente estas señales:

El llenado del formulario no ocurre de manera instantánea. El código malicioso introduce datos con pequeños retrasos aleatorios entre caracteres (normalmente de 80–120 ms), haciendo que la interacción parezca humana.

Los movimientos del mouse se generan con trayectorias naturales: curvas suaves, pausas y pequeñas desviaciones que las herramientas avanzadas de automatización ya pueden reproducir de forma convincente.

Como resultado, el modelo de comportamiento clasifica la actividad con confianza como proveniente de una persona real.

Burós de crédito y biometría también tienen limitaciones

Un buró de crédito puede identificar correctamente al cliente como de bajo riesgo — y tendría razón, porque el ataque no afecta el historial crediticio. El ataque ocurre en tiempo real dentro del navegador durante la sesión. La biometría conductual y fisiológica se enfoca en movimientos del mouse, patrones de escritura, gestos, reconocimiento facial o pruebas de liveness. Pero si el ataque del lado del cliente opera dentro de una sesión normal, mantiene el patrón de comportamiento externo y mezcla cuidadosamente señales sintéticas plausibles, incluso la biometría puede no detectar que la lógica de la página ha sido manipulada. Los atacantes simplemente acompañan al usuario legítimo a través de todos los controles.

Las soluciones antivirus ofrecen una protección limitada

Las herramientas antivirus tradicionales tampoco logran abordar completamente esta amenaza. Se basan en listas negras, verificaciones de integridad, firmas conocidas de malware, archivos sospechosos y URLs maliciosas. Las inyecciones DOM peligrosas suelen evadir estas defensas — especialmente cuando incluyen generación de ruido o escenarios multietapa donde cada acción individual parece inofensiva. La protección debe dejar de centrarse únicamente en acciones, procedimientos o archivos aislados y pasar a evaluar las consecuencias generales a lo largo de toda la sesión, incluyendo comportamientos técnicos invisibles para el usuario final (como el inicio y cierre de sesión). Este enfoque va mucho más allá de aquello para lo que fueron diseñadas las soluciones antivirus clásicas.

Qué debe analizarse

Ya no es suficiente analizar únicamente quién es el usuario, de dónde proviene, cómo mueve el mouse o la integridad básica del navegador y del sistema operativo. También debe monitorearse la integridad del entorno en tiempo real: ¿el DOM ha sido alterado? ¿Se modificó el formulario o form.action? ¿Han aparecido manejadores submit inesperados? ¿Se enviaron datos mediante sendBeacon? ¿Se leyeron tokens desde el almacenamiento en momentos sospechosos? ¿Han aparecido repentinamente campos ocultos, overlays o iframes?

El análisis debe cubrir no solo el comportamiento del usuario, sino también la integridad del entorno donde dicho comportamiento ocurre.

Estrategias de defensa efectivas: del análisis estático al monitoreo de integridad del DOM

La protección del lado del servidor por sí sola ya no es suficiente — no porque sea ineficaz, sino porque no puede ver el panorama completo. Dado que el ataque ocurre dentro del navegador, una defensa efectiva también debe tener visibilidad allí.

1. Subresource Integrity (SRI) informa al navegador sobre un hash criptográfico asociado a archivos JavaScript externos. Si el archivo cambia, no se cargará. El incidente de polyfill dot io en 2024 demostró que las amenazas pueden propagarse a través de cadenas de suministro comprometidas, afectando simultáneamente a miles de sitios sin que ninguno haya sido “hackeado” en el sentido tradicional. SRI funciona bien para recursos externos estáticos, pero no ayuda si el propio script autorizado ejecuta lógica maliciosa o es inyectado dinámicamente por el usuario (por ejemplo, mediante extensiones o plugins del navegador).

2. Content Security Policy (CSP) con reporting restringe desde dónde una página puede cargar scripts. La directiva report-uri permite recopilar señales de violaciones en producción — detectando intentos de inyecciones inline o carga de scripts desde dominios no autorizados antes de que se conviertan en incidentes completos.

3. DOM Monitoring es actualmente el enfoque más avanzado y eficaz. Un script ligero del lado del cliente verifica continuamente la integridad de elementos críticos: estructura de formularios, destinos de envío, aparición de campos ocultos, manejadores de eventos inesperados, iframes, overlays y violaciones de APIs fundamentales. Cuando se detecta una desviación, el sistema envía una señal de riesgo al motor antifraude, activa verificaciones adicionales o finaliza la sesión a nivel del servidor. La diferencia clave frente a los sistemas reactivos — que solo detectan ataques después de que ocurrieron mediante logs, eventos o resultados transaccionales — es que este enfoque identifica la amenaza en tiempo real mientras todavía se está desarrollando.

El futuro de la protección: Zero-Trust del lado del cliente con JuicyScore y JuicyID

En el pasado, una página cargada desde un dominio “correcto” se consideraba confiable por defecto. En el contexto de las inyecciones DOM, esa suposición ya no es válida. El principio de Zero-Trust del lado del cliente implica que incluso dentro de su propia página no puede asumirse ciegamente que el DOM, los manejadores de eventos, los scripts de terceros y los datos mostrados permanecen intactos. Tanto la identidad del usuario como la integridad del entorno del lado del cliente deben verificarse.

Este es precisamente el principio detrás de las soluciones de JuicyScore. JuicyScore analiza datos no personales para evaluar el riesgo de la sesión y proteger a los usuarios en línea contra fraude. La solución combina características de comportamiento, datos del dispositivo y del navegador, así como detección de anomalías — incluyendo randomización, inyección de ruido y otras manipulaciones asociadas con alto riesgo de fraude.

Además, la API v17 de JuicyScore introdujo nuevos atributos en el vector de respuesta diseñados específicamente para detectar inyecciones en distintos niveles de riesgo — directamente relacionados con esta amenaza. Estamos desarrollando activamente esta dirección y planeamos ampliar aún más la clasificación de riesgos asociados con inyecciones DOM en el futuro cercano.

JuicyID es un producto más especializado para la protección de cuentas. Identifica dispositivos riesgosos y patrones de comportamiento sospechosos, reduciendo el riesgo de account takeover sin añadir verificaciones excesivas para usuarios legítimos. Su tecnología de autenticación de dispositivos, basada en la huella digital estable JuicyDeviceID en combinación con otros atributos de JuicyScore, permite analizar el entorno exacto donde ocurre la sesión — la misma capa que sigue siendo un punto ciego para los sistemas tradicionales.

El perímetro que necesita protección ha cambiado. Ya no se encuentra únicamente en el servidor o en la identidad del usuario. Ahora atraviesa el navegador, la estructura de la página y todo lo que ocurre entre la introducción de datos y el clic final.

Una estrategia antifraude que no tenga en cuenta la capa del cliente opera con una visión incompleta del riesgo. Y este punto ciego ya está siendo explotado activamente.

La era de depender exclusivamente del análisis posterior a la transacción está llegando a su fin. La protección efectiva en el entorno actual requiere validación continua y en tiempo real del entorno del lado del cliente, donde realmente nacen las transacciones. Solo así las organizaciones podrán cerrar la creciente brecha que las inyecciones DOM y la toma de control del lado del cliente continúan ampliando.