¿Qué es el secuestro de sesión?

Publicado: 26 de julio de 2024. Actualizado: agosto de 2026. Revisado por el equipo de Seguridad de Aplicaciones e Infraestructura de Clave Pública (PKI) de Encryption Consulting.

¿Qué es el secuestro de sesión?

El secuestro de sesión es un ataque en el que un atacante toma el control de una sesión web válida y autenticada robando o adivinando el identificador único de sesión que un servidor utiliza para reconocer a un usuario conectado. Posteriormente, reutiliza dicho identificador para suplantar la identidad de la víctima sin necesidad de introducir una contraseña. Dado que el servidor ya confía en la sesión, el ataque elude por completo los formularios de inicio de sesión, las contraseñas y, en muchos casos, la autenticación multifactor.

En este tema aparecen con frecuencia algunos términos, por lo que conviene definirlos claramente antes de continuar:

• ID de sesión (token de sesión): una cadena aleatoria que un servidor emite a un cliente después de iniciar sesión para poder reconocer al mismo usuario en cada solicitud posterior, ya que el protocolo HTTP en sí no recuerda nada entre solicitudes.
• Cookie: La pequeña porción de datos que un navegador almacena y reenvía automáticamente a un sitio web, que se utiliza con mayor frecuencia para transmitir el ID de sesión entre el navegador y el servidor.
• TLS (Seguridad de la capa de transporte): El protocolo de cifrado que respalda HTTPS protege los datos, incluidas las cookies de sesión, mientras viajan a través de la red.
• MITM (ataque de intermediario): una posición de ataque en la que el adversario se sitúa entre el usuario y el servidor y puede leer o alterar el tráfico que pasa entre ellos, una de las formas en que se puede capturar un ID de sesión.
• XSS (secuencias de comandos entre sitios): Una vulnerabilidad en las aplicaciones web que permite a un atacante ejecutar su propio script en el navegador de la víctima, comúnmente utilizada para leer y extraer cookies de sesión.

El secuestro de sesión a veces se denomina secuestro de cookies o robo de cookies, ya que la cookie de sesión es lo que más se suele robar. Está estrechamente relacionado con un ataque MITM genérico, pero es distinto: un ataque MITM describe la posición del atacante en la red, mientras que el secuestro de sesión describe lo que el atacante hace con esa posición, es decir, robar y reutilizar una sesión activa. OWASP clasifica la gestión deficiente de sesiones dentro de Fallos de Identificación y Autenticación , una de sus principales categorías de riesgo para aplicaciones web.

¿Cómo funciona el secuestro de sesión?

El secuestro de sesión funciona capturando un identificador de sesión válido y reutilizándolo antes de que el servidor tenga motivos para dudar de que pertenece a otra persona. El ataque generalmente sigue los mismos cinco pasos, independientemente de la técnica de captura utilizada:

1. Reconocimiento. El atacante identifica una aplicación objetivo y busca puntos débiles en la forma en que emite, almacena o transmite identificadores de sesión, como la falta de indicadores de cookies o patrones de identificación predecibles.
2. Captura de ID de sesión. El atacante obtiene un ID de sesión en tiempo real mediante uno de varios métodos: inyectando un script a través de XSS para leer la cookie, interceptando el tráfico no cifrado o degradado en una red compartida, engañando a un usuario para que utilice un ID proporcionado por el atacante (fijación de sesión) o adivinando directamente un ID débil.
3. Repetición de ficha. El atacante inserta el ID de sesión robado en su propio navegador o cliente, normalmente configurando la cookie correspondiente.
4. Suplantación de identidad de sesión. El servidor detecta un identificador de sesión familiar y aún válido, y trata la solicitud como proveniente del usuario legítimo y ya autenticado, sin que se active ningún proceso de reautenticación.
5. Explotación. El atacante actúa con los privilegios de la víctima mientras la sesión permanezca válida, leyendo datos, cambiando configuraciones o iniciando transacciones, a menudo antes de que la víctima o cualquier sistema de monitoreo detecte algo inusual.

