¿Qué es el session hijacking? Robo de cookies de sesión

Publicado:

17 min de lectura

Acar Diveroli
Autor: Acar Diveroli
Navegador con una tarjeta azul de cookie de sesión al frente; sus copias punteadas flotan hacia un segundo dispositivo tenue

Tu proveedor de correo te envía una alerta de «nuevo inicio de sesión» desde un país que nunca has visitado. Tu contraseña es larga y única, y tienes activada la autenticación en dos pasos, así que nadie adivinó nada. Lo que muy probablemente salió de tu equipo no fue la contraseña, sino la pequeña cookie que tu navegador recibió después de iniciar sesión. Quien tenga una copia de esa cookie es, hasta donde el sitio web puede saber, tú.

Este artículo explica qué es una cookie de sesión, cómo se roba (primero los infostealers, porque la mayoría de los casos empiezan ahí), por qué esquiva la autenticación en dos pasos y qué hacer. Hay secciones aparte sobre lo que deben configurar los propietarios de sitios y sobre por qué los sitios vigilan la dirección IP y el dispositivo que hay detrás de una sesión.

¿Qué es el session hijacking?

El session hijacking, también llamado secuestro de sesión, robo de sesión o cookie hijacking, es la toma de control de una sesión web que inició un usuario real. El atacante no entra por la página de acceso. Reutiliza la prueba de inicio de sesión que el sitio entregó después.

La OWASP Session Management Cheat Sheet explica por qué importa: una vez que existe una sesión, su ID es «temporalmente equivalente al método de autenticación más fuerte que utiliza la aplicación». Si iniciaste sesión con una contraseña y una llave de seguridad, la cookie vale tanto como ambas mientras siga siendo válida.

Los sitios web no te piden la contraseña en cada clic. Cuando inicias sesión, el servidor crea un valor aleatorio largo, el ID de sesión (session ID), y lo envía a tu navegador en una cookie; el navegador lo devuelve con cada petición. Funciona como la tarjeta de la habitación de un hotel: la recepción revisa tu documento una vez y después la tarjeta abre la puerta hasta que caduca.

Las apps hacen lo mismo con tokens de acceso y de actualización (access y refresh tokens). La referencia de Set-Cookie de MDN usa «cookie de sesión» (session cookie) en sentido estricto, para una cookie sin fecha de caducidad que se borra cuando se cierra el navegador. Las cookies de inicio de sesión suelen durar más: la opción «mantener la sesión iniciada» las deja válidas durante semanas, y eso es lo que hace útil una copia robada.

¿Cómo funciona el session hijacking?

  1. Inicias sesión con una contraseña y un código o un aviso en el teléfono. Es el único momento en que se comprueba la autenticación en dos pasos.
  2. El sitio emite una cookie de sesión. A partir de ahí, solo la cookie mantiene tu sesión iniciada.
  3. Una copia sale de tu control. Un malware lee el almacén de cookies del navegador, una página de acceso falsa retransmite tu inicio de sesión y se queda con la cookie, o un fallo del sitio la deja expuesta.
  4. La copia se usa en otro lugar. El servidor ve una sesión válida y no pide nada. MITRE ATT&CK, el catálogo público de técnicas de ataque, dice que esto «elude algunos protocolos de autenticación multifactor, ya que la sesión ya está autenticada» (T1550.004). Los equipos de seguridad lo llaman «pass the cookie».
  5. El atacante se atrinchera: un nuevo correo de recuperación, una regla de reenvío, compras, antes de que la sesión caduque.

La defensa actúa en el paso 3 (impedir que la copia salga), en el paso 4 (hacer que no sirva en otro lugar) y en el paso 5 (detectarlo rápido).

¿Cómo roban los atacantes las cookies de sesión?

MétodoEn qué se basaDefensa principal
Malware infostealerUna descarga infectada o un comando pegado en tu equipoDispositivo limpio, sesiones vinculadas al dispositivo
Phishing adversary-in-the-middleInicias sesión en una página imitada que retransmite al sitio realPasskeys o una llave de seguridad
Cross-site scripting (XSS)Un fallo permite que un script inyectado se ejecute en las páginas del sitioCookies HttpOnly
Session sniffing (escucha de la sesión)La cookie viaja por HTTP sin cifrarHTTPS en todo el sitio, atributo Secure
Fijación de sesión (session fixation)El sitio mantiene el mismo ID tras el inicio de sesiónUn ID nuevo en cada inicio de sesión
IDs predecibles o filtradosIDs que se pueden adivinar, o IDs en URLs y registrosIDs aleatorios largos, solo en cookies

