El session hijacking es un problema clásico pero todavía crítico. Cuando se captura la cookie de sesión del usuario, el atacante intenta tomar el control de la sesión con el mismo token. Si el sistema solo mira la existencia del token, no comprueba en qué contexto de IP, dispositivo, navegador o usuario se generó ese token. En ese caso, el identificador de sesión se convierte por sí solo en el límite de seguridad.
Olvidar los flags de seguridad de cookies también es una debilidad común. Sin HttpOnly, los scripts del lado del cliente pueden acceder a la cookie; sin Secure, la capa de transporte se debilita; sin SameSite, las solicitudes cross-site se vuelven más riesgosas. Esperar que cada equipo de aplicación aplique estos ajustes de forma coherente no es realista en grandes organizaciones.
La gestión de timeout también suele configurarse de forma incompleta. El idle timeout determina cuánto tiempo permanece abierta la sesión tras la última actividad; el absolute timeout, en cambio, limita la vida máxima desde el momento del login aunque el usuario esté activo. Especialmente en portales financieros, sanitarios y corporativos, estos dos límites deben gestionarse por separado.
El control de sesiones concurrentes no se resuelve por sí solo con el sistema de cookies estándar. Decisiones como desde cuántos dispositivos puede iniciar sesión un usuario, si un nuevo inicio debe cerrar la sesión antigua o si debe rechazarse el nuevo inicio, requieren un session store centralizado y un seguimiento de sesiones activas. En estructuras multi-nodo esto se vuelve aún más crítico.
La Protección de Sesión de TR7 reúne esta necesidad bajo un solo policy graph: la generación del session ID, los flags de seguridad de cookies, el binding IP / IP+UA / composite, el idle y absolute timeout, el máximo de sesiones concurrentes y el cifrado opcional de cookies se unen en el mismo modelo de gestión.
TR7 aplica la protección de sesión no como un solo ajuste de cookie, sino como una política multicapa que abarca desde la generación hasta la validación y desde la renovación hasta la finalización.
SAM gestiona conjuntamente session affinity, nombre de cookie, origen de cookie, formato de sesión y flags de seguridad. TR7 puede generar el session ID o trabajar con la cookie generada por el servicio backend; pueden usarse las opciones de formato UUID, IP+timestamp+random, IP+random o custom.
Una vez abierta la sesión, puede aplicarse uno de los modos de binding IP, IP+UA, composite o none. Cuando se detecta un cambio de contexto, se marca el session mismatch y la aplicación puede solicitar una nueva verificación o un control adicional.
Cuando se activa el cifrado de cookies basado en AES-256-CBC, las cookies seleccionadas se vuelven ilegibles en el lado del cliente. Gracias al binding adicional derivado del contexto IP+UA, se dificulta la reutilización del token en otro cliente.
La operación de session refresh se ejecuta de forma atómica con funciones Lua de Redis. El idle timeout puede renovarse en cada actividad; el absolute timeout permanece ligado al momento del login. El control de máximo de sesiones concurrentes también puede aplicarse sobre el session state centralizado.
La Protección de Sesión ofrece perfiles listos, opciones de binding, gestión de timeout y seguridad de cookies para distintas necesidades de seguridad y experiencia de usuario.
El perfil default está diseñado para el uso estándar corporativo con binding IP, 8 horas de idle timeout y 7 días de absolute timeout. El perfil session_strict aporta una seguridad más estricta con binding IP+UA, 30 minutos de idle, 8 horas de absolute timeout y una sola sesión concurrente. El perfil session_relaxed es adecuado para sesiones SaaS de larga duración, sin binding, con 7 días de idle y 90 días de absolute timeout. El perfil session_singleDevice se usa en aplicaciones que requieren restricción de licencia o de dispositivo, con binding IP y política de una sola sesión concurrente.
TR7 no fuerza el formato del session ID a un único modelo fijo. El formato ipTimestampRandom aporta el formato fuerte por defecto con la combinación de IP, tiempo y valor random; el formato uuid genera un valor opaco que no contiene IP. El formato ipRandom usa IP y un valor random; el formato custom permite al operador crear la clave de sesión a partir de header, cookie o variables personalizadas. Esta flexibilidad se adapta a distintas arquitecturas de aplicación.
En la capa SAM, HttpOnly puede configurarse como flag de seguridad mínimo. Flags adicionales como Secure, SameSite=Strict o SameSite=Lax también pueden añadirse a nivel de política. El valor Max-Age de la cookie puede asociarse al absolute timeout. Así no se espera que cada equipo de aplicación configure sin errores y por separado los ajustes de seguridad de cookies.
Cuando el valor samCookieSource es TR7, la cookie de sesión se genera en la capa ADC. Si el servicio backend va a seguir generando su propia cookie, puede usarse la cookie originada en el servicio backend. En el modelo híbrido, si existe la cookie del servicio backend se continúa con ese valor, y si no, TR7 puede crear un nuevo valor de sesión. Este enfoque se adapta tanto a aplicaciones nuevas como a sistemas antiguos.
El binding ip preserva el contexto de la IP de origen desde la que el usuario hizo login; es fuerte en escenarios de oficina corporativa o VPN. El binding ip+ua aporta un control más estricto al evaluar conjuntamente el par IP y User-Agent. El binding composite puede ampliarse con componentes adicionales como Accept-Language, header personalizado o TLS fingerprint. El modo none, en cambio, se comporta de forma más flexible en el uso SaaS con sesiones de larga duración y cambios frecuentes de red.
El cifrado de cookies no se asume activado por defecto; es una protección opcional que se habilita para las cookies seleccionadas. Cuando está activo, en el lado de la respuesta se aplica el flujo cookie_encrypt y en el lado de la solicitud cookie_decrypt. Usando salt, padding y formato base64 para cada cookie, el valor del lado del cliente se vuelve carente de significado. Cuando el descifrado falla, el valor no se trata como dato de sesión confiable y la aplicación puede decidir solicitar una nueva verificación o rechazar.
sessionIdleTimeout determina cuánto tiempo permanece válida la sesión tras la última actividad. sessionAbsoluteTimeout, en cambio, limita la vida máxima de la sesión desde el momento del login y no se prolonga continuamente con la actividad. Esta distinción es crítica especialmente en aplicaciones bancarias, portales corporativos y aplicaciones con datos sensibles. La experiencia de usuario y el límite de seguridad se equilibran en la misma política.
Con el valor maxConcurrentSessions se determina a cuántas sesiones activas puede tener acceso un usuario al mismo tiempo. Cuando se supera el límite, con logout_oldest puede cerrarse la sesión más antigua o con deny_new puede rechazarse el nuevo inicio. Esta estructura puede usarse para licencia de dispositivo único, seguridad bancaria o control de acceso corporativo. La lista de sesiones activas se rastrea sobre el session state centralizado.
Durante el login se crea la sesión, en cada request puede hacerse un idle refresh, cuando hay un binding mismatch la sesión se marca como sospechosa y durante el logout la sesión se invalida. Este ciclo de vida hace que la sesión se gestione no solo al inicio, sino durante todo el tiempo de uso. Los flujos de SIEM y auditoría pueden generar señales de seguridad a partir de estos eventos. El historial de sesión es importante especialmente en las investigaciones de toma de control de cuentas.
Para preservar el session state en múltiples nodos de TR7 pueden usarse conjuntamente la sincronización entre pares y un store centralizado basado en Redis. En escenarios de failover o rolling restart, el diseño se hace de modo que se preserve la continuidad de sesión. En el lado de Redis, con opciones de replication y persistencia puede aumentarse la resistencia del session state. Esta estructura impide que la protección de sesión quede atada a un solo nodo.
La protección de sesión se opera junto con el nombre de cookie, la generación de attribute, el composite binding, las categorías de auditoría, el session store y los comportamientos de fallback de timeout.
El nombre de cookie por defecto puede usarse como TR7SID. Para cada pool puede definirse un nombre distinto con samCookieName. Esto se usa para la coherencia de marca, el estándar de la aplicación o la compatibilidad con la arquitectura de cookies existente.
Al generar el valor de la cookie se añaden, según los ajustes de política, attributes como HttpOnly, Secure, SameSite y Max-Age. Estos attributes solo pueden establecerse cuando se genera una nueva sesión. Así la seguridad de cookies se estandariza con una política centralizada.
El composite binding puede establecerse por defecto con componentes como la IP de origen y el User-Agent. El operador puede incluir componentes adicionales como Accept-Language, Accept-Encoding, header personalizado o TLS fingerprint. Este cálculo debe hacerse en una etapa tardía, tras la generación de las variables correspondientes.
Los eventos de sesión y acceso pueden registrarse con categorías como whitelisted, authorized o unauthorized. Esta información facilita en el lado SIEM las investigaciones de toma de control de cuentas, abuso y acceso no autorizado. Para cada request, el contexto de usuario y sesión se vuelve más visible.
El session state de AAM puede mantenerse sobre Redis y las operaciones de session refresh se ejecutan de forma atómica con funciones Lua. Este modelo saca la latencia clásica de base de datos de la ruta de control de sesión. Con funciones de Redis como AOF y replication puede aumentarse la persistencia y la resistencia.
Si falta la configuración de idle timeout, puede usarse un fallback de 1 hora. Si falta el absolute timeout, puede aplicarse un valor de fallback de 24 horas. Estos valores aportan supuestos seguros que impiden la creación de sesiones ilimitadas cuando falta configuración.
Una aplicación bancaria puede querer mantener al usuario en un solo dispositivo y cerrar la sesión a los 30 minutos de inactividad. El perfil session_strict se aplica con binding IP+UA, 30 minutos de idle, 8 horas de absolute timeout y una sola sesión concurrente. Si una sesión robada se usa en otro contexto, se genera una señal de mismatch.
Los usuarios de SaaS B2B pueden querer acceder a la misma cuenta desde laptop, teléfono y tablet. El perfil session_relaxed preserva la experiencia de usuario sin binding, con valores largos de idle y absolute timeout. El cambio de IP o la diversidad de dispositivos no genera reverificaciones innecesarias.
En el portal del empleado, el usuario inicia sesión a través de la red de oficina o VPN y trabaja durante toda la jornada sin volver a hacer login. El perfil default puede aplicarse con binding IP, 8 horas de idle timeout y 7 días de absolute timeout. Si cambia el contexto de IP, la aplicación puede solicitar una nueva verificación.
Una aplicación premium o servicio con licencia puede querer que la cuenta se use en un solo dispositivo al mismo tiempo. El perfil session_singleDevice, con máx. 1 sesión concurrente y comportamiento logout_oldest, cierra la sesión antigua en el nuevo inicio. El uso compartido de licencia y el uso múltiple incontrolado se dificultan.
La generación del session ID, los flags de seguridad de cookies, el binding IP+UA, la política de timeout y el límite de sesiones concurrentes bajo un solo policy graph. Le hacemos un recorrido en una instalación en vivo con sus propios servicios.