Qu'est-ce que la fixation de session ?
La fixation de session est une vulnérabilité des applications web qui permet à un attaquant de détourner une session utilisateur valide en exploitant une mauvaise gestion des identifiants de session. Le défaut principal est simple : lorsque l'utilisateur s'authentifie, l'application n'attribue pas un nouvel identifiant de session. Cela signifie qu'un attaquant qui connaît ou contrôle l'identifiant de session avant l'authentification peut l'utiliser pour accéder à la session authentifiée comme s'il était l'utilisateur légitime.
MITRE CWE définit formellement la faiblesse : « Authentifier un utilisateur, ou établir une nouvelle session utilisateur, sans invalider un identifiant de session existant donne à un attaquant l'opportunité de voler des sessions authentifiées. » Pour vous, le résultat est une prise de contrôle quasi totale du compte, souvent sans que la victime ne s'en rende compte.
La fixation de session est distincte du détournement de session, bien que les deux soient parfois confondus. OWASP trace la frontière clairement : la fixation de session commence avant que la victime ne se connecte, tandis que le détournement de session se produit après qu'une session authentifiée active existe déjà. Dans une attaque de fixation, l'attaquant connaît déjà l'identifiant de session car il l'a défini. Dans une attaque de détournement, l'attaquant doit capturer ou prédire l'identifiant de session d'une session active.
| Attribut | Fixation de session | Détournement de session |
| Moment de l'attaque | Avant l'authentification de la victime | Après l'authentification de la victime |
| Connaissance de l'ID de session | L'attaquant définit ou connaît l'ID à l'avance | L'attaquant doit capturer ou prédire l'ID |
| Contre-mesure principale | Régénération de l'ID de session à la connexion | Chiffrement du jeton, transmission sécurisée |
Cette distinction est importante pour vos contrôles de sécurité. Si votre application régénère les IDs de session après la connexion, vous bloquez les attaques de fixation. Si elle ne fait qu'encrypter les jetons de session en transit, vous traitez le détournement mais laissez la fixation totalement possible. Comprendre le fonctionnement mécanique de l'attaque montre pourquoi cette différence est si critique.
Comment fonctionne la fixation de session ?
La fixation de session suit un déroulement d'attaque en quatre étapes, documenté à la fois par MITRE CWE et OWASP WSTG.
- Étape 1 : Acquisition de session. L'attaquant visite l'application cible et reçoit un identifiant de session valide avant authentification. Par exemple, le serveur peut retourner
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1. Dans les applications utilisant un mécanisme permissif d'acceptation de session, l'attaquant peut fournir une valeur d'identifiant de session arbitraire que l'application acceptera sans vérification. - Étape 2 : Livraison de session. L'attaquant transmet l'identifiant de session connu à la victime. Cette livraison peut se faire via une URL forgée, une charge utile XSS, une balise META injectée ou un découpage de réponse HTTP. L'objectif est simple : faire en sorte que le navigateur de la victime envoie l'identifiant de session contrôlé par l'attaquant lors de l'accès à l'application cible.
- Étape 3 : Authentification de la victime. La victime clique sur le lien forgé ou accède à l'application via le mécanisme de livraison de l'attaquant et se connecte normalement. L'application valide les identifiants et accorde l'accès. Mais elle ne régénère pas l'identifiant de session après la connexion réussie, continuant d'utiliser le même identifiant déjà connu de l'attaquant.
- Étape 4 : Prise de contrôle du compte. L'attaquant envoie des requêtes à l'application en utilisant l'identifiant de session connu. Le serveur traite ces requêtes comme provenant de la victime authentifiée. MITRE note que cela offre « un accès presque illimité au compte de la victime pendant toute la durée de la session. »
Au-delà des quatre étapes principales, la fixation de session peut être réalisée par plusieurs méthodes distinctes selon l'accès de l'attaquant et la configuration de l'application cible.
Cinq vecteurs d'attaque principaux
- Injection de paramètre d'URL est le vecteur le plus simple. L'attaquant intègre l'identifiant de session comme paramètre de requête dans l'URL et transmet le lien par hameçonnage ou email :
https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner classe « Session token in URL » comme CWE-384. - Injection de cookie via XSS utilise du JavaScript exécuté dans le navigateur de la victime pour définir le cookie de session :
document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE confirme que le cross-site scripting est l'une des deux principales techniques de livraison des charges de fixation de session. - Injection de balise META implante une balise HTML qui ordonne au navigateur de définir un cookie :
<meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP note que cette approche est plus difficile à contrer que l'injection JavaScript car « il est impossible de désactiver le traitement de ces balises dans les navigateurs. » - Injection d'en-tête de réponse HTTP exploite des vulnérabilités de découpage de réponse pour injecter un en-tête
Set-Cookiedirectement dans une réponse du serveur, implantant l'identifiant de session contrôlé sans aucun script côté client. - Fixation de cookie inter-sous-domaines exploite les architectures de domaines partagés. MITRE documente directement ce cas : si
bank.example.cometrecipes.example.compartagent le même domaine de niveau supérieur, une vulnérabilité dans l'application recipes peut fixer un identifiant de session qui sera utilisé sur toutes les applications deexample.com. La diversité des vecteurs de livraison explique pourquoi la fixation de session est encore présente dans les systèmes en production.
Causes de la fixation de session
Les causes profondes de la fixation de session sont bien documentées, et chacune représente une faille que vous et votre équipe de développement pouvez corriger.
Échec de régénération des IDs de session après authentification
C'est la cause principale, citée par toutes les sources faisant autorité dans l'article. Le guide OWASP l'énonce clairement : « Lorsqu'une application ne renouvelle pas son ou ses cookies de session après une authentification utilisateur réussie, il peut être possible de trouver une vulnérabilité de fixation de session. »
La fiche OWASP précise que la régénération de l'ID de session est obligatoire lors de la connexion, des changements de mot de passe, des changements de niveau d'autorisation et des transitions de rôle. Le CVE-2022-24895 documente que la stratégie de migration de session NONE de Symfony conserve la même session après authentification, permettant les attaques de fixation, et porte une sévérité ÉLEVÉE.
Acceptation permissive des IDs de session
La Session Management Cheat Sheet d'OWASP définit deux mécanismes de gestion des IDs de session. Un mécanisme permissif accepte toute valeur d'ID de session définie par l'utilisateur comme valide et crée une nouvelle session pour celle-ci. Un mécanisme strict n'accepte que les IDs de session générés préalablement par l'application. Si votre application utilise le mécanisme permissif, vous permettez aux attaquants d'implanter des valeurs arbitraires sans obtenir d'abord un ID émis par le serveur.
Identifiants de session prévisibles
MITRE identifie les identifiants de session prévisibles comme une condition contributive, liée à CWE-340 (Génération de nombres ou d'identifiants prévisibles). Lorsque les IDs de session suivent des schémas ou utilisent une faible entropie, les attaquants peuvent prédire des valeurs valides sans avoir besoin d'en obtenir une du serveur.
Périmètre de domaine de cookie permissif
Définir l'attribut de cookie Domain sur un domaine de niveau supérieur, par exemple Domain=example.com au lieu de Domain=app.example.com, fait que les cookies sont transmis à tous les sous-domaines. Une vulnérabilité sur un seul sous-domaine devient un point d'entrée de fixation pour toutes les applications de ce domaine.
Transition HTTP vers HTTPS sans régénération de session
OWASP WSTG-SESS-03 identifie ce scénario spécifique : les sites qui émettent un identifiant de session via HTTP puis redirigent vers un formulaire de connexion HTTPS, sans réémettre l'ID de session après authentification, exposent l'ID pré-authentification à l'écoute réseau. L'attaquant capture l'ID sur la connexion non sécurisée et attend que la victime s'authentifie. Ces causes apparaissent rarement isolément, et comprendre comment la communauté des standards les classe formellement vous aide à communiquer et à prioriser la remédiation.
Classification OWASP de la fixation de session
La fixation de session est formellement classée dans trois systèmes de standards faisant autorité : le Common Weakness Enumeration de MITRE, l'OWASP Top 10 et l'OWASP Web Security Testing Guide. Sous OWASP A07, elle se situe dans la catégorie des échecs d'authentification aux côtés de faiblesses connexes partageant le même périmètre de remédiation. Chaque classification cible un public différent et implique une action différente.
CWE-384 : identifiant formel de faiblesse
MITRE CWE-384 est la classification principale pour la fixation de session, définissant la faiblesse comme l'authentification d'un utilisateur sans invalider l'identifiant de session existant. Son profil dans la taxonomie MITRE :
- Type de faiblesse : Faiblesse de base dans la catégorie des identifiants de session
- Conséquences courantes : Prise de privilèges ou usurpation d'identité de la victime ; prise de contrôle complète du compte pendant la durée de la session
- Probabilité d'exploitation : Moyenne — nécessite la livraison d'un ID de session connu à la victime avant la connexion
- Périmètre de plateforme : Indépendant du langage ; s'applique quel que soit le stack ou le framework web
- Statut CWE Top 25 : Entré dans le Top 25 en 2019 ; reste une faiblesse suivie activement dans l'édition 2023
Ces propriétés font de CWE-384 un signal cohérent pour les scanners de vulnérabilités et les cadres d'évaluation, où il correspond directement aux cas de test ciblant la gestion du cycle de vie des sessions.
OWASP Top 10 et standards de test
CWE-384 correspond à A07:2025 — Échecs d'authentification dans l'OWASP Top 10. Cette classification a une implication importante : la fixation de session est traitée comme un échec de contrôle d'authentification, et non comme une mauvaise configuration de cookie. Cette distinction la place au cœur des revues de flux de connexion et du renforcement de l'authentification, et non seulement des audits de configuration de cookies.
| Référence | Système | Objectif |
| MITRE CWE | Suivi formel des faiblesses ; utilisé par les outils SAST/DAST et les enregistrements CVE | |
| OWASP Top 10 | Signal de priorisation du risque ; cible la revue sur les contrôles d'authentification | |
| OWASP WSTG | Procédure de test en boîte noire et critères de réussite/échec faisant autorité | |
| OWASP CheatSheets | Référence de prévention pour développeurs sur la régénération, le périmètre des cookies et le mode strict |
Ensemble, ces quatre références vous donnent le vocabulaire, les cas de test et les conseils de remédiation pour traiter la fixation de session dans tout programme de sécurité existant. Avec ce contexte de classification, il est utile d'examiner ce qui se passe réellement lors d'une exploitation réussie de la vulnérabilité.
Impact et risque de la fixation de session
La fixation de session permet une prise de contrôle complète du compte pendant toute la durée de la session compromise. Une fois qu'un attaquant détient un identifiant de session authentifié, il opère avec tous les privilèges de la victime : lecture de données sensibles, initiation de transactions, modification des paramètres du compte et escalade d'accès si la victime possède des droits administratifs.
Classification et sévérité OWASP
CWE-384 relève de OWASP A07. La catégorie A07:2025 affiche un score moyen pondéré d'exploitabilité de 7,69, correspondant à 7 147 CVE totaux sur les applications testées. Le nombre total de CVE associés à la catégorie A07 a également augmenté entre les éditions 2021 et 2025, reflétant une expansion plutôt qu'une contraction de la surface d'attaque.
Plage de scores CVSS
Les CVE de fixation de session confirmés couvrent une plage allant de Moyenne à Critique. Les cas les plus graves impliquent généralement des scénarios où la fixation permet une prise de contrôle de compte non authentifiée dans des plugins ou frameworks d'authentification largement déployés. Une nuance importante pour vous en tant que praticien : les CVE de fixation de session présentent fréquemment des écarts de score entre le NIST NVD et les CNA des éditeurs. Par exemple, CVE-2019-17563 (Apache Tomcat) a reçu une note CRITIQUE du NIST mais une évaluation « Faible » d'Apache, qui a décrit la fenêtre d'exploitation comme « trop étroite pour qu'une exploitation soit pratique. »
Facteurs de risque aggravants
La fixation de session est rarement un risque isolé. CVE-2024-56529 (Mailcow) montre que l'attaque réussit spécifiquement lorsque HSTS est désactivé sur le navigateur de la victime. Un article de Microsoft Research présenté à l'IEEE S&P 2015 a documenté que l'injection de cookie pouvait contourner les défenses standard de régénération de session sur des sites web réels. Lorsque les contrôles de défense en profondeur échouent simultanément, une vulnérabilité de fixation de session peut rapidement s'aggraver. La question de qui est vulnérable va au-delà des seules applications web.
Comment les attaquants exploitent la fixation de session
Les attaquants exploitent la fixation de session à travers des scénarios allant du phishing ciblé à l'empoisonnement opportuniste de session.
Injection d'URL basée sur le phishing
L'attaquant forge une URL contenant un identifiant de session connu et la transmet via phishing ou ingénierie sociale. L'URL paraît légitime car elle pointe vers le vrai domaine de l'application. La victime clique sur le lien, se connecte normalement et authentifie sans le savoir une session contrôlée par l'attaquant. C'est le scénario le plus courant pour la transmission d'ID de session via URL.
Exploitation de terminal public
MITRE CWE-384 documente un scénario canonique : un attaquant crée une session depuis un terminal public, enregistre l'identifiant de session, réinitialise le navigateur sur la page de connexion et attend que le prochain utilisateur s'authentifie. L'application continue d'utiliser l'ID de session préexistant, donnant à l'attaquant « un accès presque illimité au compte de la victime pendant toute la durée de la session. »
Empoisonnement de session non ciblé
CVE-2022-30769 (ZoneMinder) a démontré une attaque où un attaquant pouvait « empoisonner un cookie de session pour le prochain utilisateur qui se connecte ». Cela ne nécessitait pas de cibler un individu spécifique. La session empoisonnée était héritée par quiconque s'authentifiait ensuite. Dans les environnements à accès partagé comme les plateformes de surveillance, ce schéma est particulièrement dangereux.
Exploitation de condition de concurrence
CVE-2013-2067 (Apache Tomcat) a révélé une condition de concurrence dans l'authentification FORM. En envoyant de façon répétée des requêtes pour des ressources authentifiées pendant qu'une victime remplissait le formulaire de connexion, un attaquant pouvait injecter une requête exécutée avec les identifiants de la victime. Apache a classé cela comme de sévérité « Importante ».
Attaques inter-sous-domaines
Dans les architectures multi-applications partageant un domaine de niveau supérieur, les attaquants exploitent une application peu sécurisée pour fixer un cookie de session au niveau du domaine parent. Toutes les autres applications de ce domaine acceptent alors l'ID de session fixé. Ce scénario est courant dans les environnements d'entreprise exécutant plusieurs outils internes sur un domaine partagé. Savoir qui est concerné vous aide à prioriser la recherche de ces vulnérabilités.
Qui est concerné par la fixation de session ?
La fixation de session concerne toute application qui gère des sessions utilisateur via des identifiants et ne les régénère pas lors de l'authentification. Les enregistrements CVE et la documentation MITRE pointent plusieurs catégories structurellement à haut risque.
- Applications web utilisant des identifiants de session dans l'URL sont les plus exposées. La transmission de session via URL permet aux attaquants de fournir un ID de session contrôlé via un lien forgé sans vulnérabilité supplémentaire requise.
- Écosystèmes CMS et plugins d'authentification sont régulièrement affectés. CVE-2024-13279 (Drupal TFA, selon CISA), CVE-2010-1434 (Joomla!), CVE-2012-5391 (MediaWiki) et CVE-2019-8116 (Magento) montrent que les modules d'authentification ajoutés aux plateformes CMS introduisent un risque critique de fixation de session si la régénération n'est pas appliquée.
- Applications J2EE/Java EE présentent l'une des séries de CVE les plus documentées. Apache Tomcat à lui seul compte des CVE de 2013 à 2025, dont CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563 et CVE-2025-55668.
- Architectures multi-applications à domaine partagé sont vulnérables par conception. Les plateformes SaaS à sous-domaines locataires et les portefeuilles applicatifs d'entreprise partageant un domaine de niveau supérieur présentent un risque de fixation inter-sous-domaines, comme documenté par MITRE.
- Plateformes ICS/SCADA représentent une surface de risque émergente. CVE-2025-70973 (ScadaBR 1.12.4, divulgué en mars 2026) montre la fixation de session dans des plateformes de systèmes de contrôle industriel, en cohérence avec les correspondances de catégorie ICS de CWE-384 vers CWE-1364 (ICS Communications : Zone Boundary Failures) et CWE-1366 (ICS Communications : Frail Security in Protocols).
- Plateformes de workflow d'entreprise présentent également une exposition documentée. CVE-2022-38369 (Apache IoTDB) et CVE-2022-38054 (Apache Airflow) montrent que les outils d'automatisation de workflow ne sont pas immunisés. L'étendue des catégories concernées rend les études de cas réelles utiles pour comprendre comment ces vulnérabilités apparaissent en pratique.
Exemples réels de fixation de session
La fixation de session a été confirmée sur un large éventail de systèmes en production, des frameworks Java d'entreprise aux plateformes de contrôle industriel. Les exemples ci-dessous illustrent comment la même faille sous-jacente se manifeste différemment selon l'environnement.
Condition de concurrence FORM d'Apache Tomcat (CVE-2013-2067)
Cela reste le CVE de fixation de session Tomcat le plus impactant, classé « Important » par Apache. Affectant Tomcat 6.0.21 à 6.0.36 et 7.0.0 à 7.0.32, la vulnérabilité exploitait une condition de concurrence dans l'authentification FORM. Un attaquant pouvait envoyer de façon répétée des requêtes pour des ressources authentifiées pendant qu'une victime remplissait le formulaire de connexion, injectant une requête exécutée avec les identifiants de la victime. L'ironie est que l'option de changement d'ID de session à l'authentification avait été ajoutée dans Tomcat 6.0.21. Ce CVE représentait un bug dans la propre protection contre la fixation de Tomcat.
Contournement du jeton CSRF du framework Symfony (CVE-2022-24895)
Les versions 2.0.0 à 6.2.5 de Symfony étaient affectées par une vulnérabilité de sévérité ÉLEVÉE. Le framework régénérait l'ID de session à la connexion mais conservait les autres attributs de session, y compris les jetons CSRF. Cette régénération partielle permettait à des attaquants same-site de contourner la protection CSRF via une variante de fixation de session. La leçon est claire : régénérer uniquement l'ID de session ne suffit pas. Une invalidation et une réémission complètes de la session sont nécessaires.
Système de contrôle industriel ScadaBR (CVE-2025-70973)
Divulguée en mars 2026, cette vulnérabilité dans ScadaBR 1.12.4 suit le schéma canonique de fixation de session. L'application attribue un cookie de session JSESSIONID aux utilisateurs non authentifiés et ne régénère pas l'identifiant de session après authentification réussie. Une session créée avant la connexion devient authentifiée une fois la victime connectée. Ce CVE est notable car il montre un risque actif de fixation de session dans les environnements ICS/SCADA.
Empoisonnement de session non ciblé ZoneMinder (CVE-2022-30769)
ZoneMinder 1.36.12 et versions antérieures permettait à un attaquant d'empoisonner un cookie de session qui serait hérité par le prochain utilisateur à s'authentifier. Cela ne nécessitait pas de cibler une victime spécifique, ce qui est particulièrement dangereux dans les environnements de surveillance à accès partagé où plusieurs opérateurs utilisent la même plateforme.
Adoption de session PHP (CVE-2011-4718)
Le module de session PHP était « adoptif », c'est-à-dire qu'il acceptait les IDs de session provenant de sources externes. Le RFC PHP indiquait que « l'utilisation de session_regenerate_id() NE PEUT PAS empêcher l'adoption/la fixation de session » sans activer également session.use_strict_mode. PHP 5.5.2 a introduit session.use_strict_mode comme correctif, mais même avec le mode strict activé, les gestionnaires de sauvegarde personnalisés pouvaient rester vulnérables. L'historique complet de ces incidents montre la persistance de cette classe de vulnérabilité.
Chronologie et historique de la fixation de session
La fixation de session est documentée formellement depuis 2002, et les enregistrements CVE montrent qu'elle reste active dans les nouveaux comme les anciens codes. La chronologie ci-dessous retrace les principaux événements de divulgation et les réponses au niveau des frameworks.
| Année | Événement |
| Déc 2002 | Mitja Kolšek (ACROS Security) publie « Session Fixation Vulnerability in Web-based Applications », nommant formellement la fixation de session comme une quatrième classe d'attaque contre les identifiants de session |
| 2006 | CVE-2006-1228 (Drupal 4.5.x/4.6.x) : fixation d'ID de session via URL |
| Juil 2006 | MITRE ajoute CWE-384 au Common Weakness Enumeration (Draft 3) |
| Fév 2008 | Oracle/BEA WebLogic Server advisory BEA08-196.00 : fixation de session permettant l'escalade de privilèges |
| 2009 | CVE-2009-1580 (SquirrelMail) ; Black Hat USA documente CWE-384 dans les communautés de trackers BitTorrent |
| 2010 | CVE-2010-1434 (Joomla! 1.5.0 à 1.5.15) : CVSS 7.5 ÉLEVÉ |
| Déc 2011 | CVE-2011-4718 (adoption de session PHP) : affecte PHP 5.0.0 à 5.5.1 |
| Mai 2013 | CVE-2013-2067 (Apache Tomcat 6.x, 7.x) : condition de concurrence FORM, sévérité « Importante » Apache |
| 2015 | Microsoft Research (IEEE S&P) documente l'injection de cookie contournant les défenses de régénération de session largement adoptées |
| 2019 | CWE-384 entre dans le Top 25 |
| Déc 2019 | CVE-2019-17563 (Apache Tomcat) : NIST 9.8 CRITIQUE vs. Apache « Faible » |
| 2022 | CVE-2022-24895 (Symfony) : contournement de régénération partielle |
| Jan 2025 | CVE-2024-56529 (Mailcow) : fixation de session lorsque HSTS est désactivé |
| Août 2025 | CVE-2025-55668 (Apache Tomcat 9.x/10.x/11.x) : CVSS 6.5 MODÉRÉ |
| Mars 2026 | CVE-2025-70973 (ScadaBR 1.12.4) et CVE-2026-25101 (Bludit) : de nouveaux CVE confirment que la classe de vulnérabilité reste active |
La chronologie s'étend sur plus de deux décennies sans signe de ralentissement. La fixation de session n'est pas une vulnérabilité historique. Elle continue d'apparaître dans les nouveaux comme les anciens codes, des frameworks d'entreprise aux plateformes ICS. Si vous savez comment auditer vos propres applications, vous pouvez passer à l'étape suivante.
Comment détecter la fixation de session
La fixation de session est l'une des vulnérabilités les plus simples à confirmer : le test principal consiste simplement à capturer un identifiant de session avant la connexion, à s'authentifier, puis à comparer la valeur après. Les approches suivantes couvrent la vérification manuelle, l'inspection des attributs de cookie, le scan automatisé et l'identification au niveau WAF.
Test d'intrusion manuel (OWASP WSTG-SESS-03)
La procédure de test faisant autorité provient du OWASP WSTG. Pour vous, le test en boîte noire est simple.
- Capturez l'ID de session pré-authentification. Visitez l'application et enregistrez la valeur du cookie de session
(ex. : JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1). - Authentifiez-vous en présentant l'ID de session capturé. Soumettez des identifiants valides avec le cookie de session original joint.
- Comparez les valeurs d'ID de session. Si le serveur retourne le même ID de session après authentification réussie, l'application est vulnérable.
Pour les applications sans adoption HSTS complète, WSTG-SESS-03 décrit une seconde stratégie : forcez tous les cookies non fraîchement émis après connexion dans le navigateur de la victime depuis une machine distincte, puis vérifiez si ces cookies donnent accès à la session de la victime après authentification.
Vérification des attributs de cookie
Vérifiez les indicateurs de renforcement dans vos cookies de session. Le préfixe __Host- offre une intégrité contre la fixation de session basée sur le réseau. Le préfixe __Secure- indique un renforcement partiel. Exécutez WSTG-SESS-03 pour vérifier que les attributs HttpOnly, Secure et SameSite sont correctement configurés.
Scan DAST
OWASP ZAP propose des modes de scan actif et passif avec prise en charge de la gestion de session, y compris la gestion des cookies, des jetons et d'autres mécanismes. L'analyse de ZAP sur la gestion de session et l'application de l'authentification vous aide à trouver des failles d'authentification et des bugs de fixation de session. Burp Suite Professional couvre les workflows de test de gestion de session, fonctionnant comme un scanner dynamique de vulnérabilités web applicable à la gestion de session.
Identification basée sur le WAF
La fiche OWASP identifie ModSecurity combiné à l'OWASP Core Rule Set comme fournissant des contre-mesures contre les attaques de fixation de session. Cette approche WAF est recommandée lorsque le code source n'est pas disponible, ne peut pas être modifié, ou lorsque la mise en œuvre de correctifs applicatifs complets nécessiterait une refonte importante. Un audit efficace doit mener directement à la prévention, et les contrôles requis sont bien définis.
Comment prévenir la fixation de session
La prévention repose sur une exigence non négociable : l'application doit émettre un nouvel ID de session à chaque événement d'authentification et rejeter tout identifiant de session qui n'a pas été généré par le serveur lui-même. Les contrôles ci-dessous répondent à cette exigence au niveau applicatif, framework, configuration des cookies et architecture réseau.
Contrôles au niveau applicatif
- Régénérez les IDs de session après authentification. C'est le contrôle le plus important. OWASP WSTG-SESS-03 énonce clairement l'exigence : « l'application doit toujours d'abord invalider l'ID de session existant avant d'authentifier un utilisateur, et si l'authentification réussit, fournir un autre ID de session. » La régénération est obligatoire à chaque changement de niveau de privilège, y compris la connexion, les changements de mot de passe, de permissions et de rôle.
- Utilisez une gestion stricte des sessions. Configurez votre application pour n'accepter que les IDs de session générés par le serveur. Rejetez les valeurs d'ID de session arbitraires soumises par les clients. PHP a introduit session.use_strict_mode en version 5.5.2 précisément à cet effet.
- Invalidez complètement les sessions. CVE-2022-24895 (Symfony) a prouvé que la régénération partielle de session n'est pas suffisante. Régénérer l'ID de session tout en conservant d'autres attributs comme les jetons CSRF crée une vulnérabilité résiduelle. Une invalidation et une réémission complètes de la session sont nécessaires.
Mise en œuvre spécifique au framework
| Framework | Invalider la session existante | Créer une nouvelle session |
| J2EE | HttpSession.invalidate() | request.getSession(true) |
| ASP.NET | Session.Abandon() | Response.Cookies.Add(new HttpCookie(...)) |
| PHP | session_start() | session_regenerate_id(true) |
Spring Security protège automatiquement contre la fixation de session en créant une nouvelle session ou en changeant l'ID de session lors de la connexion d'un utilisateur. Quatre stratégies configurables sont disponibles : changeSessionId() (recommandé), migrateSession(), newSession(), et none() (non recommandé).
Configuration de la sécurité des cookies
Respectez les exigences de NIST SP 800-63B :
- Le drapeau
Secure: DOIT être activé (cookies transmis uniquement via HTTPS) DomainetPath: DOIVENT être restreints au périmètre minimal nécessaire- Le drapeau
HttpOnly: DEVRAIT être activé (empêche l'accès JavaScript) SameSite=LaxouStrict: DEVRAITêtre activé (selon NIST SP 800-63B v4 draft)- Le préfixe
__HostavecPath=/:DEVRAIT être activé (selon NIST SP 800-63B v4 draft)
L'application combinée de ces drapeaux prévient la plupart des scénarios courants de fixation de session via le réseau ou inter-sites et élève significativement le niveau de difficulté pour tout attaquant tentant l'injection de cookie.
Contrôles au niveau de l'architecture
Ne mélangez pas des applications de niveaux de sécurité différents sur le même domaine. Mettez en œuvre le HSTS complet incluant les sous-domaines pour contrer la fixation basée sur le réseau. Déployez ModSecurity avec l'OWASP Core Rule Set pour une protection WAF lorsque les changements applicatifs ne sont pas immédiatement possibles. La prévention et l'audit fonctionnent mieux avec les bons outils.
Outils de détection et de prévention
L'identification et la neutralisation de la fixation de session nécessitent des outils sur trois couches : des scanners dynamiques simulant des conditions d'attaque réelles, des protections natives de framework appliquant des valeurs sûres au niveau du code, et une analyse comportementale détectant les intrusions par fixation atteignant la session authentifiée. Les outils ci-dessous couvrent ces trois aspects.
Outils DAST et de test d'intrusion
- OWASP ZAP est un outil gratuit et open source de test dynamique de la sécurité des applications. Selon la documentation officielle, ZAP utilise des modes de scan actif et passif pour détecter les failles de gestion de session, y compris la fixation de session.
- Burp Suite Professional propose des workflows de test de session et des règles de scan pour identifier les vulnérabilités de gestion des jetons de session. Ses capacités de test manuel vous permettent de suivre la procédure WSTG-SESS-03 avec une visibilité complète des requêtes/réponses.
- ModSecurity avec OWASP Core Rule Set fournit des contre-mesures WAF contre la fixation de session, incluant l'identification et l'application des attributs de sécurité des cookies, le suivi de session persistante et le renouvellement de l'ID de session lors des changements de privilège observés.
Fonctionnalités de sécurité des frameworks
La protection intégrée contre la fixation de session de Spring Security, session.use_strict_mode et session_regenerate_id() de PHP, et Session.Abandon() d'ASP.NET offrent tous une prévention native au langage. Vous devez vérifier que ces fonctionnalités sont activées et correctement configurées dans vos déploiements plutôt que de vous fier aux paramètres par défaut.
Vulnérabilités connexes
La fixation de session n'agit pas isolément. Plusieurs faiblesses connexes partagent des mécanismes de livraison, des conditions d'exploitation ou des facteurs de risque amplificateurs avec CWE-384. Les comprendre comme un groupe permet une remédiation plus efficace que de traiter la fixation de session seule.
- Cross-Site Scripting (CWE-79) sert de vecteur de livraison pour la fixation de session. Un XSS réfléchi peut injecter du JavaScript qui définit un cookie de session contrôlé dans le navigateur de la victime. Corriger le XSS ferme l'un des principaux canaux de livraison de la fixation.
- Cross-Site Request Forgery (CWE-352) est souvent confondu avec la fixation de session, mais la mécanique diffère. Le CSRF exploite la transmission automatique des cookies par le navigateur pour forger des requêtes depuis une session authentifiée. Il n'exige pas que l'attaquant connaisse ou contrôle l'ID de session. CWE-352 était classé #9 dans le Top 25 CWE 2023.
- Authentification incorrecte (CWE-287) est étroitement liée à la fixation de session, relevant de la même catégorie OWASP A07 des échecs d'authentification. CWE-287 couvre toutes les formes d'authentification défaillante et était classée #13 dans le Top 25 CWE 2023 avec 10 entrées dans le catalogue CISA des vulnérabilités exploitées connues.
- Expiration de session insuffisante (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) amplifie le risque de fixation de session en prolongeant la fenêtre pendant laquelle un ID de session fixé reste valide. Des délais de session longs donnent plus de temps aux attaquants pour exploiter une session fixée.
- Génération de nombres prévisibles (CWE-340) peut précéder la fixation de session via une relation CanFollow dans la taxonomie MITRE. Des identifiants de session prévisibles abaissent la barrière pour les attaques de fixation en rendant possible la devinette de valeurs d'ID valides. Traiter la fixation de session isolément ne couvre que rarement toute la surface de risque ; examiner ces faiblesses connexes dans le même cycle comble les failles exploitées par la fixation pour obtenir son point d'appui initial.
CVE connexes
ID CVE | Description | Sévérité | Produit affecté | Année |
| L'identifiant de session n'est pas régénéré après la connexion ; l'attaquant définit l'ID de session de la victime avant l'authentification et détourne la session post-authentification | En attente | OpenSolution : Quick.Cart | 2026 | |
| Fixation de session déclenchée lors de l'authentification distante utilisant des variables SSO ; l'attaquant peut voler une session précédemment ouverte par un autre utilisateur sur la même machine | En attente | GLPI (≥ 0.71 < 10.0.23 ; ≥ 11.0.0-alpha < 11.0.5) | 2026 | |
| Fixation de session (CWE-384) permettant à un attaquant de prendre le contrôle de la session utilisateur et d'effectuer des transactions non autorisées au nom de la victime | MOYENNE (6.5) | HCL Technologies : Aftermarket DPC (Aftermarket Cloud 1.0.0) | 2025 | |
| Mauvaise gestion de session (CWE-287) dans ManageEngine ADSelfService Plus ; un utilisateur authentifié à faible privilège exploite une gestion de session incorrecte pour prendre le contrôle d'autres comptes utilisateurs | ÉLEVÉE (9.3) | Zohocorp ManageEngine ADSelfService Plus (≤ build 6510) | 2025 | |
| Fixation de session (CWE-384) dans le middleware de session GoFiber ; accepte les valeurs session_id fournies par l'utilisateur, donnant à l'attaquant le contrôle de la clé de session authentifiée | CRITIQUE (9.8) | GoFiber : Fiber (< 2.52.5) | 2024 | |
| Détournement de session (CWE-384) dans le plug-in d'authentification améliorée VMware obsolète ; un attaquant local non privilégié détourne la session EAP authentifiée d'un utilisateur de domaine privilégié | ÉLEVÉE (7.8) | VMware : Enhanced Authentication Plug-in (obsolète) | 2024 | |
| Relais d'authentification et détournement de session dans VMware EAP obsolète ; un acteur malveillant trompe un utilisateur de domaine pour relayer des tickets de service Kerberos pour des SPN Active Directory arbitraires | CRITIQUE (9.6) | VMware : Enhanced Authentication Plug-in (obsolète) | 2024 | |
| SECRET_KEY par défaut dans Apache Superset utilisé pour signer les cookies de session ; un attaquant connaissant la valeur par défaut peut forger des cookies de session valides et s'authentifier en tant que n'importe quel utilisateur, y compris les administrateurs ; CISA KEV | CRITIQUE (9.8) | Apache Superset (≤ 2.0.1) | 2023 | |
| L'ID de session reste valide dans le gestionnaire d'ID de session lorsqu'une exception est levée depuis SessionListener#sessionDestroyed() (CWE-613) ; la session de l'utilisateur précédent reste accessible après déconnexion sur des ordinateurs partagés | FAIBLE (3.5) | Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3) | 2021 | |
| Les jetons de session signés avec la clé secrète par défaut sont acceptés sur différentes instances Airflow ; un utilisateur authentifié sur une instance peut accéder à une autre sans ré-authentification | ÉLEVÉE (8.8) | Apache Airflow Webserver (< 1.10.14) | 2020 |
Cybersécurité alimentée par l'IA
Améliorez votre posture de sécurité grâce à la détection en temps réel, à une réponse à la vitesse de la machine et à une visibilité totale de l'ensemble de votre environnement numérique.
Obtenir une démonstrationConclusion
La fixation de session exploite une seule défaillance bien comprise : votre application ne régénère pas l'ID de session après authentification. Classée formellement CWE-384 et associée à OWASP Top 10 2025 A07, elle continue d'apparaître sur les plateformes CMS, les frameworks Java, les applications PHP et les systèmes ICS/SCADA.
Vous réduisez le risque en faisant tourner les IDs de session à chaque changement de privilège, en appliquant une acceptation stricte des sessions, en renforçant le périmètre des cookies et en auditant l'activité post-authentification pour détecter les abus.
FAQ
La session fixation se produit lorsqu'une application conserve le même identifiant de session avant et après la connexion. Un attaquant fait d'abord utiliser à la victime un identifiant de session connu, puis attend que la victime s'authentifie.
Si l'application ne délivre pas un nouvel identifiant, l'attaquant peut utiliser cette même session authentifiée. La défense clé est simple : invalider l'ancienne session et en créer une nouvelle après la connexion et lors des changements de privilèges.
Oui. CWE-384 est inclus dans l'OWASP Top 10 2025 A07 : Échecs d'authentification. Pour vous en tant que défenseur, cela compte moins comme étiquette que comme signal de priorisation : la session fixation est traitée comme un échec d'authentification, et non simplement comme une mauvaise configuration de cookie.
Elle doit être prise en compte lors des revues de flux de connexion, des tests de gestion de session et du renforcement de l'authentification.
Oui. La livraison à distance est courante car l'attaquant a généralement seulement besoin d'un moyen pour faire utiliser à la victime un identifiant de session choisi. Cela peut se produire via une URL conçue, un script côté navigateur, une réponse malveillante ou une application plus faible sur le même domaine parent.
L'accès physique n'est requis que dans des scénarios comme les terminaux partagés ou publics.
Les applications les plus à risque sont celles qui acceptent des identifiants de session fournis par l'utilisateur ou qui ne les renouvellent pas après l'authentification. Les exemples courants mentionnés dans l'article incluent les schémas de session basés sur l'URL, les modules d'authentification CMS, les piles d'applications Java, les environnements à domaine partagé, les plateformes de workflow et les interfaces web ICS/SCADA.
Le point commun est une gestion faible du cycle de vie des sessions, et non un langage ou un secteur spécifique.
Ils testent si une session survit à la connexion sans changement. Une méthode simple consiste à capturer un identifiant de session avant authentification, à s'authentifier avec, puis à comparer la valeur après.
Si le même identifiant est toujours valide, la faille est présente. Les outils de scan peuvent aider, mais des tests manuels sont souvent nécessaires pour les cas particuliers comme la régénération partielle ou le comportement des cookies inter-sous-domaines.
Recherchez une session se comportant comme si deux utilisateurs la possédaient. Les signes d'alerte pratiques incluent la même session apparaissant depuis différentes adresses IP, des changements soudains d'appareil ou de localisation, ou des schémas d'accès qui changent immédiatement après la connexion.
Les requêtes qui transmettent des identifiants de session dans les URL vers des points de terminaison d'authentification peuvent également indiquer une tentative de fixation plutôt qu'une navigation normale.
La gravité dépend des actions possibles avec le compte compromis. Dans des contextes à faible valeur, elle peut être considérée comme moyenne. Dans des systèmes à forte valeur, la même faille peut permettre une prise de contrôle complète du compte et des abus administratifs.
Les exemples de CVE de l'article vont de 4.6 à 9.8, ce qui montre que la session fixation n'est pas intrinsèquement mineure ; l'impact dépend des privilèges, de l'exposition et des contrôles environnants.
Elle peut conduire directement à la compromission complète du compte ciblé, et cela peut s'étendre si la victime est un administrateur. Une fois que l'attaquant hérite de privilèges élevés, il peut modifier des paramètres, accéder à des données sensibles ou effectuer des actions affectant tout l'environnement.
La faille cible les sessions, mais l'impact métier peut largement dépasser une simple connexion.
La forme la plus simple est relativement facile à repérer car les outils peuvent comparer les identifiants de session avant et après l'authentification. Les cas plus complexes impliquent une régénération partielle, des cookies hérités entre sous-domaines ou des conditions liées au transport et au comportement du navigateur.
En pratique, le scan est utile pour la couverture, mais des tests manuels ciblés restent importants pour confirmer la réelle exploitabilité.
Toute industrie exploitant des applications web authentifiées est exposée, en particulier là où les utilisateurs manipulent des données ou transactions sensibles. L'article met en avant le e-commerce, les plateformes d'entreprise, les environnements à domaine partagé, les systèmes réglementés de type santé et les déploiements ICS/SCADA.
Le risque augmente lorsque les organisations dépendent de plugins, de la gestion de session héritée ou de plusieurs applications partageant un domaine parent.