Phishing que retransmite el inicio de sesión. Algunas páginas de phishing se colocan entre tú y el sitio real, pasan tu contraseña y tu código, y se quedan con la cookie de sesión que devuelve el sitio real; MITRE recoge esta vía del «proxy malicioso» en el robo de cookies de sesión web. Las passkeys la anulan: la FIDO Alliance las describe como credenciales resistentes al phishing vinculadas a tu cuenta en un único sitio web.

Cross-site scripting. Un script colado en las páginas de un sitio a través de un fallo se ejecuta como si lo hubiera escrito el propio sitio y puede leer cualquier cookie que no tenga el atributo HttpOnly.

Session sniffing. En una red que no controlas, el tráfico sin cifrar se puede leer; HTTPS cierra esa puerta para la cookie, y ¿Es seguro el Wi-Fi público? explica lo que sigue a la vista. Para leer tráfico HTTPS, tu dispositivo tiene que confiar en un certificado raíz adicional. Los desarrolladores añaden uno a propósito para depurar con un proxy MITM en su propio equipo; nunca instales uno porque te lo pida una red o un sitio web.

¿Qué es un infostealer y cómo esquiva la 2FA?

Un infostealer es un malware que copia los datos guardados en un equipo y los envía fuera en cuestión de minutos: contraseñas del navegador, cookies, datos de autocompletado, monederos de criptomonedas y tokens de aplicaciones. El botín, un stealer log, se vende al por mayor.

Un aviso conjunto del FBI y la CISA sobre el infostealer LummaC2, del 21 de mayo de 2025, enumera lo que se lleva este tipo de malware, desde «credenciales financieras» hasta «datos de autenticación multifactor (MFA)», y cómo llega: correos de phishing, software falso o crackeado y páginas de CAPTCHA falsas. Esas páginas piden al visitante que pulse Windows + R, pegue con Ctrl + V y pulse Enter, lo que ejecuta el comando del atacante. Ninguna comprobación real de «¿eres humano?» pide algo así.

La autenticación en dos pasos no sirve de nada una vez que la cookie se ha ido, porque la cookie es el resultado de un inicio de sesión que ya pasó la 2FA. A finales de agosto de 2026, Anthropic cerró la sesión de usuarios de Claude cuyas sesiones habían copiado infostealers en sus propios equipos, y advirtió que cerrar la sesión «no elimina el malware» (Help Net Security). Mientras el dispositivo siga infectado, la siguiente sesión también se copia.

Have I Been Pwned también carga stealer logs: verifica tu dirección de correo en su servicio gratuito de notificaciones para ver los sitios web junto a los que apareció tu dirección, y considera expuesto cada uno de ellos.

Session hijacking frente a credential stuffing, phishing y CSRF

AtaqueQué obtiene el atacante¿Lo frena la 2FA?
Session hijackingUna sesión iniciada (cookie o token)No, la sesión ya pasó la 2FA
Credential stuffingUna contraseña filtrada, probada en otros sitiosSí, en la mayoría de los casos
Phishing de contraseñasTu contraseña, a veces un código de un solo usoLos códigos se pueden retransmitir; las passkeys lo frenan
Cross-site request forgery (CSRF)Una acción enviada a través de tu propio navegadorNo; lo frenan las cookies SameSite y los tokens CSRF

En el CSRF la cookie nunca sale de tu navegador; el session hijacking la lleva a otra máquina.

Señales de que te robaron la sesión

  • Una alerta de «nuevo inicio de sesión» que no provocaste, o un dispositivo desconocido en la lista de sesiones activas de la cuenta.
  • Cambios que no hiciste: correo o teléfono de recuperación, reglas de reenvío, apps conectadas, métodos de pago.
  • Mensajes o pedidos que no enviaste, o un saldo o una cuota de uso que baja mientras no estás.
  • Un cierre de sesión sin aviso, a veces porque el sitio detectó una segunda copia de tu sesión.

Una solicitud de la autenticación en dos pasos que no pediste significa otra cosa: alguien tiene tu contraseña. Recházala y cambia esa contraseña.

Qué hacer si te robaron la sesión

  1. Limpia primero el dispositivo. Haz un análisis completo con tu software de seguridad; si encuentra un infostealer, o si tienes dudas, haz una copia de seguridad de tus archivos y reinstala el sistema operativo. Si no, el malware simplemente copiará tu siguiente sesión.
  2. Cierra todas las sesiones desde un dispositivo limpio. En una cuenta de Google: Cuenta de Google > Seguridad e inicio de sesión > Tus dispositivos > Gestionar todos los dispositivos; después selecciona cada dispositivo desconocido y elige Cerrar sesión (pasos de Google). La mayoría de los grandes servicios tienen una lista parecida.
  3. Cambia la contraseña. Google cerrará entonces tu sesión en todas partes excepto en algunos dispositivos que enumera en su página de ayuda sobre contraseñas; otros servicios pueden mantener vivas las sesiones antiguas, así que haz también el paso 2.
  4. Revisa lo que dejaron: datos de recuperación, reenvío de correo, apps conectadas, métodos de pago. Después añade una passkey donde se ofrezca.