La tabla que aparece a continuación muestra las técnicas de captura más comunes, cómo funciona cada una y la defensa más eficaz para contrarrestarlas.

Técnica de ataque	Cómo Funciona	Defensa primaria
Secuencias de comandos entre sitios (XSS)	El atacante inyecta un script en una página vulnerable; el script lee la cookie de sesión mediante JavaScript y se la envía al atacante.	Se ha habilitado la cookie HttpOnly, de modo que los scripts del lado del cliente no pueden leerla en absoluto, además de una estricta desinfección de la entrada y una Política de Seguridad de Contenido.
Captura de sesión (captura de red)	Un atacante que se encuentre en la misma red no cifrada o degradada captura las cookies de sesión en tránsito utilizando herramientas de captura de paquetes.	TLS en todas partes, la bandera de cookies seguras y HSTS para evitar cualquier reversión a HTTP simple.
Fijación de sesión	El atacante proporciona a la víctima un ID de sesión conocido con antelación y luego lo reutiliza una vez que la víctima se autentica con él.	Regenera el ID de sesión en cada cambio de autenticación y privilegios; nunca aceptes un ID de sesión proporcionado por el cliente como válido antes de iniciar sesión.
ID de sesión predecible o obtenido mediante fuerza bruta	El atacante adivina o prueba diferentes identificadores de sesión débiles y de baja entropía hasta encontrar uno que coincida con una sesión activa.	Genere identificadores de sesión con un generador de números aleatorios criptográficamente seguro con 64 bits de entropía o más.
Ataque de intermediario en el navegador (malware de sesión)	El software malicioso presente en el dispositivo de la víctima lee o manipula directamente los datos de la sesión, independientemente de los controles de red o del servidor.	La protección de los puntos finales, la duración reducida de las sesiones y la reautenticación para acciones sensibles limitan las capacidades de un punto final comprometido.
Solicitud entre sitios sin SameSite	Un sitio web malicioso activa solicitudes que se transmiten a través de la cookie de sesión existente de la víctima, ya que el navegador la envía automáticamente.	SameSite=Strict o Lax en la cookie de sesión, para que no se adjunte a las solicitudes entre sitios.

Un ejemplo real del alcance que puede tener el secuestro de sesiones: la vulnerabilidad CVE-2024-53704 , revelada a principios de 2025, era una vulnerabilidad de omisión de autenticación en el componente SonicOS SSL VPN de SonicWall que permitía a un atacante remoto no autenticado secuestrar sesiones VPN activas, obteniendo acceso a los marcadores de Virtual Office, la configuración de NetExtender y el acceso a la red privada de la víctima. La Zero Day Initiative la recalificó a un nivel crítico de 9.8 CVSS, y semanas después de que se publicara un parche, miles de dispositivos conectados a Internet seguían sin actualizarse, lo que nos recuerda que el secuestro de sesiones no es un concepto teórico exclusivo de las aplicaciones web, sino una causa real de brechas de seguridad en las redes empresariales.

¿Cómo se debe clasificar la sensibilidad de la sesión y del token?

No todas las sesiones conllevan el mismo riesgo, por lo que las medidas de seguridad deben ajustarse a lo que una sesión comprometida expondría realmente. Clasifique las sesiones en niveles antes de decidir cuánto tiempo deben durar o con qué frecuencia deben volver a autenticarse.

Nivel de sesión	Ejemplo	Manejo recomendado
Público/anónimo	Navegar por un sitio web de marketing público o una base de conocimientos.	Estado mínimo de la sesión; bajo riesgo en caso de interceptación.
Autenticado estándar	Visualización de un perfil de usuario, configuración de cuenta no financiera	Tiempo de espera de inactividad estándar, indicadores de cookies Secure y HttpOnly
Datos sensibles/regulados	Sesiones que involucran información de identificación personal, datos de titulares de tarjetas PCI o datos de salud protegidos.	Tiempo de inactividad corto, SameSite=Strict, se supervisan las anomalías.
Privilegiado/administrativo	Consolas de administración, iniciación de pagos, interfaces de gestión de claves	Duración mínima, reautenticación obligatoria para acciones sensibles, rotación del ID de sesión al cambiar los privilegios.

