El registro de actividad de scripts en la capa del navegador es la grabación en tiempo real de lo que JavaScript ejecuta dentro del navegador del usuario: cada lectura del DOM, acceso a campos de formulario, solicitud de red, escritura de cookies e inyección dinámica de scripts realizada por código propio y de terceros durante una sesión activa. Es la capa de registro que las herramientas SIEM, EDR y WAF no pueden alcanzar, y donde el skimming Magecart, los compromisos de cadena de suministro y los scripts de secuestro de sesión se ejecutan.
La mayoría de los equipos de seguridad tienen un sólido registro en las capas de servidor, red y endpoint. El entorno de ejecución del navegador, donde los scripts de terceros se ejecutan con los mismos privilegios que el código propio, casi siempre no está monitorizado. Esta guía cubre qué captura un registro de actividad de scripts del navegador, por qué importa la brecha y cómo es la respuesta efectiva a incidentes cuando un script en tu sitio se ve comprometido.
La brecha de registro que la mayoría de las pilas dejan abierta
Una pila de seguridad empresarial típica registra las siguientes capas:
| Capa | Qué registra | Herramientas típicas |
|---|---|---|
| Red | Tráfico HTTP/S, DNS, eventos de firewall | WAF, NGFW, NDR |
| Endpoint | Llamadas al SO, ejecución de procesos, escrituras de archivos | EDR, XDR |
| Servidor | Registros de aplicación, eventos de autenticación, llamadas API | SIEM (vía agentes/conectores) |
| Entorno de ejecución del navegador | Ejecución de JavaScript, lecturas del DOM, comportamiento de scripts | Ausente en la mayoría de las pilas |
El entorno de ejecución del navegador es donde operan los ataques del lado del cliente. Un script Magecart lee el valor de un campo de tarjeta de pago y lo envía a un servidor remoto. Esa lectura ocurre completamente dentro del navegador. La capa de red ve un POST HTTPS después de que los datos ya han salido. El EDR no detecta ningún proceso anómalo. El SIEM no tiene ninguna entrada. El ataque se completa con registros limpios en todas partes, razón por la cual los equipos que quieren detectar Magecart en tiempo real instrumentan el propio navegador.
Ante un único GET /pricing desde una sola IP, las dos capas llegan a veredictos opuestos:
| Lo que ve la capa de red/servidor | Lo que ve la capa de sesión de navegador |
|---|---|
| IP: proxy residencial | Puntero: 0 px movidos |
| TLS: huella de Chrome 124 | Permanencia: 0,2 s por página |
| Cookie: sesión válida | Navegación: estrictamente secuencial |
| User-Agent: Chrome 124 | Desplazamiento: ninguno |
| Veredicto: sin anomalía, carga limpia | Veredicto: clasificada como automatizada, sesión con límite de velocidad |
Las cabeceras parecen humanas, así que el WAF, la CDN y la inspección de IP dejan pasar la solicitud. La misma sesión, leída en la capa de navegador, nunca mueve el puntero, permanece 0,2 segundos por página y recorre las páginas en orden estricto sin desplazarse: el punto ciego de la red es exactamente donde cside la detecta.
El compromiso de la cadena de suministro de Polyfill[.]io en junio de 2024 demostró esto a escala. Un script alojado en CDN de uso generalizado fue modificado para servir payloads maliciosos a más de 490.000 sitios web. El WAF, SIEM y EDR de cada sitio afectado tenían registros limpios. Las únicas herramientas que podían detectar la anomalía eran las que operaban en la capa de ejecución del navegador.
Qué captura un registro completo de actividad de scripts del navegador
Un registro de actividad en la capa del navegador útil registra seis categorías de comportamiento de scripts:
1. Acceso al DOM y mutaciones
Qué elementos lee o escribe un script, con atención especial a los campos de entrada, elementos de formulario y campos de contraseña. Un script en la página de pago que nunca antes había leído el campo del número de tarjeta pero lo hace en un nuevo despliegue es una anomalía de comportamiento que merece ser marcada de inmediato.
2. Solicitudes de red
Cada fetch(), XMLHttpRequest, navigator.sendBeacon(), píxel de imagen y conexión WebSocket iniciada por un script, incluyendo el dominio de destino, el método de solicitud y si el destino es nuevo o ya conocido. Los nuevos destinos salientes son el principal indicador de exfiltración de datos.
3. Acceso a cookies y almacenamiento
Qué scripts leen o escriben cookies, localStorage y sessionStorage. Los scripts de análisis legítimos rara vez necesitan tokens de sesión. Si uno comienza a leerlos, el comportamiento debe ser marcado.
4. Inyección dinámica de scripts
Scripts que crean nuevos elementos <script> o usan eval(), Function() o document.write() para ejecutar nuevo código en tiempo de ejecución. Así es como el malware de segunda etapa se carga en ataques a la cadena de suministro: el primer script es limpio y busca y ejecuta el payload real de forma dinámica.
5. Solicitudes de sub-recursos y dependencias de cuarta parte
Scripts que cargan recursos externos adicionales, creando una cadena desde tu tercero aprobado hasta un dominio de cuarta parte no aprobado. El ataque de Polyfill[.]io usó este patrón: el script CDN comprometido cargó código controlado por el atacante desde un dominio separado.
6. Desviaciones de la línea base de comportamiento
La señal más accionable no es un único evento sino una desviación del comportamiento establecido. Un script que ha ejecutado en tu página de pago durante seis meses y nunca ha accedido a campos de formulario, que de repente comienza a leer valores de entrada de tarjeta en una sesión de cada mil: ese es el evento de detección.
Respuesta a incidentes para ataques de scripts del navegador
La respuesta efectiva a incidentes para el compromiso de un script en la capa del navegador sigue un flujo de trabajo distinto al de los incidentes del lado del servidor. El cronograma es comprimido porque los datos pueden ser exfiltrados en milisegundos y la superficie de ataque es cada sesión de usuario que ejecuta el script comprometido.
Detectar
La detección se basa en alertas de anomalías de comportamiento, no en coincidencia de firmas. La detección basada en firmas falla contra payloads polimórficos y ofuscados descritos en detalle aquí. El desencadenante para un incidente en la capa del navegador debe ser: un script conocido accediendo a tipos de datos que nunca había accedido anteriormente, o un script haciendo solicitudes de red a un destino fuera de su perfil de comportamiento establecido.
Una alerta en tiempo real, no un lote SIEM del día siguiente, es el estándar mínimo. Para cuando una revisión de registros diaria detecta un script Magecart, decenas de miles de sesiones pueden haber sido expuestas.
Contener
La contención en la capa del navegador ocurre de manera diferente a la contención en el endpoint. Las opciones incluyen:
- Bloquear la solicitud de red específica: evitar que la llamada de exfiltración se complete interceptando la solicitud saliente que hace el script malicioso.
- Bloquear el propio script: evitar que el script comprometido se cargue en cargas de página posteriores, reduciendo inmediatamente la superficie de ataque.
- Alertar sin bloquear: usar para detecciones de menor confianza donde el riesgo de falsos positivos es alto. Registra el evento y alerta al equipo sin impacto visible para el usuario.
La capacidad de bloquear sin un despliegue de código, directamente desde una plataforma de monitoreo sin tocar el código fuente del sitio, es crítica para la velocidad de contención. Los despliegues de código toman horas; el bloqueo en la capa del navegador puede ser casi instantáneo.
Investigar
El paso de investigación requiere un registro de lo que ocurrió en las sesiones afectadas. Sin un registro de actividad del navegador, este paso es casi imposible. Con uno, la investigación puede responder:
- ¿Qué sesiones ejecutaron la versión comprometida del script?
- Durante esas sesiones, ¿a qué campos de datos accedió el script?
- ¿A dónde se enviaron las solicitudes de red?
- ¿Se completó la exfiltración (respondió el destino) o fue interrumpida?
Este registro es también el expediente probatorio para las decisiones de notificación de brechas bajo el Artículo 33 del RGPD (umbral de notificación de 72 horas) y los requisitos de PCI DSS. Sin él, la suposición predeterminada bajo la mayoría de los marcos es que todas las sesiones expuestas fueron comprometidas.
Remediar
La remediación para el compromiso de un script del navegador incluye: eliminar o revertir la versión comprometida del script, confirmar que el endpoint de exfiltración del atacante está bloqueado a nivel de red, evaluar qué sesiones de usuario requieren notificación y actualizar la línea base de comportamiento del script para que la próxima desviación se detecte más rápido.
La revisión post-incidente debe evaluar si la ventana de detección a contención cumplió un umbral aceptable. Para los scripts de páginas de pago bajo los requisitos de PCI DSS 6.4.3 y 11.6.1, la expectativa es la detección de modificaciones no autorizadas de scripts en tiempo real, no horas o días después.
Cómo evaluar plataformas para el registro de actividad de scripts del navegador
No todas las herramientas de monitoreo que afirman tener visibilidad en la capa del navegador realmente instrumentan el entorno de ejecución del navegador. Preguntas a hacer durante la evaluación de un producto:
| Área de evaluación | Qué buscar | Señal de alerta |
|---|---|---|
| Método de registro | Agente o SDK que se ejecuta en el navegador y observa la ejecución | Rastreador que simula sesiones externamente |
| Cobertura | Todas las sesiones, no un subconjunto muestreado | El muestreo significa que la mayoría de los ataques no se registran |
| Aprendizaje de línea base | Perfilado de comportamiento automático por script por página | Requiere configuración manual de umbrales |
| Capacidad de bloqueo | Puede bloquear solicitudes de red de scripts sin un despliegue de código | Solo detección sin ruta de aplicación |
| Retención de registros | Registros indexados a nivel de sesión disponibles para investigación | Solo métricas agregadas, sin repetición de sesión |
| Evidencia de cumplimiento | Registros exportables mapeados a PCI DSS 6.4.3/11.6.1 y RGPD Artículo 32 | Sin salida de cumplimiento estructurada |
La distinción clave es el método de instrumentación. Un escáner externo visita tu página desde un navegador sin cabeza y registra lo que observa durante esa sesión artificial. Un atacante que solo se activa contra usuarios reales, una técnica de evasión común, es invisible para un escáner. La instrumentación en tiempo de ejecución que se ejecuta en cada sesión de usuario real captura lo que los escáneres no ven.
Dónde encaja cside
cside es el registro de actividad de scripts nativo del navegador y la aplicación construida específicamente para el riesgo de JavaScript de terceros. Instrumenta la capa de ejecución del navegador en cada sesión de usuario real y registra las seis categorías descritas anteriormente: acceso al DOM, solicitudes de red, lecturas de cookies y almacenamiento, inyección dinámica de scripts, cadenas de sub-recursos y desviaciones de comportamiento de las líneas base establecidas.
Cuando se detecta una anomalía, cside puede bloquear las solicitudes de red del script o el propio script sin requerir un despliegue de código. El registro de actividad que produce está estructurado tanto para la investigación de incidentes como para la evidencia de cumplimiento bajo PCI DSS 6.4.3, 11.6.1 y RGPD Artículo 32.
Para los equipos que actualmente dependen de la cobertura de SIEM, EDR y WAF y asumen que esas tres capas cubren toda la superficie de ataque: no cubren el entorno de ejecución del navegador. Esa es la capa donde operan Magecart, el formjacking y el skimming digital, los compromisos de cadena de suministro y los scripts de secuestro de sesión, y es la capa donde el registro de actividad de scripts y la respuesta a incidentes tiene la mayor brecha en la mayoría de las pilas empresariales.