Cómo evitar el session hijacking como usuario

  • Instala software solo desde fuentes oficiales y nunca pegues un comando que una página web te pida ejecutar.
  • Usa passkeys o una llave de seguridad. Una página de phishing puede retransmitir un código, no una passkey.
  • No marques «mantener la sesión iniciada» en equipos compartidos y cierra la sesión cuando te vayas.
  • Revisa de vez en cuando las sesiones activas de tu cuenta de correo.
  • Quita las extensiones del navegador que ya no uses; una con permisos amplios puede leer cookies.
  • Mantén el navegador actualizado, porque protecciones como las sesiones vinculadas al dispositivo llegan con las actualizaciones.

Cómo evitar el session hijacking en tu sitio

La cheat sheet de OWASP es la referencia. Los puntos que más importan:

  1. Configura los atributos de la cookie. Secure (solo HTTPS), HttpOnly (sin acceso desde scripts), SameSite=Lax o Strict, y el prefijo __Host-, que exige Secure, Path=/ y ningún Domain.
  2. Haz que los IDs no se puedan adivinar: al menos 64 bits de entropía, generados por tu framework, nunca en URLs.
  3. Emite un ID de sesión nuevo al iniciar sesión y en cada cambio de privilegios; así se cierra la puerta a la fijación de sesión.
  4. Haz que las sesiones caduquen. Los ejemplos de OWASP: un tiempo de inactividad de 2-5 minutos para aplicaciones de alto valor, de 15-30 minutos para las de bajo riesgo y un tiempo máximo absoluto de 4-8 horas.
  5. Haz que cerrar sesión sea real. Invalida la sesión en el servidor y deja que los usuarios vean y cierren sus sesiones.
  6. Vuelve a pedir la verificación antes de cambios sensibles, como una contraseña nueva, una dirección de correo nueva o una cuenta de cobro.
  7. Sirve todas las páginas por HTTPS con HSTS, para que los navegadores nunca vuelvan a HTTP sin cifrar.
text
Set-Cookie: __Host-sid=<random value>; Path=/; Secure; HttpOnly; SameSite=Lax

Device Bound Session Credentials (DBSC)

DBSC vincula una sesión al dispositivo que la creó. El navegador guarda una clave privada en hardware seguro, como el chip TPM en Windows, y debe demostrar que tiene esa clave cada vez que renueva las cookies de corta duración del sitio, así que una cookie copiada caduca pronto y no se puede renovar en otro lugar. Google anunció el 9 de abril de 2026 que DBSC entra en disponibilidad pública en Chrome 146 para Windows, que macOS llegará después y que se desarrolla como estándar abierto del W3C. La documentación de Chrome describe la configuración del lado del sitio y advierte que un malware que ya esté presente en el momento del registro podría extraer la clave.

Por qué los sitios vinculan tu sesión a tu dirección IP y a tu dispositivo

Pocos sitios fijan una sesión a una sola dirección IP, porque los usuarios reales pasan todo el día del Wi-Fi a los datos móviles y viceversa. En su lugar, vigilan las sesiones que cambian de carácter de repente: una cookie emitida a un equipo portátil con una conexión doméstica aparece minutos después desde una red de hosting de otro país, con otra huella digital del navegador. Eso parece un robo, así que el sitio cierra la sesión o te pide que vuelvas a iniciarla. OWASP señala que un atacante hábil puede saltarse la vinculación a la IP y al User-Agent, así que estas comprobaciones son una capa, no la solución.

La misma lógica atrapa a usuarios honestos. Si tu VPN o tu proxy cambian de país a mitad de sesión, o un proxy rotativo da a cada petición una dirección nueva, el sitio ve una sesión que salta por el mapa y te echa; ¿Por qué tu banco marca un inicio de sesión en otro lugar? lo muestra desde el lado del usuario.

Los equipos que trabajan en cuentas con la sesión iniciada a través de un proxy, como las agencias que gestionan cuentas publicitarias de clientes, mantienen una salida por cuenta. Con los Proxies de sesión fija, una sesión conserva la misma IP de 1 a 60 minutos, y con los Proxies ISP mantienes una dirección registrada a nombre de un proveedor de internet durante todo el tiempo que la alquiles; Plataformas de pago y consistencia de IP trata el caso de las finanzas. Un proxy no protege una cookie contra el robo, y los Términos del servicio de Proxynet prohíben los intentos de acceso no autorizado.