¿Cómo se cifran los tokens de sesión y se elige un almacenamiento seguro?

Cifra cada token de sesión en tránsito con TLS y almacénalo en una cookie segura HttpOnly, en lugar de en una ubicación accesible mediante JavaScript o almacenamiento local. No existe una opción de "tokenización" significativa para los identificadores de sesión, como sí la hay para los datos de la tarjeta almacenados; la decisión equivalente aquí es dónde y cómo reside el token una vez emitido, y un error en esta decisión es lo que posibilita la mayoría de las técnicas de secuestro de tarjetas.

• Transporte: Aplique TLS 1.2 o superior a cada solicitud que contenga una cookie de sesión y utilice HSTS para que los navegadores se nieguen a recurrir al HTTP simple, incluso si un enlace o una redirección apunta hacia allí.
• Ubicación de almacenamiento: usar una cookie HttpOnly, no localStorage or sessionStorage, para el token de sesión, ya que cualquier cosa legible por JavaScript también es legible por una carga útil XSS.
• Banderas de cookies: y configure Secure (Solo HTTPS), HttpOnly (sin acceso a JavaScript) y SameSite=Strict or Lax (sin conexión automática entre sitios) en cada cookie de sesión, según el Guía rápida de gestión de sesiones de OWASP.
• Entropía y longitud: Generar identificadores de sesión con un generador de números aleatorios criptográficamente seguro que proporcione al menos 64 bits de entropía, lo que, según OWASP, le llevaría a un atacante cientos de años descifrar por fuerza bruta con tasas de intentos realistas.
• Prefijos de nombres de cookies: donde sea compatible, utilice el __Host- prefijo, que obliga al navegador a aplicar Secure, sin alcance entre dominios, y Path=/ en la galleta.

La infraestructura de certificados y claves es la base de todo esto: la terminación TLS es tan confiable como los certificados y las claves privadas que la respaldan. CertSecure Manager automatiza la administración del ciclo de vida de los certificados para que los puntos finales TLS nunca se ejecuten con un certificado caducado o mal configurado, y HSM-as-a-Service protege las claves privadas que respaldan esa terminación TLS en hardware, en lugar de en software que un servidor comprometido podría exponer.

¿Qué controles de acceso limitan los daños derivados del robo de una sesión?

La corta duración de las sesiones y la reautenticación obligatoria para acciones sensibles limitan lo que un atacante puede hacer incluso después de robar con éxito un ID de sesión. Según NIST SP 800-63B , el tiempo de reautenticación debe escalar con el nivel de seguridad: en AAL1, reautenticar al menos una vez cada 30 días; en AAL2, al menos cada 12 horas o después de 30 minutos de inactividad, lo que ocurra primero; en AAL3, al menos cada 12 horas o después de 15 minutos de inactividad, y la reautenticación requiere ambos factores de autenticación nuevamente. La guía general de OWASP es similar en espíritu: tiempos de espera de inactividad de 2 a 5 minutos para aplicaciones de alto valor y de 15 a 30 minutos para las de menor riesgo, con un tiempo de espera de sesión absoluto de 4 a 8 horas independientemente de la actividad, aplicado en el lado del servidor en lugar de confiarse al cliente.

Además de los tiempos de espera, se requiere una nueva autenticación, como volver a introducir la contraseña o una solicitud de autenticación multifactor (MFA) más exhaustiva, antes de realizar acciones de alto impacto: cambiar el correo electrónico o la contraseña de la cuenta, añadir un método de pago, otorgar privilegios administrativos o exportar datos confidenciales. Una sesión robada que no pueda superar esta segunda barrera resulta mucho menos útil para un atacante, incluso si el token subyacente es válido.

