Un banco aprobó un píxel Taboola. Ese píxel redirigió silenciosamente a los usuarios que iniciaron sesión a un punto final de seguimiento de Temu. Esto ocurrió sin el conocimiento del banco, sin el consentimiento del usuario y sin que un solo control de seguridad registrara una infracción.

Lea el desglose técnico completo en el Resumen de inteligencia de seguridad. Descargar ahora →

El punto ciego del «sesgo del primer salto»

La mayoría de las pilas de seguridad, incluidos WAF, analizadores estáticos y CSP estándar, comparten un modo de falla común: evalúan la origen declarado de un guión, no del destino de tiempo de ejecución de su cadena de solicitudes.

Si sync.taboola.com está en la lista permitida de su Política de seguridad de contenido (CSP), el navegador considera que la solicitud es legítima. Sin embargo, no revalida contra el destino terminal de un redirección 302. Cuando el navegador llega a temu.com, ha heredado la confianza otorgada a Taboola.

El rastro forense

Durante una auditoría realizada en febrero de 2026 de una plataforma financiera europea, Reflectiz identificó la siguiente cadena de redireccionamiento que se ejecuta en páginas de cuentas en las que se ha iniciado sesión:

1. Solicitud inicial: Una solicitud GET a https://sync.taboola.com/sg/temurtbnative-network/1/rtb/.
2. La redirección: El servidor respondió con un 302 encontradoredirigiendo el navegador a https://www.temu.com/api/adx/cm/pixel-taboola?….
3. La carga útil: La redirección incluía el encabezado crítico Access-Control-Allow-Credentials: true.

Este encabezado indica específicamente al navegador que incluya cookies en la solicitud de origen cruzado al dominio de Temu. Este es el mecanismo mediante el cual Temu puede leer o escribir identificadores de seguimiento en un navegador que ahora sabe que visitó una sesión bancaria autenticada.

Por qué las herramientas convencionales no lo lograron

«`html

«`

Las consecuencias regulatorias

Para las entidades reguladas, la ausencia de robo directo de credenciales no limita la exposición al cumplimiento. Nunca se informó a los usuarios que el comportamiento de su sesión bancaria estaría asociado con un perfil de seguimiento de PDD Holdings, una falla de transparencia según el art. 13. El enrutamiento en sí involucra infraestructura en un país no adecuado, y sin Cláusulas Contractuales Estándar que cubran esta relación específica de cuarto partido, la transferencia no está respaldada por el Capítulo V del RGPD. «No sabíamos que el píxel hacía eso» no es una defensa disponible para un controlador de datos según el art. 24.

La exposición al PCI DSS agrava esto. Una cadena de redireccionamiento que termina en un dominio de terceros no previsto queda fuera del alcance de cualquier revisión que evalúe sólo al proveedor principal, que es precisamente lo que Requerido 6.4.3 fue escrito para cerrar.

Inspeccionar el tiempo de ejecución, no sólo las declaraciones

En este momento, la misma configuración de píxeles de Taboola se ejecuta en miles de sitios web. La pregunta no es si se están produciendo cadenas de redireccionamiento como ésta. Ellos son. La pregunta es si su pila de seguridad puede ver más allá del primer salto, o si se detiene en el dominio que usted aprobó y da por terminado.

Para equipos de seguridad: inspeccionar el comportamiento del tiempo de ejecución, no solo las listas de proveedores declaradas.

Para equipos legales y de privacidad: Las cadenas de seguimiento a nivel del navegador en páginas autenticadas garantizan el mismo rigor que las integraciones de backend.

La amenaza entró por la puerta grande. Su CSP lo dejó entrar.

El registro completo de evidencia técnica se encuentra en el Security Intelligence Brief. Descárgalo aquí →

Google ha hecho Credenciales de sesión vinculadas al dispositivo (DBSC) generalmente disponible para todos los usuarios de Windows de su navegador web Chrome, meses después de que comenzara a probar la función de seguridad en versión beta abierta.

La disponibilidad pública está actualmente limitada a usuarios de Windows en Chrome 146, y la expansión de macOS está planificada en una próxima versión de Chrome.

«Este proyecto representa un importante paso adelante en nuestros esfuerzos continuos para combatir el robo de sesiones, que sigue siendo una amenaza frecuente en el panorama de seguridad moderno», dijeron los equipos de seguridad de cuentas y Chrome de Google. dicho en una publicación del jueves.

El robo de sesión implica la filtración encubierta de cookies de sesión del navegador web, ya sea reuniendo las existentes o esperando a que la víctima inicie sesión en una cuenta en un servidor controlado por un atacante.

Normalmente, esto sucede cuando los usuarios descargan inadvertidamente malware para robar información en sus sistemas. Estas familias de malware ladrón (de las cuales hay muchas, como Atomic, Lumma y Vidar Stealer) tienen capacidades para recopilar una amplia gama de información de los sistemas comprometidos, incluidas las cookies.

Debido a que las cookies de sesión suelen tener una vida útil más prolongada, los atacantes pueden aprovecharlas para obtener acceso no autorizado a las cuentas en línea de las víctimas sin tener que conocer sus contraseñas. Una vez recolectados, estos tokens se empaquetan y venden a otros actores de amenazas para obtener ganancias financieras. Los ciberdelincuentes que los adquieran pueden realizar sus propios ataques.

DBSC, anunciado por primera vez por Google en abril de 2024, tiene como objetivo contrarrestar este abuso vinculando criptográficamente la sesión de autenticación a un dispositivo específico. Al hacerlo, la idea es hacer que las cookies pierdan su valor incluso si son robadas por malware.

«Lo hace utilizando módulos de seguridad respaldados por hardware, como el Módulo de plataforma segura (TPM) en Windows y Secure Enclave en macOS, para generar un par de claves pública/privada único que no se puede exportar desde la máquina», explicó Google.

«La emisión de nuevas cookies de sesión de corta duración depende de que Chrome demuestre la posesión de la clave privada correspondiente al servidor. Debido a que los atacantes no pueden robar esta clave, cualquier cookie exfiltrada caducará rápidamente y se volverá inútil para esos atacantes».

En caso de que el dispositivo de un usuario no admita el almacenamiento seguro de claves, DBSC vuelve elegantemente al comportamiento estándar sin interrumpir el flujo de autenticación, Google dicho en su documentación para desarrolladores.

El gigante tecnológico dijo que ha observado una reducción significativa en el robo de sesiones desde su lanzamiento, una indicación temprana del éxito de la contramedida. El lanzamiento oficial es solo el comienzo, ya que la compañía planea llevar DBSC a una gama más amplia de dispositivos e introducir capacidades avanzadas para integrarse mejor con entornos empresariales.

Google, que trabajó con Microsoft para diseñar el estándar con el objetivo de convertirlo en un estándar web abierto, también enfatizó que la arquitectura DBSC es privada por diseño y que el enfoque de clave distinta garantiza que los sitios web no puedan usar las credenciales de sesión para correlacionar la actividad de un usuario en diferentes sesiones o sitios en el mismo dispositivo.

«Además, el protocolo está diseñado para ser sencillo: no filtra identificadores de dispositivos ni datos de certificación al servidor más allá de la clave pública por sesión requerida para certificar la prueba de posesión», añadió. «Este intercambio mínimo de información garantiza que DBSC ayude a proteger las sesiones sin permitir el seguimiento entre sitios ni actuar como un mecanismo de toma de huellas digitales del dispositivo».