Dónde hace más daño el session hijacking

  • Bancos y apps de pago, donde una sesión robada puede mover dinero; consulta la página de finanzas.
  • Tiendas online y cuentas de vendedor, con tarjetas guardadas y datos de cobro; consulta la página de e-commerce.
  • Redes sociales y cuentas publicitarias, donde una página tomada puede publicar estafas o gastar el presupuesto; la página de redes sociales explica cómo mantener una IP por cuenta.
  • Paneles de administración y herramientas de empresa, donde una sola sesión robada puede exponer datos de clientes; la página de seguridad de datos explica cómo probar tus propias páginas de acceso desde fuera.

Errores frecuentes

  • Confiar en que la 2FA protege una sesión que ya está abierta.
  • Cerrar sesión en un equipo que sigue infectado.
  • Cambiar la contraseña y dar por hecho que las sesiones antiguas terminaron.
  • Sitio: un cierre de sesión que solo borra la cookie en el navegador.
  • Sitio: fijar las sesiones de forma rígida a una dirección IP, lo que echa a los usuarios móviles y apenas frena a un atacante.

Guía de decisión

Tu situaciónQué hacer primero
Una alerta de «nuevo inicio de sesión» que no provocasteDesde un dispositivo limpio, cierra todas las sesiones y cambia la contraseña
Tu software de seguridad encontró un infostealerLimpia o reinstala el equipo; después cierra las sesiones y cambia las contraseñas
Tu correo aparece en stealer logsConsidera expuestos los sitios de la lista; añade passkeys
Una solicitud de 2FA que no pedisteRecházala y cambia esa contraseña
Tienes un sitio con inicio de sesiónAtributos de cookie, ID nuevo al iniciar sesión, cierre de sesión en el servidor, lista de sesiones
Tu equipo de trabajo opera cuentas de clientes a través de un proxyUna salida de sesión fija o estática por cuenta

Preguntas frecuentes

¿Puede el session hijacking saltarse la autenticación en dos pasos?

Sí. La autenticación en dos pasos se comprueba al iniciar sesión, y una cookie robada representa un inicio de sesión que ya la superó. Las passkeys frenan la vía del phishing, pero no el malware de tu propio dispositivo.

¿Cerrar sesión me protege del session hijacking?

En un sitio bien hecho, cerrar sesión termina la sesión en el servidor, así que una cookie copiada deja de funcionar. Pero en un dispositivo infectado la siguiente sesión se vuelve a copiar, así que limpia primero el dispositivo.

¿HTTPS evita el session hijacking?

Evita la escucha en la red, pero no el malware de tu dispositivo, un fallo XSS ni una página de phishing con su propio certificado válido.

¿Una VPN o un proxy pueden detener el session hijacking?

No. Ambos cambian el camino por la red, pero un infostealer lee la cookie de tu disco y una página de phishing la obtiene directamente de ti. Una VPN o un proxy gratuito gestionado por un desconocido puede incluso añadir riesgo; consulta ¿Son seguros los proxies gratis y los sitios web proxy?

¿Qué diferencia hay entre session hijacking y session fixation?

En el hijacking, el atacante se apropia de un ID de sesión que ya existe. En la fijación (session fixation), el atacante coloca un ID conocido antes de que inicies sesión y espera a que lo autentiques; un ID nuevo al iniciar sesión lo impide.

¿El session hijacking es ilegal?

Sí. Usar la sesión de otra persona sin permiso es un acceso no autorizado según las leyes sobre delitos informáticos de la mayoría de los países. Las pruebas solo son legales en tus propios sistemas o con permiso por escrito del propietario.

En resumen

El session hijacking se salta el inicio de sesión: quien tiene una copia de tu cookie o token de sesión ha iniciado sesión como tú, con la contraseña y el código de dos pasos ya superados. La mayoría de los casos empiezan con un malware infostealer en el propio equipo de la víctima; después vienen las páginas de phishing que retransmiten el inicio de sesión, los fallos XSS y las conexiones sin cifrar. Los usuarios se defienden con dispositivos limpios, passkeys y un vistazo a sus sesiones activas; los sitios, con atributos de cookie estrictos, IDs nuevos al iniciar sesión, duraciones cortas, un cierre de sesión real y sesiones vinculadas al dispositivo. Si tu equipo de trabajo opera cuentas con la sesión iniciada a través de un proxy, mantén cada cuenta en una dirección estable con nuestros servicios de proxy.