¿Cómo es una buena gobernanza del ciclo de vida de las sesiones?

La gobernanza del ciclo de vida de la sesión implica tratar la emisión, la rotación y la invalidación como pasos deliberados y obligatorios, en lugar de efectos secundarios del formulario de inicio de sesión. Tres momentos son los más importantes:

• Emisión: Generar un ID de sesión nuevo y de alta entropía al iniciar sesión correctamente; nunca reutilizar ni extender un ID de sesión previo a la autenticación en uno autenticado, que es precisamente lo que aprovecha la fijación de sesión.
• Rotación: regenerar el ID de sesión después de cualquier cambio de nivel de privilegio, como un restablecimiento de contraseña, un cambio de rol o una autenticación de nivel superior, utilizando llamadas a nivel de marco como session_regenerate_id(true) en PHP o una llamada equivalente de invalidación de sesión en su framework.
• Invalidación: Destruir la sesión tanto en el cliente como en el servidor al cerrar la sesión, mostrar un control de cierre de sesión visible en cada página autenticada y hacer que las sesiones caduquen en el servidor al expirar el tiempo de espera, en lugar de depender de la caducidad de la cookie, ya que una cookie robada no respeta el reloj del cliente.

¿Cómo deberían ser los procedimientos de recuperación y respuesta ante incidentes si se detecta un secuestro?

Si se confirma un intento de secuestro de sesión, invalide inmediatamente todas las sesiones activas de la cuenta afectada y fuerce la reautenticación antes de volver a confiar en cualquier sesión. A partir de ahí, una secuencia de respuesta práctica sería la siguiente:

1. Revocar todas las sesiones activas y los tokens vinculados a la cuenta afectada, en el servidor, no solo la sesión que mostró la anomalía.
2. Fuerza el restablecimiento de la contraseña y, si es posible, rota las claves API vinculadas o los tokens de larga duración que haya emitido la cuenta.
3. Revise el registro de actividad reciente de la cuenta para detectar acciones realizadas durante el período en que la cuenta fue pirateada y revierta o marque cualquier acción no autorizada.
4. Verifique si existe un vector de captura subyacente, como una vulnerabilidad XSS sin parchear, una bandera de cookies faltante o un punto final comprometido, y ciérrelo antes de restaurar el acceso normal.
5. Notifique al usuario afectado y, si se expusieron datos regulados, cumpla con las obligaciones de notificación de violaciones de seguridad de su organización conforme al marco aplicable.

¿Cómo se detectan comportamientos anómalos en las sesiones?

La monitorización continua detecta los intentos de secuestro que eluden los controles preventivos al observar comportamientos que una sesión legítima no produciría. Las señales útiles incluyen:

• Se utilizó un único ID de sesión desde dos direcciones IP geográficamente distantes dentro de un intervalo de tiempo implausiblemente corto.
• Un cambio repentino en el agente de usuario o la huella digital del dispositivo a mitad de sesión, sin un nuevo inicio de sesión correspondiente.
• Una sesión autenticada que de repente realiza acciones con altos privilegios que nunca antes había realizado para esa cuenta.
• Los intentos repetidos y rápidos de adivinar el ID de sesión o de obtener tokens de sesión mal formados que lleguen al punto final de inicio de sesión o de validación de sesión son una señal de un ataque de fuerza bruta.
• Tráfico dirigido a patrones conocidos de herramientas de secuestro de sesión, que los sistemas de detección y prevención de intrusiones pueden identificar en función de firmas de ataque conocidas.

Nada de esto sustituye la prevención; es la capa que parte de la base de que la prevención fallará ocasionalmente y que reduce el tiempo que un atacante tiene una sesión activa sin ser detectado.

¿Cómo se relaciona la seguridad de la sesión con los requisitos de cumplimiento normativo?

En la mayoría de los marcos de seguridad, los controles de gestión de sesiones no son opcionales; son requisitos específicos y con nombre. La siguiente tabla relaciona los controles mencionados anteriormente con los casos en que se requiere cada uno.

