¿Qué es la fijación de sesión?
La fijación de sesión es una vulnerabilidad en aplicaciones web que permite a un atacante secuestrar una sesión de usuario válida explotando una falla en la gestión del identificador de sesión. El defecto principal es sencillo: cuando un usuario se autentica, la aplicación no asigna un nuevo ID de sesión. Esto significa que un atacante que conoce o controla el identificador de sesión previo a la autenticación puede usarlo para acceder a la sesión autenticada como si fuera el usuario legítimo.
MITRE CWE define formalmente la debilidad: "Autenticar a un usuario, o de otro modo establecer una nueva sesión de usuario, sin invalidar ningún identificador de sesión existente le da al atacante la oportunidad de robar sesiones autenticadas." Para usted, el resultado es la toma casi total de la cuenta, a menudo sin que la víctima sepa que algo ocurrió.
La fijación de sesión es distinta del secuestro de sesión, aunque a veces se confundan. OWASP traza la línea claramente: la fijación de sesión comienza antes de que la víctima inicie sesión, mientras que el secuestro de sesión ocurre después de que ya existe una sesión autenticada activa. En un ataque de fijación, el atacante ya conoce el ID de sesión porque él lo estableció. En un ataque de secuestro, el atacante debe capturar o predecir el ID de sesión de una sesión activa.
| Atributo | Fijación de sesión | Secuestro de sesión |
| Momento del ataque | Antes de que la víctima se autentique | Después de que la víctima se haya autenticado |
| Conocimiento del ID de sesión | El atacante establece o conoce el ID de antemano | El atacante debe capturar o predecir el ID |
| Contramedida principal | Regeneración del ID de sesión al iniciar sesión | Encriptación del token, transmisión segura |
Esta distinción es importante para sus controles de seguridad. Si su aplicación regenera los IDs de sesión después de iniciar sesión, detiene los ataques de fijación. Si solo cifra los tokens de sesión en tránsito, aborda el secuestro pero deja la fijación completamente expuesta. Cuando comprende cómo funciona el ataque mecánicamente, puede ver por qué esta diferencia es tan crítica.
¿Cómo funciona la fijación de sesión?
La fijación de sesión sigue un flujo de ataque de cuatro pasos, documentado tanto por MITRE CWE como por OWASP WSTG.
- Paso 1: Adquisición de sesión. El atacante visita la aplicación objetivo y recibe un ID de sesión válido previo a la autenticación. Por ejemplo, el servidor podría devolver
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1. En aplicaciones que usan un mecanismo permisivo de aceptación de sesión, el atacante puede suministrar un valor arbitrario de ID de sesión que la aplicación aceptará sin cuestionar. - Paso 2: Entrega de sesión. El atacante entrega el ID de sesión conocido a la víctima. Esta entrega puede ocurrir mediante una URL manipulada, una carga útil de cross-site scripting, una etiqueta META inyectada o división de respuesta HTTP. El objetivo es simple: hacer que el navegador de la víctima envíe el ID de sesión controlado por el atacante al acceder a la aplicación objetivo.
- Paso 3: Autenticación de la víctima. La víctima hace clic en el enlace manipulado o accede a la aplicación a través del mecanismo de entrega del atacante e inicia sesión normalmente. La aplicación valida las credenciales y concede acceso. Pero no regenera el ID de sesión tras el inicio de sesión exitoso, continuando con el mismo identificador que el atacante ya conoce.
- Paso 4: Toma de control de la cuenta. El atacante envía solicitudes a la aplicación usando el ID de sesión conocido. El servidor trata estas solicitudes como si provinieran de la víctima autenticada. MITRE señala que esto proporciona "acceso casi irrestricto a la cuenta de la víctima durante la vida útil de la sesión."
Más allá de los cuatro pasos principales, la fijación de sesión puede entregarse mediante varios métodos distintos dependiendo del acceso del atacante y la configuración de la aplicación objetivo.
Cinco vectores de ataque principales
- Inyección de parámetros en la URL es el vector más simple. El atacante incrusta el ID de sesión como un parámetro de consulta en la URL y entrega el enlace por phishing o correo electrónico:
https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner clasifica "Session token in URL" como CWE-384. - Inyección de cookies vía XSS utiliza JavaScript que se ejecuta en el navegador de la víctima para establecer la cookie de sesión:
document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE confirma que cross-site scripting es una de las dos clases de técnicas más comunes para entregar cargas útiles de fijación de sesión. - Inyección de etiqueta META planta una etiqueta HTML que instruye al navegador a establecer una cookie:
<meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP señala que este enfoque es más difícil de contrarrestar que la inyección de JavaScript porque "es imposible deshabilitar el procesamiento de estas etiquetas en los navegadores." - Inyección de cabecera de respuesta HTTP explota vulnerabilidades de división de respuesta para inyectar una cabecera
Set-Cookiedirectamente en una respuesta del servidor, plantando el ID de sesión controlado sin ningún script del lado del cliente. - Fijación de cookies entre subdominios explota arquitecturas de dominio compartido. MITRE lo documenta directamente: si
bank.example.comyrecipes.example.comcomparten el mismo dominio de nivel superior, una vulnerabilidad en la aplicación de recetas puede fijar un ID de sesión que se usará en todas las aplicaciones deexample.com. La amplitud de los vectores de entrega explica por qué aún se observa fijación de sesión en sistemas en producción.
Causas de la fijación de sesión
Las causas raíz de la fijación de sesión están bien documentadas, y cada una representa una brecha que usted y su equipo de desarrollo pueden cerrar.
No regenerar los IDs de sesión tras la autenticación
Esta es la causa principal, citada por todas las fuentes autorizadas en el artículo. La guía OWASP lo indica directamente: "Cuando una aplicación no renueva su(s) cookie(s) de sesión tras una autenticación exitosa, podría ser posible encontrar una vulnerabilidad de fijación de sesión."
La hoja de OWASP especifica que la regeneración del ID de sesión es obligatoria al iniciar sesión, cambiar la contraseña, cambios de permisos y transiciones de rol. El registro de la CVE-2022-24895 documenta que la estrategia de migración de sesión NONE de Symfony preserva la misma sesión tras la autenticación, habilitando ataques de fijación, y tiene una calificación de ALTA severidad.
Aceptación permisiva de IDs de sesión
La OWASP Session Management Cheat Sheet define dos mecanismos para manejar los IDs de sesión. Un mecanismo permisivo acepta cualquier valor de ID de sesión establecido por el usuario como válido y crea una nueva sesión para él. Un mecanismo estricto solo acepta IDs de sesión previamente generados por la aplicación. Si su aplicación usa el mecanismo permisivo, permite que los atacantes planten valores arbitrarios sin obtener primero un ID emitido por el servidor.
Identificadores de sesión predecibles
MITRE identifica los identificadores de sesión predecibles como una condición contribuyente, relacionada con CWE-340 (Generación de números o identificadores predecibles). Cuando los IDs de sesión siguen patrones o usan aleatoriedad débil, los atacantes pueden predecir valores válidos sin necesidad de obtener uno del servidor.
Ámbito permisivo del dominio de la cookie
Establecer el atributo Domain de la cookie en un dominio de nivel superior, por ejemplo Domain=example.com en lugar de Domain=app.example.com, hace que las cookies se transmitan a todos los subdominios. Una vulnerabilidad en cualquier subdominio se convierte en un punto de entrada de fijación para cada aplicación en ese dominio.
Transición de HTTP a HTTPS sin regeneración de sesión
OWASP WSTG-SESS-03 identifica este escenario específico: sitios que emiten un identificador de sesión sobre HTTP y luego redirigen a un formulario de inicio de sesión HTTPS, sin volver a emitir el ID de sesión tras la autenticación, exponen el ID previo a la autenticación a escuchas a nivel de red. El atacante captura el ID en la conexión insegura y espera a que la víctima se autentique. Estas causas rara vez aparecen de forma aislada, y comprender cómo la comunidad de estándares las clasifica formalmente le ayuda a comunicar y priorizar la remediación.
Clasificación OWASP de la fijación de sesión
La fijación de sesión está formalmente clasificada en tres sistemas de estándares autorizados: el MITRE Common Weakness Enumeration, el OWASP Top 10 y la OWASP Web Security Testing Guide. Bajo OWASP A07, se ubica dentro de la categoría de fallos de autenticación junto a debilidades relacionadas que comparten el mismo alcance de remediación. Cada clasificación sirve a una audiencia diferente y señala una acción distinta.
CWE-384: Identificador formal de debilidad
MITRE CWE-384 es la clasificación principal para la fijación de sesión, definiendo la debilidad como autenticar a un usuario sin invalidar el identificador de sesión existente. Su perfil en la taxonomía MITRE:
- Tipo de debilidad: Debilidad base dentro de la categoría de credenciales de sesión
- Consecuencias comunes: Obtener privilegios o asumir la identidad de la víctima; toma total de la cuenta durante la vida útil de la sesión
- Probabilidad de explotación: Media — requiere entregar un ID de sesión conocido a la víctima antes del inicio de sesión
- Alcance de plataforma: Independiente del lenguaje; aplica sin importar el stack web o framework
- Estado en CWE Top 25: Ingresó al Top 25 en 2019; sigue siendo una debilidad rastreada activamente en la edición 2023
Estas propiedades hacen que CWE-384 sea una señal consistente en los escáneres de vulnerabilidades y frameworks de evaluación, donde se mapea directamente a casos de prueba que apuntan al manejo del ciclo de vida de la sesión.
OWASP Top 10 y estándares de pruebas
CWE-384 se mapea a A07:2025 — Fallos de autenticación en el OWASP Top 10. Esta clasificación conlleva una implicación importante: la fijación de sesión se trata como un fallo de control de autenticación, no como una mala configuración de cookies. Esa distinción la coloca directamente dentro de las revisiones del flujo de inicio de sesión y el endurecimiento de la autenticación, no solo en auditorías de configuración de cookies.
| Referencia | Sistema | Propósito |
| MITRE CWE | Seguimiento formal de debilidades; usado por herramientas SAST/DAST y registros CVE | |
| OWASP Top 10 | Señal de priorización de riesgos; delimita la revisión a controles de autenticación | |
| OWASP WSTG | Procedimiento de prueba black-box autorizado y criterios de aprobación/rechazo | |
| OWASP CheatSheets | Referencia de prevención para desarrolladores sobre regeneración, alcance de cookies y modo estricto |
Juntas, estas cuatro referencias le dan el vocabulario, los casos de prueba y la guía de remediación para abordar la fijación de sesión dentro de cualquier programa de seguridad existente. Con el contexto de clasificación establecido, vale la pena examinar qué ocurre realmente cuando la vulnerabilidad se explota con éxito.
Impacto y riesgo de la fijación de sesión
La fijación de sesión permite la toma total de la cuenta durante la vida útil de la sesión comprometida. Una vez que un atacante posee un ID de sesión autenticado, opera con todos los privilegios que posee la víctima: lectura de datos sensibles, inicio de transacciones, modificación de configuraciones de cuenta y escalamiento de acceso si la víctima tiene derechos administrativos.
Clasificación y severidad OWASP
CWE-384 cae bajo OWASP A07. La categoría A07:2025 tiene una puntuación promedio ponderada de explotabilidad de 7.69, mapeada a 7,147 CVEs totales en aplicaciones probadas. El total de CVEs mapeados a la categoría A07 también aumentó entre las ediciones 2021 y 2025, reflejando una expansión en lugar de contracción de la superficie de ataque.
Rango de puntuación CVSS
Los CVEs confirmados de fijación de sesión abarcan desde Media a Crítica. Los casos con mayor puntuación suelen involucrar escenarios donde la fijación permite la toma de cuentas no autenticadas en plugins o frameworks de autenticación ampliamente desplegados. Un matiz importante para usted como profesional: los CVEs de fijación de sesión frecuentemente muestran discrepancias de puntuación entre NIST NVD y los CNA de los proveedores. Por ejemplo, CVE-2019-17563 (Apache Tomcat) recibió una calificación CRÍTICA de NIST pero una evaluación de "Baja" de Apache, que describió la ventana de explotación como "demasiado estrecha para que un exploit sea práctico."
Factores de riesgo compuestos
La fijación de sesión rara vez es un riesgo independiente. CVE-2024-56529 (Mailcow) muestra que el ataque tiene éxito específicamente cuando HSTS está deshabilitado en el navegador de la víctima. Un artículo de Microsoft Research presentado en IEEE S&P 2015 documentó que la inyección de cookies podía eludir las defensas estándar de regeneración de sesión en sitios web reales. Cuando los controles de defensa en profundidad fallan simultáneamente, una vulnerabilidad de fijación de sesión puede escalar rápidamente. La cuestión de quién es vulnerable va más allá de solo las aplicaciones web.
Cómo los atacantes explotan la fijación de sesión
Los atacantes explotan la fijación de sesión mediante escenarios que van desde phishing dirigido hasta envenenamiento de sesión oportunista.
Inyección de URL basada en phishing
El atacante crea una URL que contiene un ID de sesión conocido y la entrega mediante phishing o ingeniería social. La URL parece legítima porque apunta al dominio real de la aplicación. La víctima hace clic en el enlace, inicia sesión normalmente y, sin saberlo, autentica una sesión que controla el atacante. Este es el escenario más común para la transmisión de IDs de sesión vía URL.
Explotación de terminales públicos
MITRE CWE-384 documenta un escenario canónico: un atacante crea una sesión desde un terminal público, registra el identificador de sesión, restablece el navegador a la página de inicio de sesión y espera a que el siguiente usuario se autentique. La aplicación sigue usando el ID de sesión preexistente, dando al atacante "acceso casi irrestricto a la cuenta de la víctima durante la vida útil de la sesión."
Envenenamiento de sesión no dirigido
CVE-2022-30769 (ZoneMinder) demostró un ataque donde un atacante podía "envenenar una cookie de sesión para el siguiente usuario que inicie sesión." Esto no requería dirigir el ataque a un individuo específico. La sesión envenenada era heredada por quien autenticara a continuación. En entornos de acceso compartido como plataformas de vigilancia, este patrón es especialmente peligroso.
Explotación de condiciones de carrera
CVE-2013-2067 (Apache Tomcat) reveló una condición de carrera en la autenticación FORM. Al enviar repetidamente solicitudes de recursos autenticados mientras una víctima completaba el formulario de inicio de sesión, un atacante podía inyectar una solicitud ejecutada usando las credenciales de la víctima. Apache calificó esto como de severidad "Importante".
Ataques entre subdominios
En arquitecturas multiaplicación que comparten un dominio de nivel superior, los atacantes explotan una aplicación de baja seguridad para fijar una cookie de sesión con alcance al dominio principal. Todas las demás aplicaciones en ese dominio aceptan el ID de sesión fijado. Este escenario es común en entornos empresariales que ejecutan múltiples herramientas internas en un dominio compartido. Saber quiénes se ven afectados le ayuda a priorizar dónde buscar estas vulnerabilidades.
¿Quiénes se ven afectados por la fijación de sesión?
La fijación de sesión afecta a cualquier aplicación que gestione sesiones de usuario mediante identificadores y no los regenere tras la autenticación. El registro CVE y la documentación de MITRE señalan varias categorías estructuralmente de alto riesgo.
- Aplicaciones web que usan identificadores de sesión en la URL enfrentan la exposición más directa. La transmisión de sesión vía URL permite a los atacantes suministrar un ID de sesión controlado mediante un enlace manipulado sin requerir vulnerabilidad adicional.
- Ecosistemas de CMS y plugins de autenticación se ven afectados repetidamente. CVE-2024-13279 (Drupal TFA, según CISA), CVE-2010-1434 (Joomla!), CVE-2012-5391 (MediaWiki) y CVE-2019-8116 (Magento) muestran que los módulos de autenticación añadidos a plataformas CMS introducen riesgo crítico de fijación de sesión cuando no se aplica la regeneración de sesión.
- Aplicaciones J2EE/Java EE tienen una de las series de CVEs documentadas más extensas. Apache Tomcat por sí solo abarca CVEs desde 2013 hasta 2025, incluyendo CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563 y CVE-2025-55668.
- Arquitecturas multiaplicación de dominio compartido son vulnerables por diseño. Las plataformas SaaS con subdominios de inquilinos y portafolios de aplicaciones empresariales que comparten un dominio de nivel superior enfrentan riesgo de fijación entre subdominios, como documenta MITRE directamente.
- Plataformas ICS/SCADA representan una superficie de riesgo emergente. CVE-2025-70973 (ScadaBR 1.12.4, divulgada en marzo de 2026) muestra fijación de sesión en plataformas de sistemas de control industrial, consistente con los mapeos de categoría ICS de CWE-384 a CWE-1364 (ICS Communications: Zone Boundary Failures) y CWE-1366 (ICS Communications: Frail Security in Protocols).
- Plataformas de flujo de trabajo empresarial también presentan exposición documentada. CVE-2022-38369 (Apache IoTDB) y CVE-2022-38054 (Apache Airflow) muestran que las herramientas de automatización de flujos de trabajo no son inmunes. La amplitud de las categorías afectadas hace que los casos de estudio reales sean una lente útil para entender cómo aparecen estas vulnerabilidades en la práctica.
Ejemplos reales de fijación de sesión
La fijación de sesión ha sido confirmada en una amplia gama de sistemas en producción, desde frameworks empresariales Java hasta plataformas de control industrial. Los ejemplos a continuación ilustran cómo el mismo defecto subyacente se manifiesta de manera diferente según el entorno.
Condición de carrera en autenticación FORM de Apache Tomcat (CVE-2013-2067)
Este sigue siendo el CVE de fijación de sesión más impactante de Tomcat, calificado como "Importante" por Apache. Afectando Tomcat 6.0.21 a 6.0.36 y 7.0.0 a 7.0.32, la vulnerabilidad explotaba una condición de carrera en la autenticación FORM. Un atacante podía enviar repetidamente solicitudes de recursos autenticados mientras una víctima completaba el formulario de inicio de sesión, inyectando una solicitud que se ejecutaba usando las credenciales de la víctima. La ironía es que la opción para cambiar el ID de sesión al autenticarse se añadió en Tomcat 6.0.21. Este CVE representó un error en la propia protección contra fijación de Tomcat.
Bypass de token CSRF en el framework Symfony (CVE-2022-24895)
Las versiones de Symfony de la 2.0.0 a la 6.2.5 se vieron afectadas por una vulnerabilidad de ALTA severidad. El framework regeneraba el ID de sesión al iniciar sesión pero preservaba el resto de los atributos de la sesión, incluidos los tokens CSRF. Esta regeneración parcial permitía a atacantes same-site eludir la protección CSRF mediante una variante de fijación de sesión. La lección es clara: regenerar solo el ID de sesión no es suficiente. Se requiere la invalidación y reemisión completa de la sesión.
Sistema de control industrial ScadaBR (CVE-2025-70973)
Divulgada en marzo de 2026, esta vulnerabilidad en ScadaBR 1.12.4 sigue el patrón canónico de fijación de sesión. La aplicación asigna una cookie de sesión JSESSIONID a usuarios no autenticados y no regenera el identificador de sesión tras la autenticación exitosa. Una sesión creada antes del inicio de sesión se vuelve autenticada una vez que la víctima inicia sesión. Este CVE es notable porque muestra riesgo activo de fijación de sesión en entornos ICS/SCADA.
Envenenamiento de sesión no dirigido en ZoneMinder (CVE-2022-30769)
ZoneMinder 1.36.12 y versiones anteriores permitían a un atacante envenenar una cookie de sesión que sería heredada por el siguiente usuario que se autenticara. Esto no requería dirigir el ataque a una víctima específica, lo que lo hace especialmente peligroso en entornos de vigilancia de acceso compartido donde varios operadores comparten acceso a la misma plataforma.
Adopción de sesión en PHP (CVE-2011-4718)
El módulo de sesión de PHP era "adoptivo", lo que significa que aceptaba IDs de sesión de fuentes externas. La RFC de PHP indicaba que "el uso de session_regenerate_id() NO PUEDE prevenir la adopción/fijación de sesión" sin habilitar también session.use_strict_mode. PHP 5.5.2 introdujo session.use_strict_mode como la solución, pero incluso con el modo estricto habilitado, los controladores de guardado personalizados podían seguir siendo vulnerables. El registro histórico completo de estos incidentes muestra cuán persistente ha sido esta clase de vulnerabilidad.
Línea de tiempo e historia de la fijación de sesión
La fijación de sesión ha sido documentada formalmente desde 2002, y el registro CVE muestra que sigue activa en bases de código nuevas y heredadas. La línea de tiempo a continuación traza eventos clave de divulgación y respuestas a nivel de framework.
| Año | Evento |
| Dic 2002 | Mitja Kolšek (ACROS Security) publica "Session Fixation Vulnerability in Web-based Applications", nombrando formalmente la fijación de sesión como una cuarta clase de ataque contra identificadores de sesión |
| 2006 | CVE-2006-1228 (Drupal 4.5.x/4.6.x): fijación de ID de sesión vía URL |
| Jul 2006 | MITRE añade CWE-384 a Common Weakness Enumeration (Draft 3) |
| Feb 2008 | Oracle/BEA WebLogic Server advisory BEA08-196.00: fijación de sesión permitiendo escalamiento de privilegios |
| 2009 | CVE-2009-1580 (SquirrelMail); Black Hat USA documenta CWE-384 en comunidades de trackers BitTorrent |
| 2010 | CVE-2010-1434 (Joomla! 1.5.0 a 1.5.15): CVSS 7.5 ALTA |
| Dic 2011 | CVE-2011-4718 (adopción de sesión en PHP): afecta PHP 5.0.0 a 5.5.1 |
| May 2013 | CVE-2013-2067 (Apache Tomcat 6.x, 7.x): condición de carrera en autenticación FORM, severidad "Importante" según Apache |
| 2015 | Microsoft Research (IEEE S&P) documenta inyección de cookies que elude defensas de regeneración ampliamente adoptadas |
| 2019 | CWE-384 entra en el Top 25 |
| Dic 2019 | CVE-2019-17563 (Apache Tomcat): NIST 9.8 CRÍTICA vs. Apache "Baja" |
| 2022 | CVE-2022-24895 (Symfony): bypass de regeneración parcial |
| Ene 2025 | CVE-2024-56529 (Mailcow): fijación de sesión cuando HSTS está deshabilitado |
| Ago 2025 | CVE-2025-55668 (Apache Tomcat 9.x/10.x/11.x): CVSS 6.5 MODERADA |
| Mar 2026 | CVE-2025-70973 (ScadaBR 1.12.4) y CVE-2026-25101 (Bludit): nuevos CVEs confirman que la clase de vulnerabilidad sigue activa |
La línea de tiempo abarca más de dos décadas sin señales de desaceleración. La fijación de sesión no es una vulnerabilidad histórica. Continúa apareciendo tanto en bases de código nuevas como heredadas, desde frameworks empresariales hasta plataformas ICS. Si sabe cómo revisar sus propias aplicaciones, puede dar el siguiente paso.
Cómo detectar la fijación de sesión
La fijación de sesión es una de las vulnerabilidades más sencillas de confirmar: la prueba principal solo requiere capturar un identificador de sesión antes del inicio de sesión, autenticarse y comparar el valor después. Los siguientes enfoques cubren verificación manual, inspección de atributos de cookies, escaneo automatizado e identificación a nivel WAF.
Pruebas de penetración manual (OWASP WSTG-SESS-03)
El procedimiento de prueba autorizado proviene de la OWASP WSTG. Para usted, la prueba black-box es directa.
- Capture el ID de sesión previo a la autenticación. Visite la aplicación y registre el valor de la cookie de sesión
(por ejemplo, JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1). - Autentíquese presentando el ID de sesión capturado. Envíe credenciales válidas con la cookie de sesión original adjunta.
- Compare los valores de ID de sesión. Si el servidor devuelve el mismo ID de sesión tras la autenticación exitosa, la aplicación es vulnerable.
Para aplicaciones sin adopción completa de HSTS, WSTG-SESS-03 describe una segunda estrategia: fuerce todas las cookies no emitidas tras el inicio de sesión en el navegador de la víctima desde otra máquina, luego confirme si esas cookies otorgan acceso a la sesión de la víctima después de la autenticación.
Verificación de atributos de cookies
Verifique indicadores de endurecimiento en sus cookies de sesión. El prefijo __Host- proporciona integridad contra la fijación de sesión basada en red. El prefijo __Secure- indica endurecimiento parcial. Ejecute WSTG-SESS-03 para verificar que los atributos HttpOnly, Secure y SameSite estén correctamente configurados.
Escaneo DAST
OWASP ZAP ofrece modos de escaneo activo y pasivo con soporte para gestión de sesiones, incluyendo manejo de cookies, tokens y otros mecanismos. El análisis de ZAP sobre la gestión de sesión y la aplicación de autenticación le ayuda a encontrar autenticación rota y errores de fijación de sesión. Burp Suite Professional cubre flujos de trabajo de pruebas de gestión de sesión, funcionando como un escáner dinámico de vulnerabilidades web aplicable a pruebas de gestión de sesión.
Identificación basada en WAF
La hoja de OWASP identifica ModSecurity combinado con el OWASP Core Rule Set como contramedidas contra ataques de fijación de sesión. Este enfoque a nivel WAF se recomienda cuando el código fuente no está disponible, no puede modificarse o cuando implementar correcciones completas a nivel de aplicación requeriría un rediseño extenso. Una revisión efectiva debe conducir directamente a la prevención, y los controles requeridos están bien definidos.
Cómo prevenir la fijación de sesión
La prevención se centra en un requisito innegociable: la aplicación debe emitir un nuevo ID de sesión en cada evento de autenticación y rechazar cualquier identificador de sesión que no haya sido generado por el propio servidor. Los controles a continuación abordan ese requisito en la capa de aplicación, a nivel de framework, configuración de cookies y arquitectura de red.
Controles a nivel de aplicación
- Regenerar los IDs de sesión tras la autenticación. Este es el control más importante. OWASP WSTG-SESS-03 establece el requisito claramente: "la aplicación siempre debe invalidar primero el ID de sesión existente antes de autenticar a un usuario, y si la autenticación es exitosa, proporcionar otro ID de sesión." La regeneración es obligatoria en cada cambio de nivel de privilegio, incluyendo inicio de sesión, cambios de contraseña, cambios de permisos y transiciones de rol.
- Usar gestión estricta de sesiones. Configure su aplicación para aceptar solo IDs de sesión generados por el servidor. Rechace valores arbitrarios de ID de sesión enviados por los clientes. PHP introdujo session.use_strict_mode en la versión 5.5.2 específicamente para este propósito.
- Invalidar completamente las sesiones. CVE-2022-24895 (Symfony) demostró que la regeneración parcial de la sesión no es suficiente. Regenerar el ID de sesión mientras se preservan otros atributos de la sesión como los tokens CSRF crea una vulnerabilidad residual. Se requiere la invalidación y reemisión completa de la sesión.
Implementación específica de framework
| Framework | Invalidar sesión existente | Crear nueva sesión |
| J2EE | HttpSession.invalidate() | request.getSession(true) |
| ASP.NET | Session.Abandon() | Response.Cookies.Add(new HttpCookie(...)) |
| PHP | session_start() | session_regenerate_id(true) |
Spring Security protege contra la fijación de sesión automáticamente creando una nueva sesión o cambiando el ID de sesión cuando un usuario inicia sesión. Hay cuatro estrategias configurables disponibles: changeSessionId() (recomendada), migrateSession(), newSession(), y none() (no recomendada).
Configuración de seguridad de cookies
Siga los requisitos de NIST SP 800-63B:
- Bandera
Secure: DEBE estar establecida (cookies solo transmitidas por HTTPS) DomainyPath: DEBEN restringirse al alcance mínimo práctico- Bandera
HttpOnly: DEBERÍA estar establecida (previene acceso por JavaScript) SameSite=LaxoStrict: DEBERÍAestar establecida (según el borrador NIST SP 800-63B v4)- Prefijo
__HostconPath=/:DEBERÍA estar establecido (según el borrador NIST SP 800-63B v4)
Aplicar estas banderas en combinación previene los escenarios de entrega de fijación más comunes basados en red y cross-site, y eleva significativamente la dificultad para cualquier atacante que intente inyección de cookies.
Controles a nivel de arquitectura
No mezcle aplicaciones de diferentes niveles de seguridad en el mismo dominio. Implemente HSTS completo incluyendo subdominios para contrarrestar la fijación basada en red. Despliegue ModSecurity con OWASP Core Rule Set para protección a nivel WAF cuando los cambios a nivel de aplicación no sean posibles de inmediato. La prevención y la revisión funcionan mejor cuando se apoyan en las herramientas adecuadas.
Herramientas para detección y prevención
Identificar y detener la fijación de sesión requiere herramientas en tres capas: escáneres dinámicos que simulan condiciones reales de ataque, protecciones nativas de framework que aplican configuraciones seguras a nivel de código y análisis de comportamiento que detectan intrusiones basadas en fijación que alcanzan la sesión autenticada. Las herramientas a continuación cubren las tres.
Herramientas DAST y de pruebas de penetración
- OWASP ZAP es una herramienta gratuita y de código abierto para pruebas dinámicas de seguridad de aplicaciones. Según la documentación oficial, ZAP utiliza modos de escaneo activo y pasivo para encontrar fallos en la gestión de sesiones, incluida la fijación de sesión.
- Burp Suite Professional proporciona flujos de pruebas de sesión y reglas de escaneo para identificar vulnerabilidades en el manejo de tokens de sesión. Sus capacidades de prueba manual le permiten seguir el procedimiento WSTG-SESS-03 con visibilidad completa de solicitudes y respuestas.
- ModSecurity con OWASP Core Rule Set proporciona contramedidas a nivel WAF contra la fijación de sesión, incluyendo identificación y aplicación de atributos de seguridad en cookies, seguimiento de sesión persistente y renovación del ID de sesión cuando se observan cambios de privilegio.
Características de seguridad de frameworks
La protección integrada contra fijación de sesión de Spring Security, session.use_strict_mode y session_regenerate_id() de PHP, y Session.Abandon() de ASP.NET proporcionan prevención nativa por lenguaje. Debe verificar que estas funciones estén habilitadas y correctamente configuradas en sus despliegues en lugar de confiar en la configuración predeterminada.
Vulnerabilidades relacionadas
La fijación de sesión no opera de forma aislada. Varias debilidades estrechamente relacionadas comparten mecanismos de entrega, condiciones de explotación o factores de riesgo con CWE-384. Entenderlas como grupo produce un alcance de remediación más sólido que tratar la fijación de sesión por separado.
- Cross-Site Scripting (CWE-79) sirve como mecanismo de entrega para la fijación de sesión. XSS reflejado puede inyectar JavaScript que establece una cookie de sesión controlada en el navegador de la víctima. Abordar XSS cierra uno de los principales canales de entrega de fijación.
- Cross-Site Request Forgery (CWE-352) a menudo se confunde con la fijación de sesión, pero la mecánica es diferente. CSRF explota la transmisión automática de cookies del navegador para falsificar solicitudes desde una sesión autenticada. No requiere que el atacante conozca o controle el ID de sesión. CWE-352 ocupó el puesto #9 en el CWE Top 25 de 2023.
- Autenticación incorrecta (CWE-287) está estrechamente relacionada con la fijación de sesión, ubicándose en la misma categoría OWASP A07 de fallos de autenticación. CWE-287 cubre todas las formas de autenticación rota y ocupó el puesto #13 en el CWE Top 25 de 2023 con 10 entradas en el catálogo de vulnerabilidades explotadas conocidas de CISA.
- Expiración insuficiente de sesión (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) amplifica el riesgo de fijación de sesión al extender la ventana durante la cual un ID de sesión fijado permanece válido. Tiempos de espera largos dan a los atacantes más tiempo para explotar una sesión fijada.
- Generación de números predecibles (CWE-340) puede preceder a la fijación de sesión mediante una relación CanFollow en la taxonomía de MITRE. Identificadores de sesión predecibles reducen la barrera para ataques de fijación al hacer posible adivinar valores válidos de ID de sesión. Abordar la fijación de sesión de forma aislada rara vez cubre toda la superficie de riesgo; revisar estas debilidades relacionadas en el mismo ciclo cierra las brechas que la fijación explota para obtener su punto de apoyo inicial.
CVEs relacionados
ID CVE | Descripción | Severidad | Producto afectado | Año |
| El identificador de sesión no se regenera tras el inicio de sesión; el atacante establece el ID de sesión de la víctima antes de la autenticación y secuestra la sesión posterior al inicio de sesión | Pendiente | OpenSolution: Quick.Cart | 2026 | |
| Fijación de sesión desencadenada cuando la autenticación remota usa variables SSO; el atacante puede robar la sesión previamente abierta por otro usuario en la misma máquina | Pendiente | GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5) | 2026 | |
| Fijación de sesión (CWE-384) permite al atacante tomar el control de la sesión del usuario y realizar transacciones no autorizadas en nombre de la víctima | MEDIA (6.5) | HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0) | 2025 | |
| Manejo incorrecto de sesión (CWE-287) en ManageEngine ADSelfService Plus; usuario autenticado con bajos privilegios explota gestión incorrecta de sesión para tomar el control de otras cuentas de usuario | ALTA (9.3) | Zohocorp ManageEngine ADSelfService Plus (≤ build 6510) | 2025 | |
| Fijación de sesión (CWE-384) en el middleware de sesión de GoFiber; acepta valores de session_id suministrados por el usuario, dando al atacante control de la clave de sesión autenticada | CRÍTICA (9.8) | GoFiber: Fiber (< 2.52.5) | 2024 | |
| Secuestro de sesión (CWE-384) en el plugin de autenticación mejorada de VMware (obsoleto); atacante local sin privilegios secuestra la sesión EAP autenticada de un usuario de dominio privilegiado | ALTA (7.8) | VMware: Enhanced Authentication Plug-in (obsoleto) | 2024 | |
| Relé de autenticación y secuestro de sesión en VMware EAP (obsoleto); actor malicioso engaña al usuario de dominio para retransmitir tickets de servicio Kerberos para SPNs arbitrarios de Active Directory | CRÍTICA (9.6) | VMware: Enhanced Authentication Plug-in (obsoleto) | 2024 | |
| SECRET_KEY predeterminado en Apache Superset usado para firmar cookies de sesión; atacante con conocimiento del valor predeterminado puede forjar cookies de sesión válidas y autenticarse como cualquier usuario, incluidos administradores; CISA KEV | CRÍTICA (9.8) | Apache Superset (≤ 2.0.1) | 2023 | |
| El ID de sesión permanece válido en el gestor de IDs de sesión cuando se lanza una excepción desde SessionListener#sessionDestroyed() (CWE-613); la sesión del usuario anterior es accesible tras cerrar sesión en computadoras compartidas | BAJA (3.5) | Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3) | 2021 | |
| Tokens de sesión firmados con la clave secreta predeterminada aceptados entre diferentes despliegues de Airflow; usuario autenticado en una instancia puede acceder a otra sin reautenticación | ALTA (8.8) | Apache Airflow Webserver (< 1.10.14) | 2020 |
Ciberseguridad basada en IA
Mejore su postura de seguridad con detección en tiempo real, respuesta a velocidad de máquina y visibilidad total de todo su entorno digital.
DemostraciónConclusión
La fijación de sesión explota una única falla bien entendida: su aplicación no regenera el ID de sesión tras la autenticación. Formalmente clasificada como CWE-384 y mapeada al OWASP Top 10 2025 A07, sigue apareciendo en plataformas CMS, frameworks Java, aplicaciones PHP y sistemas ICS/SCADA.
Usted reduce el riesgo rotando los IDs de sesión en cada cambio de privilegio, aplicando aceptación estricta de sesión, endureciendo el alcance de las cookies y revisando la actividad posterior a la autenticación en busca de uso indebido.
Preguntas frecuentes
La fijación de sesión ocurre cuando una aplicación mantiene el mismo ID de sesión antes y después del inicio de sesión. Un atacante primero hace que la víctima use un ID de sesión conocido y luego espera a que la víctima se autentique.
Si la aplicación no emite un ID nuevo, el atacante puede usar esa misma sesión autenticada. La defensa clave es simple: invalidar la sesión antigua y crear una nueva después del inicio de sesión y otros cambios de privilegios.
Sí. CWE-384 está incluido en OWASP Top 10 2025 A07: Fallos de autenticación. Para usted como defensor, eso importa menos como etiqueta que como señal de priorización: la fijación de sesión se trata como un fallo de autenticación, no solo una mala configuración de cookies.
Debe incluirse en revisiones de flujos de inicio de sesión, pruebas de gestión de sesiones y trabajos de refuerzo de autenticación.
Sí. La entrega remota es común porque el atacante normalmente solo necesita una forma de hacer que la víctima use un ID de sesión elegido. Eso puede ocurrir mediante una URL manipulada, un script en el navegador, una respuesta maliciosa o una aplicación más débil en el mismo dominio principal.
El acceso físico solo es necesario en escenarios como terminales compartidos o públicos.
Las aplicaciones de mayor riesgo son aquellas que aceptan identificadores de sesión proporcionados por el usuario o no los rotan después de la autenticación. Ejemplos comunes en el artículo incluyen esquemas de sesión basados en URL, módulos de autenticación de CMS, pilas de aplicaciones Java, entornos de dominio compartido, plataformas de flujo de trabajo e interfaces web de ICS/SCADA.
El patrón compartido es una gestión débil del ciclo de vida de la sesión, no un solo lenguaje o industria.
Prueban si una sesión sobrevive al inicio de sesión sin cambios. Un método simple es capturar un ID de sesión antes de la autenticación, autenticarse con él y comparar el valor después.
Si el mismo ID sigue siendo válido, la falla está presente. Las herramientas de escaneo pueden ayudar, pero a menudo se necesita prueba manual para casos límite como regeneración parcial o comportamiento de cookies entre subdominios.
Busque una sesión que se comporte como si dos usuarios la poseyeran. Señales de advertencia prácticas incluyen la misma sesión apareciendo desde diferentes direcciones IP, cambios repentinos de dispositivo o ubicación, o patrones de acceso que cambian inmediatamente después del inicio de sesión.
Las solicitudes que llevan identificadores de sesión en URLs a puntos finales de autenticación también pueden indicar intentos de fijación en lugar de navegación normal.
La gravedad depende de lo que pueda hacer la cuenta comprometida. En contextos de bajo valor, puede clasificarse como media. En sistemas de alto valor, la misma falla puede permitir la toma total de cuentas y abuso administrativo.
Los ejemplos de CVE del artículo van de 4.6 a 9.8, lo que muestra que la fijación de sesión no es intrínsecamente menor; el impacto depende de privilegios, exposición y controles circundantes.
Puede llevar directamente a la toma total de la cuenta objetivo, y eso puede convertirse en una toma más amplia si la víctima es un administrador. Una vez que el atacante hereda privilegios elevados, puede cambiar configuraciones, acceder a datos sensibles o realizar acciones que afectan a todo el entorno.
La falla en sí misma apunta a sesiones, pero el impacto empresarial puede ir mucho más allá de un solo inicio de sesión.
La forma más simple es relativamente fácil de detectar porque las herramientas pueden comparar los IDs de sesión antes y después de la autenticación. Los casos más difíciles implican regeneración parcial, cookies heredadas entre subdominios o condiciones ligadas al transporte y comportamiento del navegador.
En la práctica, el escaneo es útil para la cobertura, pero las pruebas manuales enfocadas siguen siendo importantes para confirmar la explotabilidad real.
Cualquier industria que ejecute aplicaciones web autenticadas está expuesta, especialmente donde los usuarios manejan datos o transacciones sensibles. El artículo destaca comercio electrónico, plataformas empresariales, entornos de dominio compartido, sistemas regulados tipo sanitario y despliegues ICS/SCADA.
El riesgo aumenta cuando las organizaciones dependen de plugins, gestión de sesiones heredada o múltiples aplicaciones que comparten un dominio principal.
