Le session hijacking est un problème classique mais toujours critique. Lorsque le cookie de session de l'utilisateur est dérobé, l'attaquant tente de prendre le contrôle de la session avec le même token. Si le système ne regarde que la présence du token, il ne contrôle pas dans quel contexte d'IP, d'appareil, de navigateur ou d'utilisateur ce token a été généré. Dans ce cas, l'identifiant de session devient à lui seul la frontière de sécurité.
L'oubli des flags de sécurité des cookies est aussi une faiblesse répandue. Sans HttpOnly, les scripts côté client peuvent accéder au cookie ; sans Secure, la couche de transport s'affaiblit ; sans SameSite, les requêtes cross-site deviennent plus risquées. Attendre que ces réglages soient appliqués de manière cohérente par chaque équipe applicative n'est pas réaliste dans les grandes organisations.
La gestion des timeouts est elle aussi souvent mal mise en place. L'idle timeout détermine combien de temps la session reste ouverte après la dernière activité ; l'absolute timeout limite la durée de vie maximale depuis le moment de la connexion, même si l'utilisateur est actif. Notamment dans les portails de la finance, de la santé et de l'entreprise, ces deux limites doivent être gérées séparément.
Le contrôle des sessions concurrentes ne se résout pas spontanément avec un système de cookie standard. Combien d'appareils un utilisateur peut-il utiliser pour se connecter, une nouvelle connexion doit-elle faire tomber l'ancienne session ou la nouvelle connexion doit-elle être refusée — de telles décisions nécessitent un session store central et un suivi des sessions actives. Dans les structures multi-nœuds, cela devient encore plus critique.
La protection de session de TR7 réunit ce besoin sous un seul policy graph : la génération du session ID, les flags de sécurité des cookies, le binding IP / IP+UA / composite, les idle et absolute timeouts, le maximum de sessions concurrentes et le chiffrement de cookie optionnel convergent dans le même modèle de gestion.
TR7 applique la protection de session non pas comme un simple réglage de cookie, mais comme une politique multi-couche allant de la génération à la vérification, et du renouvellement à la terminaison.
SAM gère conjointement la session affinity, le nom du cookie, la source du cookie, le format de session et les flags de sécurité. TR7 peut générer le session ID ou fonctionner avec le cookie généré par le backend ; les options de format UUID, IP+timestamp+random, IP+random ou custom peuvent être utilisées.
Après l'ouverture de la session, l'un des modes de binding IP, IP+UA, composite ou none peut être appliqué. Lorsqu'un changement de contexte est détecté, un session mismatch est signalé et l'application peut demander une nouvelle authentification ou un contrôle supplémentaire.
Lorsque le chiffrement de cookie basé sur AES-256-CBC est activé, les cookies sélectionnés deviennent illisibles côté client. Grâce au binding supplémentaire dérivé du contexte IP+UA, la réutilisation du token sur un autre client est rendue plus difficile.
L'opération de session refresh est exécutée de manière atomique avec des fonctions Lua de Redis. L'idle timeout peut être renouvelé à chaque activité ; l'absolute timeout reste lié au moment de la connexion. Le contrôle des sessions concurrentes maximales peut aussi être appliqué via le session state central.
La protection de session offre des profils prêts à l'emploi, des options de binding, une gestion des timeouts et une sécurité des cookies pour différents besoins de sécurité et d'expérience utilisateur.
Le profil default est conçu pour un usage standard d'entreprise avec un binding IP, un idle timeout de 8 heures et un absolute timeout de 7 jours. Le profil session_strict offre une sécurité plus stricte avec un binding IP+UA, 30 minutes d'idle, 8 heures d'absolute timeout et une seule session concurrente. Le profil session_relaxed convient aux sessions SaaS de longue durée, sans binding, avec 7 jours d'idle et 90 jours d'absolute timeout. Le profil session_singleDevice s'utilise dans les applications nécessitant une restriction de licence ou d'appareil, avec un binding IP et une politique de session concurrente unique.
TR7 n'impose pas le format du session ID à un seul modèle fixe. Le format ipTimestampRandom fournit le format fort par défaut avec une combinaison d'IP, de temps et de valeur aléatoire ; le format uuid produit une valeur opaque ne contenant pas d'IP. Le format ipRandom utilise une IP et une valeur aléatoire ; le format custom permet à l'opérateur de créer une clé de session à partir de headers, de cookies ou de variables personnalisées. Cette flexibilité s'adapte à différentes architectures applicatives.
Au niveau de la couche SAM, HttpOnly peut être configuré comme flag de sécurité minimal. Des flags supplémentaires comme Secure, SameSite=Strict ou SameSite=Lax peuvent aussi être ajoutés au niveau de la politique. La valeur Max-Age du cookie peut être associée à l'absolute timeout. Ainsi, on n'attend pas de chaque équipe applicative qu'elle effectue séparément et sans erreur ses réglages de sécurité de cookie.
Lorsque la valeur samCookieSource est TR7, le cookie de session est généré au niveau de la couche ADC. Si le backend doit continuer à générer son propre cookie, le cookie issu du backend peut être utilisé. Dans le modèle hybride, si le cookie du backend existe on continue avec cette valeur, sinon TR7 peut créer une nouvelle valeur de session. Cette approche s'adapte aussi bien aux nouvelles applications qu'aux anciens systèmes.
Le binding ip préserve le contexte d'IP source où l'utilisateur s'est connecté ; il est fort dans les scénarios de bureau d'entreprise ou de VPN. Le binding ip+ua évalue conjointement la paire IP et User-Agent pour un contrôle plus strict. Le binding composite peut être étendu avec des composantes supplémentaires comme Accept-Language, un header personnalisé ou un TLS fingerprint. Le mode none se comporte de manière plus flexible dans un usage SaaS à session longue et à changements de réseau fréquents.
Le chiffrement de cookie n'est pas considéré comme activé par défaut ; c'est une protection optionnelle activée pour les cookies sélectionnés. Lorsqu'il est actif, le flux cookie_encrypt s'applique côté réponse et cookie_decrypt côté requête. Pour chaque cookie, l'utilisation d'un salt, d'un padding et d'un formatage base64 rend la valeur côté client dénuée de sens. Lorsque le déchiffrement échoue, la valeur n'est pas traitée comme une donnée de session fiable et l'application peut décider d'une nouvelle authentification ou d'un refus.
sessionIdleTimeout détermine combien de temps la session reste valide après la dernière activité. sessionAbsoluteTimeout limite la durée de vie maximale de la session depuis le moment de la connexion et ne s'allonge pas continuellement avec l'activité. Cette distinction est particulièrement critique dans les applications bancaires, les portails d'entreprise et les applications contenant des données sensibles. L'expérience utilisateur et la frontière de sécurité sont équilibrées dans la même politique.
La valeur maxConcurrentSessions détermine combien de sessions actives un utilisateur peut posséder simultanément. Lorsque la limite est dépassée, la session la plus ancienne peut être abandonnée avec logout_oldest, ou la nouvelle connexion refusée avec deny_new. Cette structure peut être utilisée pour la licence d'appareil unique, la sécurité bancaire ou le contrôle d'accès d'entreprise. La liste des sessions actives est suivie via le session state central.
Lors de la connexion, la session est créée, à chaque requête un idle refresh peut être effectué, lors d'un binding mismatch la session est marquée comme suspecte, et lors du logout la session est invalidée. Ce cycle de vie permet de gérer la session non seulement au début mais pendant toute la durée d'usage. Les flux SIEM et d'audit peuvent produire un signal de sécurité à partir de ces événements. L'historique de session est particulièrement important dans les investigations de compromission de compte.
Pour préserver le session state sur plusieurs nœuds TR7, la synchronisation des pairs et un store central basé sur Redis peuvent être utilisés ensemble. La conception est faite pour que la continuité de session soit préservée dans les scénarios de failover ou de rolling restart. Côté Redis, la résilience du session state peut être renforcée avec les options de replication et de persistance. Cette structure empêche la protection de session de rester liée à un seul nœud.
La protection de session est exploitée conjointement avec le nom du cookie, la génération des attributs, le binding composite, les catégories d'audit, le session store et les comportements de fallback de timeout.
Le nom de cookie par défaut TR7SID peut être utilisé. Un nom différent peut être défini pour chaque pool avec samCookieName. Cela s'utilise pour la cohérence de marque, le standard applicatif ou la compatibilité avec une architecture de cookie existante.
Lors de la création de la valeur du cookie, des attributs tels que HttpOnly, Secure, SameSite et Max-Age sont ajoutés selon les réglages de politique. Ces attributs ne peuvent être définis que lorsqu'une nouvelle session est générée. Ainsi, la sécurité des cookies est standardisée par une politique centrale.
Le binding composite peut être établi par défaut avec des composantes comme l'IP source et le User-Agent. L'opérateur peut inclure des composantes supplémentaires comme Accept-Language, Accept-Encoding, un header personnalisé ou un TLS fingerprint. Ce calcul doit être effectué à une étape tardive, après que les variables concernées ont été générées.
Les événements de session et d'accès peuvent être journalisés avec des catégories comme whitelisted, authorized ou unauthorized. Cette information facilite côté SIEM les investigations de compromission de compte, d'abus et d'accès non autorisé. Pour chaque requête, le contexte utilisateur et de session devient plus visible.
Le session state AAM peut être conservé sur Redis et les opérations de session refresh sont exécutées de manière atomique avec des fonctions Lua. Ce modèle sort la latence classique des bases de données du chemin de contrôle de session. La persistance et la résilience peuvent être renforcées avec des fonctionnalités Redis comme AOF et replication.
Si la configuration de l'idle timeout est absente, un fallback d'1 heure peut être utilisé. Si l'absolute timeout est absent, une valeur de fallback de 24 heures peut être appliquée. Ces valeurs fournissent des hypothèses sécurisées qui empêchent la création de sessions illimitées lorsque la configuration est incomplète.
Une application bancaire peut vouloir maintenir l'utilisateur sur un seul appareil et fermer la session après 30 minutes d'inactivité. Le profil session_strict est appliqué avec un binding IP+UA, 30 minutes d'idle, 8 heures d'absolute timeout et une seule session concurrente. Si une session volée est utilisée dans un contexte différent, un signal de mismatch est produit.
Les utilisateurs SaaS B2B peuvent vouloir accéder au même compte depuis un ordinateur portable, un téléphone et une tablette. Le profil session_relaxed préserve l'expérience utilisateur avec de longues valeurs d'idle et d'absolute timeout, sans binding. Le changement d'IP ou la diversité des appareils ne produit pas de nouvelle authentification inutile.
Dans le portail des employés, l'utilisateur se connecte via le réseau du bureau ou le VPN et travaille toute la journée sans se reconnecter. Le profil default peut être appliqué avec un binding IP, un idle timeout de 8 heures et un absolute timeout de 7 jours. Si le contexte d'IP change, l'application peut demander une nouvelle authentification.
Une application premium ou un service sous licence peut vouloir que le compte soit utilisé sur un seul appareil à la fois. Le profil session_singleDevice fait tomber l'ancienne session lors d'une nouvelle connexion, avec un maximum de 1 session concurrente et le comportement logout_oldest. Le partage de licence et l'usage multiple incontrôlé deviennent difficiles.
La génération du session ID, les flags de sécurité des cookies, le binding IP+UA, la politique de timeout et la limite de sessions concurrentes sous un seul policy graph. Nous vous guidons dans une installation en direct avec vos propres services.