Control	OWASP	Norma NIST SP 800-63B	PCI DSS 4.0
Generación de entropía y ID de sesión	Guía rápida de gestión de sesiones: más de 64 bits de entropía mediante CSPRNG	Secretos de sesión vinculados a autenticadores criptográficos aprobados.	Requisito 6, prácticas seguras de desarrollo y criptografía
atributos de seguridad de las cookies	Se requiere Secure, HttpOnly y SameSite en las cookies de sesión.	No es específico de las cookies, pero requiere enlaces de sesión protegidos.	Requisito 6.2, codificación segura para prevenir fallos de sesión.
Tiempo de espera inactivo y absoluto	De 2 a 5 minutos de inactividad para aplicaciones de alto valor; de 4 a 8 horas en absoluto.	Reautenticación después de 15 a 30 minutos de inactividad, dependiendo de AAL.	Requisito 8.2.8, volver a autenticarse después de 15 minutos de inactividad
Reautenticación para acciones sensibles	Refuerza la autenticación antes de realizar acciones de alto impacto.	Autenticación completa con ambos factores en AAL3	Requisito 8, controles de autenticación robustos para el acceso de los usuarios.
Invalidación de la sesión al cerrar sesión.	Destrucción del lado del servidor, no solo del lado del cliente.	Se espera la finalización de la sesión al cerrar sesión.	Requisito 8: el acceso se revoca cuando ya no es necesario.

Limitaciones

Ningún control por sí solo elimina por completo el riesgo de secuestro de sesión. TLS protege una cookie de sesión en tránsito, pero no hace nada contra una vulnerabilidad XSS que lee la cookie directamente en el navegador. Las banderas de cookies como HttpOnly y SameSite detienen técnicas de robo específicas, pero no pueden detener una sesión robada mediante malware que ya se ejecuta en el dispositivo de la víctima. Los tiempos de espera cortos y la reautenticación reducen el período de exposición, pero generan dificultades para los usuarios legítimos, y los tiempos de espera excesivamente estrictos los llevan a buscar soluciones alternativas, como permanecer conectados permanentemente en un dispositivo compartido. La monitorización del comportamiento anómalo ayuda a detectar lo que la prevención no detecta, pero es probabilística, no certera, y un atacante paciente que imite la ubicación y el dispositivo habituales de la víctima puede eludirla durante un tiempo. Considere estos controles como un conjunto de capas, no como una solución única, y revíselos a medida que cambie el modelo de amenazas de su aplicación.

¿Qué recomendaría Encryption Consulting?

Empiece por los controles que bloquean directamente las técnicas de captura más comunes, y luego incorpore la monitorización y la gobernanza en lugar de intentar abarcarlo todo a la vez. En la práctica, orientamos a nuestros clientes hacia esta secuencia: aplicar TLS en todas partes con una gestión automatizada del ciclo de vida de los certificados para que los certificados caducados o mal configurados nunca creen una brecha para los ataques de degradación; establecer Secure, HttpOnly y SameSite en cada cookie de sesión como un cambio de configuración básico e innegociable; regenerar los ID de sesión al iniciar sesión y en cada cambio de privilegio; y ajustar los tiempos de espera por inactividad y los requisitos de reautenticación al nivel de sensibilidad de la sesión, no a un valor predeterminado único para toda la organización.

Cuando el problema subyacente radica en la gestión fragmentada de certificados y claves en múltiples aplicaciones, en lugar del código de sesión de una sola aplicación, la infraestructura de clave pública como servicio (PKI-as-a-Service) ofrece a los equipos una forma gestionada de emitir y rotar los certificados TLS que hacen posibles las sesiones cifradas, sin que cada equipo de aplicación tenga que reinventar la gestión del ciclo de vida de los certificados por su cuenta. Para las organizaciones que gestionan esto internamente, nuestra guía relacionada sobre los ataques SSL/TLS más comunes y cómo la gestión del ciclo de vida de los certificados ayuda a mitigarlos aborda con mayor profundidad el aspecto de la capa de transporte de este problema; esa publicación se centra en los ataques a certificados y protocolos que preceden o permiten la interceptación, mientras que esta se centra en lo que sucede con la sesión una vez que un atacante se ha infiltrado, por lo que conviene leerlas juntas en lugar de como duplicados.

Conclusión

El secuestro de sesiones se produce al explotar la confianza que un servidor deposita en un ID de sesión, no al descifrar una contraseña. La defensa es multicapa, no unidimensional: cifrar las sesiones en tránsito con TLS, proteger las cookies con las banderas Secure, HttpOnly y SameSite, mantener las sesiones cortas y volver a autenticarse para acciones sensibles, rotar los ID de sesión con cada cambio de privilegios y supervisar las anomalías que escapan a todas las medidas anteriores. Ningún control por sí solo cierra todas las vías de acceso, razón por la cual la seguridad de las sesiones debe gestionarse como un ciclo de vida completo, desde su emisión hasta su invalidación, en lugar de configurarse una sola vez y dejarse sin modificar.

Preguntas frecuentes

¿Es lo mismo el secuestro de sesión que la fijación de sesión? No. La fijación de sesión es una técnica específica para secuestrar una sesión: el atacante establece un ID de sesión conocido en la víctima con antelación y espera a que esta se autentique. El secuestro de sesión es el resultado más general: tomar el control de cualquier sesión válida. Esto se puede lograr mediante la fijación, el robo de cookies basado en XSS, el análisis de la red u otras técnicas.

¿Es suficiente con HTTPS para evitar el secuestro de sesión? No. TLS protege la cookie de sesión durante su transmisión por la red, lo que bloquea el secuestro mediante interceptación de datos, pero no protege contra una cookie de sesión robada en el lado del cliente a través de una vulnerabilidad XSS o malware ya presente en el dispositivo del usuario. HTTPS es necesario, pero no suficiente por sí solo.

¿Cuánto tiempo debería durar una cookie de sesión? Depende de a qué pueda acceder la sesión. La guía general de OWASP recomienda un tiempo de inactividad de 2 a 5 minutos para aplicaciones de alto valor y de 15 a 30 minutos para las de menor riesgo, con una duración absoluta de la sesión de 4 a 8 horas, independientemente de la actividad. El requisito 8.2.8 de PCI DSS 4.0 exige específicamente la reautenticación tras 15 minutos de inactividad para los sistemas incluidos en el ámbito de aplicación.

¿Protege la autenticación multifactor contra el secuestro de sesión? La MFA protege el inicio de sesión en sí, no una sesión ya establecida. Una vez que un usuario se ha autenticado y existe una cookie de sesión, un atacante que roba esa cookie suplanta la identidad de una sesión ya autenticada y no tiene que pasar la verificación de MFA. Precisamente por eso, la duración de la sesión, la rotación y la reautenticación para acciones sensibles son importantes como una capa independiente de la MFA.

¿Qué es lo primero que debemos hacer si sospechamos de un ataque de secuestro de sesión? Invalidar inmediatamente la sesión afectada y todas las demás sesiones activas de esa cuenta en el servidor, y luego forzar un nuevo inicio de sesión. Actuar únicamente sobre la sesión sospechosa no es suficiente si el atacante también ha capturado o podría reutilizar otros tokens válidos asociados a la misma cuenta.

Referencias

• OWASP, Guía rápida para la gestión de sesiones
• OWASP, Los 10 principales: A07:2021 Fallos de identificación y autenticación
• NIST, SP 800-63B Directrices sobre identidad digital, autenticación y gestión del ciclo de vida
• Consejo de Normas de Seguridad PCI, Preguntas frecuentes sobre el requisito PCI DSS 8.2.8
• Obispo Fox, Análisis de CVE-2024-53704, secuestro de sesión de VPN SSL de SonicWall
• Documentación web de MDN, Encabezado Set-Cookie, incluido el atributo SameSite.