Wat is Session Fixation? Hoe aanvallers gebruikerssessies kapen

Session fixation stelt aanvallers in staat om geauthenticeerde accounts te kapen door vóór het inloggen een bekende sessie-ID af te dwingen. De belangrijkste verdediging: genereer sessie-ID's opnieuw bij elke login.

Wat is session fixation?

Session fixation is een kwetsbaarheid in webapplicaties waarmee een aanvaller een geldige gebruikerssessie kan kapen door misbruik te maken van een fout in het beheer van sessie-identificatie. De kern van het probleem is eenvoudig: wanneer een gebruiker zich authentiseert, wijst de applicatie geen nieuw sessie-ID toe. Dit betekent dat een aanvaller die het pre-authenticatie sessie-ID kent of beheert, dit kan gebruiken om toegang te krijgen tot de geauthenticeerde sessie alsof hij de legitieme gebruiker is.

MITRE CWE definieert de zwakte formeel: "Het authenticeren van een gebruiker, of het anderszins opzetten van een nieuwe gebruikerssessie, zonder een bestaand sessie-ID ongeldig te maken, geeft een aanvaller de kans om geauthenticeerde sessies te stelen." Voor u resulteert dit in vrijwel volledige overname van het account, vaak zonder dat het slachtoffer iets merkt.

Session fixation is anders dan session hijacking, hoewel deze twee soms door elkaar worden gehaald. OWASP maakt het onderscheid duidelijk: session fixation begint vóórdat het slachtoffer inlogt, terwijl session hijacking plaatsvindt nadat er al een actieve geauthenticeerde sessie bestaat. Bij een fixation-aanval kent de aanvaller het sessie-ID al omdat hij het zelf heeft ingesteld. Bij een hijacking-aanval moet de aanvaller het sessie-ID van een actieve sessie onderscheppen of voorspellen.

Attribuut	Session Fixation	Session Hijacking
Aanvalstijdstip	Voor authenticatie van het slachtoffer	Na authenticatie van het slachtoffer
Kennis van sessie-ID	Aanvaller stelt het ID in of kent het vooraf	Aanvaller moet het ID onderscheppen of voorspellen
Primaire tegenmaatregel	Sessie-ID regeneratie bij inloggen	Token-encryptie, veilige transmissie

Dit onderscheid is belangrijk voor uw beveiligingsmaatregelen. Als uw applicatie sessie-ID's regenereert na het inloggen, stopt u fixation-aanvallen. Als u alleen sessietokens tijdens transport versleutelt, pakt u hijacking aan maar blijft fixation mogelijk. Door te begrijpen hoe de aanval technisch werkt, ziet u waarom dit verschil zo cruciaal is.

Hoe werkt session fixation?

Session fixation volgt een aanvalspad in vier stappen, gedocumenteerd door zowel MITRE CWE als OWASP WSTG.

• Stap 1: Sessieverwerving. De aanvaller bezoekt de doelapplicatie en ontvangt een geldig pre-authenticatie sessie-ID. Bijvoorbeeld, de server retourneert JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1. In applicaties die een permissief sessieacceptatiemechanisme gebruiken, kan de aanvaller een willekeurige sessie-ID aanleveren die de applicatie zonder controle accepteert.
• Stap 2: Sessielevering. De aanvaller levert het bekende sessie-ID aan het slachtoffer. Dit kan via een aangepaste URL, een cross-site scripting payload, een geïnjecteerde META-tag of HTTP response splitting. Het doel is eenvoudig: de browser van het slachtoffer het door de aanvaller gecontroleerde sessie-ID laten meesturen bij toegang tot de doelapplicatie.
• Stap 3: Authenticatie van het slachtoffer. Het slachtoffer klikt op de aangepaste link of bezoekt de applicatie via het leveringsmechanisme van de aanvaller en logt normaal in. De applicatie valideert de inloggegevens en verleent toegang. Maar het faalt in het regenereren van het sessie-ID na succesvolle login, en blijft werken met dezelfde identifier die de aanvaller al kent.
• Stap 4: Accountovername. De aanvaller stuurt verzoeken naar de applicatie met het bekende sessie-ID. De server behandelt deze verzoeken alsof ze afkomstig zijn van het geauthenticeerde slachtoffer. MITRE merkt op dat dit "vrijwel onbeperkte toegang tot het account van het slachtoffer biedt gedurende de levensduur van de sessie."

Buiten deze vier kernstappen kan session fixation via verschillende methoden worden uitgevoerd, afhankelijk van de toegang van de aanvaller en de configuratie van de doelapplicatie.

Vijf primaire aanvalsvectoren

1. URL-parameterinjectie is de eenvoudigste vector. De aanvaller plaatst het sessie-ID als URL-queryparameter en levert de link via phishing of e-mail: https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner classificeert "Session token in URL" als CWE-384.
2. Cookie-injectie via XSS gebruikt JavaScript dat in de browser van het slachtoffer wordt uitgevoerd om de sessiecookie te zetten: document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE bevestigt dat cross-site scripting een van de twee meest voorkomende technieken is voor het afleveren van session fixation payloads.
3. META-taginjectie plaatst een HTML-tag die de browser instrueert een cookie te zetten: <meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP merkt op dat deze aanpak moeilijker te blokkeren is dan JavaScript-injectie omdat "het onmogelijk is om de verwerking van deze tags in browsers uit te schakelen."
4. HTTP response header-injectie maakt misbruik van response splitting kwetsbaarheden om een Set-Cookie header direct in een serverrespons te injecteren, waardoor het gecontroleerde sessie-ID wordt geplaatst zonder client-side scripting.
5. Cross-subdomein cookie fixation maakt misbruik van gedeelde domeinarchitecturen. MITRE documenteert dit direct: als bank.example.com en recipes.example.com hetzelfde top-level domein delen, kan een kwetsbaarheid in de receptenapplicatie een sessie-ID fixeren dat wordt gebruikt door alle applicaties op example.com. De breedte van de leveringsvectoren verklaart waarom session fixation nog steeds voorkomt in productiesystemen.

Oorzaken van session fixation

De hoofdoorzaken van session fixation zijn goed gedocumenteerd en elk vormt een gat dat u en uw ontwikkelteam kunnen dichten.

Geen regeneratie van sessie-ID's na authenticatie

Dit is de primaire oorzaak, genoemd door elke gezaghebbende bron in dit artikel. De OWASP-gids stelt het direct: "Wanneer een applicatie zijn sessiecookie(s) niet vernieuwt na succesvolle gebruikersauthenticatie, kan het mogelijk zijn een session fixation kwetsbaarheid te vinden."

De OWASP sheet specificeert dat sessie-ID regeneratie verplicht is bij inloggen, wachtwoordwijzigingen, wijzigingen in permissieniveau en roltransities. De CVE-2022-24895 documenteert dat Symfony's NONE session migration strategy dezelfde sessie behoudt na authenticatie, waardoor fixation-aanvallen mogelijk zijn, en draagt een HOGE ernstgraad.

Permissieve acceptatie van sessie-ID's

De OWASP Session Management Cheat Sheet definieert twee mechanismen voor het omgaan met sessie-ID's. Een permissief mechanisme accepteert elke door de gebruiker ingestelde sessie-ID als geldig en maakt er een nieuwe sessie voor aan. Een strikt mechanisme accepteert alleen sessie-ID's die eerder door de applicatie zijn gegenereerd. Als uw applicatie het permissieve mechanisme gebruikt, kunnen aanvallers willekeurige waarden plaatsen zonder eerst een server-uitgegeven ID te verkrijgen.

Voorspelbare sessie-identificaties

MITRE identificeert voorspelbare sessie-identificaties als een bijdragende factor, gerelateerd aan CWE-340 (Genereren van voorspelbare nummers of identificaties). Wanneer sessie-ID's patronen volgen of zwakke willekeurigheid gebruiken, kunnen aanvallers geldige waarden voorspellen zonder er een van de server te hoeven verkrijgen.

Permissieve cookiedomeinscope

Het instellen van het Domain cookie-attribuut op een top-level domein, bijvoorbeeld Domain=example.com in plaats van Domain=app.example.com, zorgt ervoor dat cookies over alle subdomeinen worden verzonden. Een kwetsbaarheid in één subdomein wordt zo een fixation-ingangspunt voor elke applicatie op dat domein.

HTTP-naar-HTTPS transitie zonder sessieregeneratie

OWASP WSTG-SESS-03 identificeert dit specifieke scenario: sites die een sessie-ID uitgeven via HTTP en vervolgens doorverwijzen naar een HTTPS-inlogformulier, zonder het sessie-ID opnieuw uit te geven na authenticatie, stellen het pre-authenticatie-ID bloot aan netwerkafluisteren. De aanvaller onderschept het ID via de onveilige verbinding en wacht tot het slachtoffer zich authentiseert. Deze oorzaken komen zelden geïsoleerd voor, en inzicht in hoe de standaardisatiegemeenschap ze formeel classificeert helpt u bij het communiceren en prioriteren van herstelmaatregelen.

OWASP-classificatie van session fixation

Session fixation is formeel geclassificeerd binnen drie gezaghebbende standaardsystemen: de MITRE Common Weakness Enumeration, de OWASP Top 10 en de OWASP Web Security Testing Guide. Onder OWASP A07 valt het binnen de categorie authenticatiefouten, samen met gerelateerde zwaktes die hetzelfde herstelbereik delen. Elke classificatie dient een ander publiek en signaleert een andere actie.

CWE-384: Formele zwakte-identificatie

MITRE CWE-384 is de primaire classificatie voor session fixation en definieert de zwakte als het authenticeren van een gebruiker zonder het bestaande sessie-ID ongeldig te maken. Het profiel in de MITRE-taxonomie:

• Type zwakte: Basiszwakte binnen de categorie Session Credentials
• Veelvoorkomende gevolgen: Privileges verkrijgen of de identiteit van het slachtoffer aannemen; volledige accountovername gedurende de sessieduur
• Kans op exploitatie: Gemiddeld — vereist het afleveren van een bekend sessie-ID aan het slachtoffer vóór inloggen
• Platformscope: Taalonafhankelijk; van toepassing ongeacht webstack of framework
• CWE Top 25-status: In de Top 25 sinds 2019; blijft een actief gevolgde zwakte in de editie van 2023

Deze eigenschappen maken CWE-384 tot een consistent signaal in kwetsbaarheidsscanners en assessment frameworks, waar het direct in kaart wordt gebracht met testcases gericht op sessielifecyclebeheer.

OWASP Top 10 en teststandaarden

CWE-384 is gekoppeld aan A07:2025 — Authentication Failures in de OWASP Top 10. Deze classificatie heeft een belangrijke implicatie: session fixation wordt behandeld als een authenticatiecontrolefout, niet als een cookie-misconfiguratie. Dat plaatst het direct binnen login-flow reviews en authenticatieversterking, niet alleen cookieconfiguratie-audits.

Referentie	Systeem	Doel
CWE-384	MITRE CWE	Formele zwaktetracering; gebruikt door SAST/DAST-tools en CVE-registraties
A07:2025	OWASP Top 10	Risicoprioritering; richt de review op authenticatiecontroles
WSTG-SESS-03	OWASP WSTG	Gezaghebbende black-box testprocedure en pass/fail-criteria
Session Management Cheat Sheet	OWASP CheatSheets	Referentie voor ontwikkelaars voor preventie van regeneratie, cookiebereik en strikte modus

Samen bieden deze vier referenties u de terminologie, testcases en herstelrichtlijnen om session fixation binnen elk bestaand beveiligingsprogramma aan te pakken. Met de classificatiecontext vastgesteld, is het de moeite waard te onderzoeken wat er daadwerkelijk gebeurt wanneer de kwetsbaarheid succesvol wordt uitgebuit.

Impact en risico van session fixation

Session fixation maakt volledige accountovername mogelijk gedurende de levensduur van de gecompromitteerde sessie. Zodra een aanvaller een geauthentiseerd sessie-ID bezit, opereert hij met alle privileges van het slachtoffer: het lezen van gevoelige gegevens, uitvoeren van transacties, wijzigen van accountinstellingen en escaleren van toegang als het slachtoffer beheerdersrechten heeft.

OWASP-classificatie en ernst

CWE-384 valt onder OWASP A07. De A07:2025-categorie heeft een gemiddeld gewogen exploitability score van 7,69, gekoppeld aan 7.147 totale CVE's over geteste applicaties. Het totale aantal CVE's gekoppeld aan de A07-categorie is ook gestegen tussen de edities van 2021 en 2025, wat een uitbreiding van het aanvalsoppervlak weerspiegelt.

CVSS-scorebereik

Bevestigde session fixation CVE's variëren van Medium tot Kritiek. De hoogst gewaardeerde gevallen betreffen doorgaans scenario's waarbij fixation ongeauthentiseerde accountovername mogelijk maakt in breed ingezette authenticatieplug-ins of frameworks. Een belangrijk detail voor u als professional: session fixation CVE's tonen vaak scoreverschillen tussen NIST NVD en leveranciers-CNA's. Bijvoorbeeld, CVE-2019-17563 (Apache Tomcat) kreeg een KRITIEKE beoordeling van NIST maar een "Low" beoordeling van Apache, dat het exploitatievenster als "te smal voor een praktische exploit" beschreef.

Verzwarende risicofactoren

Session fixation is zelden een op zichzelf staand risico. CVE-2024-56529 (Mailcow) toont aan dat de aanval specifiek slaagt wanneer HSTS is uitgeschakeld in de browser van het slachtoffer. Een Microsoft Research-paper gepresenteerd op IEEE S&P 2015 documenteerde dat cookie-injectie standaard sessieregeneratieverdedigingen op echte websites kon omzeilen. Wanneer defense-in-depth controles gelijktijdig falen, kan een session fixation kwetsbaarheid snel escaleren. De vraag wie kwetsbaar is, gaat verder dan alleen webapplicaties.

Hoe aanvallers session fixation uitbuiten

Aanvallers benutten session fixation via scenario's die variëren van gerichte phishing tot opportunistische sessie-vergiftiging.

Phishing-gebaseerde URL-injectie

De aanvaller maakt een URL met een bekend sessie-ID en levert deze via phishing of social engineering. De URL lijkt legitiem omdat deze naar het echte applicatiedomein verwijst. Het slachtoffer klikt op de link, logt normaal in en authentiseert onbewust een sessie die door de aanvaller wordt beheerd. Dit is het meest voorkomende scenario voor URL-gebaseerde sessie-ID transmissie.

Misbruik van openbare terminals

MITRE CWE-384 documenteert een klassiek scenario: een aanvaller maakt een sessie vanaf een openbare terminal, noteert het sessie-ID, reset de browser naar de inlogpagina en wacht tot de volgende gebruiker zich authentiseert. De applicatie blijft het bestaande sessie-ID gebruiken, waardoor de aanvaller "vrijwel onbeperkte toegang tot het account van het slachtoffer heeft gedurende de sessieduur."

Niet-gerichte sessie-vergiftiging

CVE-2022-30769 (ZoneMinder) toonde een aanval waarbij een aanvaller een sessiecookie kon "vergiftigen" voor de volgende gebruiker die inlogde. Dit vereiste geen gerichtheid op een specifiek individu. De vergiftigde sessie werd overgenomen door wie er daarna authenticeerde. In omgevingen met gedeelde toegang, zoals surveillanceplatforms, is dit patroon bijzonder gevaarlijk.

Race condition-exploitatie

CVE-2013-2067 (Apache Tomcat) onthulde een race condition in FORM-authenticatie. Door herhaaldelijk verzoeken te sturen voor geauthenticeerde resources terwijl een slachtoffer het inlogformulier invulde, kon een aanvaller een verzoek injecteren dat werd uitgevoerd met de inloggegevens van het slachtoffer. Apache beoordeelde dit als "Important" ernst.

Cross-subdomein aanvallen

In multi-applicatiearchitecturen die een top-level domein delen, benutten aanvallers een applicatie met lage beveiliging om een sessiecookie te fixeren die is gescope op het hoofddomein. Elke andere applicatie op dat domein accepteert dan het gefixeerde sessie-ID. Dit scenario komt vaak voor in enterprise-omgevingen met meerdere interne tools op een gedeeld domein. Weten wie wordt getroffen helpt u prioriteren waar u naar deze kwetsbaarheden moet zoeken.

Wie is kwetsbaar voor session fixation?

Session fixation treft elke applicatie die gebruikerssessies beheert via identificaties en deze niet regenereert bij authenticatie. De CVE-registratie en MITRE-documentatie wijzen op verschillende structureel risicovolle categorieën.

• Webapplicaties die URL-gebaseerde sessie-identificaties gebruiken lopen het meest directe risico. URL-gebaseerde sessietransmissie stelt aanvallers in staat een gecontroleerd sessie-ID te leveren via een aangepaste link zonder extra kwetsbaarheid.
• CMS- en authenticatieplug-in ecosystemen worden herhaaldelijk getroffen. CVE-2024-13279 (Drupal TFA, per CISA), CVE-2010-1434 (Joomla!), CVE-2012-5391 (MediaWiki) en CVE-2019-8116 (Magento) tonen aan dat authenticatiemodules bovenop CMS-platforms een kritisch session fixation risico introduceren als sessieregeneratie niet wordt afgedwongen.
• J2EE/Java EE-applicaties hebben een van de meest uitgebreide gedocumenteerde CVE-reeksen. Apache Tomcat alleen al kent CVE's van 2013 tot 2025, waaronder CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563 en CVE-2025-55668.
• Multi-applicatie gedeelde domeinarchitecturen zijn kwetsbaar door ontwerp. SaaS-platforms met tenant-subdomeinen en enterprise-applicatieportefeuilles die een top-level domein delen lopen cross-subdomein fixation risico, zoals MITRE direct documenteert.
• ICS/SCADA-platforms vormen een opkomend aanvalsoppervlak. CVE-2025-70973 (ScadaBR 1.12.4, openbaar gemaakt maart 2026) toont session fixation in industriële controlesystemen, in lijn met CWE-384's ICS-categorie mapping naar CWE-1364 (ICS Communications: Zone Boundary Failures) en CWE-1366 (ICS Communications: Frail Security in Protocols).
• Enterprise workflowplatforms hebben ook gedocumenteerde blootstelling. CVE-2022-38369 (Apache IoTDB) en CVE-2022-38054 (Apache Airflow) tonen aan dat workflow-automatiseringstools niet immuun zijn. De breedte van getroffen categorieën maakt praktijkvoorbeelden nuttig om te begrijpen hoe deze kwetsbaarheden in de praktijk voorkomen.

Praktijkvoorbeelden van session fixation

Session fixation is bevestigd in een breed scala aan productiesystemen, van enterprise Java-frameworks tot industriële controlesystemen. De onderstaande voorbeelden illustreren hoe hetzelfde onderliggende probleem zich verschillend manifesteert afhankelijk van de omgeving.

Apache Tomcat FORM authenticatie race condition (CVE-2013-2067)

Dit blijft de meest impactvolle Tomcat session fixation CVE, beoordeeld als "Important" door Apache. Van toepassing op Tomcat 6.0.21 t/m 6.0.36 en 7.0.0 t/m 7.0.32, maakte de kwetsbaarheid misbruik van een race condition in FORM-authenticatie. Een aanvaller kon herhaaldelijk verzoeken sturen voor geauthenticeerde resources terwijl een slachtoffer het inlogformulier invulde, waardoor een verzoek werd geïnjecteerd dat werd uitgevoerd met de inloggegevens van het slachtoffer. Ironisch genoeg werd de optie om het sessie-ID te wijzigen bij authenticatie zelf toegevoegd in Tomcat 6.0.21. Deze CVE vertegenwoordigde een bug in Tomcat's eigen fixation-bescherming.

Symfony framework CSRF-token bypass (CVE-2022-24895)

Symfony versies 2.0.0 t/m 6.2.5 waren getroffen door een HOGE ernst kwetsbaarheid. Het framework regenereerde het sessie-ID bij inloggen maar behield de rest van de sessie-attributen, waaronder CSRF-tokens. Deze gedeeltelijke regeneratie stelde same-site aanvallers in staat CSRF-bescherming te omzeilen via een session fixation variant. De les is duidelijk: alleen het sessie-ID regenereren is niet voldoende. Volledige sessie-invalidatie en heruitgifte is vereist.

ScadaBR industriële controlesysteem (CVE-2025-70973)

Openbaar gemaakt in maart 2026, volgt deze kwetsbaarheid in ScadaBR 1.12.4 het canonieke session fixation patroon. De applicatie wijst een JSESSIONID sessiecookie toe aan niet-geauthenticeerde gebruikers en regenereert het sessie-ID niet na succesvolle authenticatie. Een sessie die vóór het inloggen is aangemaakt, wordt geauthentiseerd zodra het slachtoffer inlogt. Deze CVE is opmerkelijk omdat het actieve session fixation risico in ICS/SCADA-omgevingen aantoont.

ZoneMinder niet-gerichte sessie-vergiftiging (CVE-2022-30769)

ZoneMinder 1.36.12 en eerdere versies stonden een aanvaller toe een sessiecookie te vergiftigen dat zou worden overgenomen door de volgende gebruiker die zich authenticeerde. Dit vereiste geen gerichtheid op een specifiek slachtoffer, wat het bijzonder gevaarlijk maakt in omgevingen met gedeelde toegang waar meerdere operators toegang delen tot hetzelfde platform.

PHP session adoption (CVE-2011-4718)

De sessiemodule van PHP was "adoptief", wat betekende dat het sessie-ID's van externe bronnen accepteerde. De PHP RFC stelde dat "gebruik van session_regenerate_id() GEEN session adoption/fixation kan voorkomen" zonder ook session.use_strict_mode in te schakelen. PHP 5.5.2 introduceerde session.use_strict_mode als de oplossing, maar zelfs met strikte modus ingeschakeld konden aangepaste save handlers kwetsbaar blijven. Het volledige historische overzicht van deze incidenten toont aan hoe lang deze kwetsbaarheidsklasse al bestaat.

Session fixation tijdlijn en geschiedenis

Session fixation is formeel gedocumenteerd sinds 2002 en de CVE-registratie toont aan dat het actief blijft in nieuwe en legacy codebases. De onderstaande tijdlijn volgt belangrijke openbaarmakingen en frameworkreacties.

Jaar	Gebeurtenis
Dec 2002	Mitja Kolšek (ACROS Security) publiceert "Session Fixation Vulnerability in Web-based Applications" en benoemt session fixation formeel als vierde aanvalsklasse tegen sessie-identificaties
2006	CVE-2006-1228 (Drupal 4.5.x/4.6.x): URL-gebaseerde sessie-ID fixation
Juli 2006	MITRE voegt CWE-384 toe aan Common Weakness Enumeration (Draft 3)
Feb 2008	Oracle/BEA WebLogic Server advisory BEA08-196.00: session fixation maakt privilege-escalatie mogelijk
2009	CVE-2009-1580 (SquirrelMail); Black Hat USA documenteert CWE-384 in BitTorrent tracker communities
2010	CVE-2010-1434 (Joomla! 1.5.0 t/m 1.5.15): CVSS 7.5 HOOG
Dec 2011	CVE-2011-4718 (PHP session adoption): treft PHP 5.0.0 t/m 5.5.1
Mei 2013	CVE-2013-2067 (Apache Tomcat 6.x, 7.x): FORM auth race condition, Apache "Important" ernst
2015	Microsoft Research (IEEE S&P) documenteert cookie-injectie die breed toegepaste regeneratieverdedigingen omzeilt
2019	CWE-384 komt in de Top 25
Dec 2019	CVE-2019-17563 (Apache Tomcat): NIST 9.8 KRITIEK vs. Apache "Low"
2022	CVE-2022-24895 (Symfony): gedeeltelijke regeneratie bypass
Jan 2025	CVE-2024-56529 (Mailcow): session fixation bij uitgeschakelde HSTS
Aug 2025	CVE-2025-55668 (Apache Tomcat 9.x/10.x/11.x): CVSS 6.5 GEMIDDELD
Mar 2026	CVE-2025-70973 (ScadaBR 1.12.4) en CVE-2026-25101 (Bludit): nieuwe CVE's bevestigen dat de kwetsbaarheidsklasse actief blijft

De tijdlijn beslaat meer dan twee decennia zonder tekenen van afname. Session fixation is geen historische kwetsbaarheid. Het blijft voorkomen in zowel nieuwe als legacy codebases, van enterprise frameworks tot ICS-platforms. Als u weet hoe u uw eigen applicaties moet beoordelen, kunt u de volgende stap zetten.

Hoe session fixation detecteren?

Session fixation is een van de eenvoudigere kwetsbaarheden om te bevestigen: de kern van de test vereist niet meer dan het vastleggen van een sessie-identificatie vóór het inloggen, authenticeren en de waarde daarna vergelijken. De volgende benaderingen dekken handmatige verificatie, cookie-attribuutinspectie, geautomatiseerde scanning en WAF-laag identificatie.

Handmatige penetratietest (OWASP WSTG-SESS-03)

De gezaghebbende testprocedure komt uit de OWASP WSTG. Voor u is de black-box test eenvoudig.

1. Leg het pre-authenticatie sessie-ID vast. Bezoek de applicatie en noteer de waarde van de sessiecookie (bijv. JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1).
2. Authenticeer terwijl u het vastgelegde sessie-ID presenteert. Dien geldige inloggegevens in met de originele sessiecookie bijgevoegd.
3. Vergelijk sessie-ID waarden. Als de server na succesvolle authenticatie hetzelfde sessie-ID retourneert, is de applicatie kwetsbaar.

Voor applicaties zonder volledige HSTS-implementatie beschrijft WSTG-SESS-03 een tweede strategie: forceer alle cookies die niet na het inloggen zijn uitgegeven in de browser van het slachtoffer vanaf een andere machine, en bevestig of deze cookies toegang geven tot de sessie van het slachtoffer na authenticatie.

Cookie-attribuutverificatie

Controleer op hardening-indicatoren in uw sessiecookies. Het __Host-voorvoegsel biedt integriteit tegen netwerkgebaseerde session fixation. Het __Secure-voorvoegsel geeft gedeeltelijke hardening aan. Voer WSTG-SESS-03 uit om te verifiëren dat HttpOnly, Secure en SameSite attributen correct zijn geconfigureerd.

DAST-scanning

OWASP ZAP biedt zowel actieve als passieve scanmodi met ondersteuning voor sessiebeheer, inclusief cookies, tokens en andere mechanismen. ZAP's analyse van sessie- en authenticatiehandhaving helpt u gebroken authenticatie en session fixation bugs te vinden. Burp Suite Professional ondersteunt workflows voor sessiebeheer en fungeert als een dynamische webkwetsbaarheidsscanner voor sessiebeheer.

WAF-gebaseerde identificatie

De OWASP sheet noemt ModSecurity in combinatie met de OWASP Core Rule Set als tegenmaatregel tegen session fixation aanvallen. Deze WAF-laag aanpak wordt aanbevolen wanneer broncode niet beschikbaar is, niet kan worden aangepast, of wanneer volledige applicatieniveau-oplossingen een ingrijpend herontwerp vereisen. Effectieve beoordeling moet direct leiden tot preventie, en de vereiste controles zijn goed gedefinieerd.

Hoe session fixation voorkomen?

Preventie draait om één niet-onderhandelbare eis: de applicatie moet bij elk authenticatie-evenement een nieuw sessie-ID uitgeven en elk sessie-ID weigeren dat niet door de server zelf is gegenereerd. De onderstaande controles adresseren die eis op applicatieniveau, frameworkniveau, cookieconfiguratie en netwerkarchitectuur.

Applicatielaagcontroles

• Regenereren van sessie-ID's na authenticatie. Dit is de belangrijkste controle. OWASP WSTG-SESS-03 stelt de eis duidelijk: "de applicatie moet altijd eerst het bestaande sessie-ID ongeldig maken vóór authenticatie van een gebruiker, en als authenticatie succesvol is, een ander sessie-ID verstrekken." Regeneratie is verplicht bij elke wijziging van privilege, inclusief inloggen, wachtwoordwijzigingen, permissiewijzigingen en roltransities.
• Gebruik strikt sessiebeheer. Configureer uw applicatie om alleen door de server gegenereerde sessie-ID's te accepteren. Weiger willekeurige sessie-ID waarden van clients. PHP introduceerde session.use_strict_mode in versie 5.5.2 specifiek voor dit doel.
• Maak sessies volledig ongeldig. CVE-2022-24895 (Symfony) bewees dat gedeeltelijke sessieregeneratie niet voldoende is. Het regenereren van het sessie-ID terwijl andere sessie-attributen zoals CSRF-tokens behouden blijven, creëert een restkwetsbaarheid. Volledige sessie-invalidatie en heruitgifte is vereist.

Frameworkspecifieke implementatie

Framework	Bestaande sessie ongeldig maken	Nieuwe sessie aanmaken
J2EE	HttpSession.invalidate()	request.getSession(true)
ASP.NET	Session.Abandon()	Response.Cookies.Add(new HttpCookie(...))
PHP	session_start()	session_regenerate_id(true)

Spring Security beschermt automatisch tegen session fixation door een nieuwe sessie aan te maken of het sessie-ID te wijzigen wanneer een gebruiker inlogt. Vier configureerbare strategieën zijn beschikbaar: changeSessionId() (aanbevolen), migrateSession(), newSession(), en none() (niet aanbevolen).

Cookiebeveiligingsconfiguratie

Volg de eisen van NIST SP 800-63B:

• Secure vlag: MOET worden ingesteld (cookies alleen verzonden via HTTPS)
• Domain en Path: MOETEN worden beperkt tot het minimaal noodzakelijke bereik
• HttpOnly vlag: MOET worden ingesteld (voorkomt JavaScript-toegang)
• SameSite=Lax of Strict: MOET worden ingesteld (volgens NIST SP 800-63B v4 concept)
• __Host-voorvoegsel met Path=/: MOET worden ingesteld (volgens NIST SP 800-63B v4 concept)

Het toepassen van deze vlaggen in combinatie voorkomt de meest voorkomende netwerk- en cross-site fixation scenario's en verhoogt de drempel aanzienlijk voor elke aanvaller die cookie-injectie probeert.

Architectuurniveau-controles

Meng geen applicaties met verschillende beveiligingsniveaus op hetzelfde domein. Implementeer volledige HSTS inclusief subdomeinen om netwerkgebaseerde fixation tegen te gaan. Zet ModSecurity in met de OWASP Core Rule Set voor WAF-laag bescherming wanneer applicatieniveau-aanpassingen niet direct mogelijk zijn. Preventie en beoordeling werken het beste met de juiste tools.

Tools voor detectie en preventie

Het identificeren en stoppen van session fixation vereist tools op drie niveaus: dynamische scanners die echte aanvalsomstandigheden simuleren, framework-native beveiligingen die veilige standaardinstellingen afdwingen op codeniveau, en gedragsanalyse die fixation-gebaseerde inbraken detecteert die de geauthenticeerde sessie bereiken. De onderstaande tools dekken alle drie.

DAST- en penetratietesttools

• OWASP ZAP is een gratis, open-source dynamische applicatiebeveiligingstesttool. Volgens de officiële documentatie gebruikt ZAP actieve en passieve scanmodi om sessiebeheerfouten te vinden, waaronder session fixation.
• Burp Suite Professional biedt sessietest workflows en scannerregels voor het identificeren van kwetsbaarheden in sessietokenbeheer. De handmatige testmogelijkheden stellen u in staat de WSTG-SESS-03 procedure stap voor stap te doorlopen met volledig inzicht in verzoeken en antwoorden.
• ModSecurity met OWASP Core Rule Set biedt WAF-laag tegenmaatregelen tegen session fixation, waaronder identificatie en afdwingen van beveiligingscookie-attributen, sticky session tracking en sessie-ID vernieuwing bij privilegewijzigingen.

Frameworkbeveiligingsfuncties

Spring Security's ingebouwde session fixation bescherming, PHP's session.use_strict_mode en session_regenerate_id(), en ASP.NET's Session.Abandon() bieden allemaal taal-native preventie. U dient te verifiëren dat deze functies zijn ingeschakeld en correct geconfigureerd in uw implementaties, in plaats van te vertrouwen op standaardinstellingen.

Gerelateerde kwetsbaarheden

Session fixation opereert niet geïsoleerd. Verschillende nauw verwante zwaktes delen leveringsmechanismen, exploitatievoorwaarden of risicoversterkers met CWE-384. Ze als groep begrijpen levert een sterker herstelbereik op dan session fixation alleen behandelen.

• Cross-Site Scripting (CWE-79) dient als leveringsmechanisme voor session fixation. Reflected XSS kan JavaScript injecteren dat een gecontroleerde sessiecookie in de browser van het slachtoffer zet. Het aanpakken van XSS sluit een van de primaire fixation-leveringskanalen.
• Cross-Site Request Forgery (CWE-352) wordt vaak verward met session fixation, maar de werking verschilt. CSRF maakt misbruik van de automatische cookietransmissie van de browser om verzoeken te vervalsen vanuit een geauthenticeerde sessie. Het vereist niet dat de aanvaller het sessie-ID kent of beheert. CWE-352 stond op #9 in de 2023 CWE Top 25.
• Onjuiste authenticatie (CWE-287) is nauw verwant aan session fixation en valt binnen dezelfde OWASP A07 authenticatiefoutcategorie. CWE-287 dekt alle vormen van gebroken authenticatie en stond op #13 in de 2023 CWE Top 25 met 10 vermeldingen in de CISA Known Exploited Vulnerabilities catalogus.
• Onvoldoende sessieverval (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) vergroot het risico van session fixation door het venster te verlengen waarin een gefixeerd sessie-ID geldig blijft. Lange sessietime-outs geven aanvallers meer tijd om een gefixeerde sessie te misbruiken.
• Genereren van voorspelbare nummers (CWE-340) kan voorafgaan aan session fixation via een CanFollow-relatie in de MITRE-taxonomie. Voorspelbare sessie-identificaties verlagen de drempel voor fixation-aanvallen door het mogelijk te maken geldige sessie-ID waarden te raden. Session fixation in isolatie aanpakken dekt zelden het volledige risicovlak; het beoordelen van deze gerelateerde zwaktes in dezelfde cyclus sluit de gaten die fixation benut om zijn initiële toegang te verkrijgen.

Gerelateerde CVE's

CVE ID	Beschrijving	Ernst	Getroffen product	Jaar
CVE-2026-23796	Sessie-identificatie wordt niet geregenereerd na inloggen; aanvaller stelt sessie-ID van slachtoffer in vóór authenticatie en kaapt de post-login sessie	In behandeling	OpenSolution: Quick.Cart	2026
CVE-2026-23624	Session fixation geactiveerd wanneer remote authenticatie SSO-variabelen gebruikt; aanvaller kan sessie stelen die eerder door een andere gebruiker op dezelfde machine is geopend	In behandeling	GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5)	2026
CVE-2025-55266	Session fixation (CWE-384) stelt aanvaller in staat de sessie van de gebruiker over te nemen en ongeautoriseerde transacties uit te voeren namens het slachtoffer	MEDIUM (6.5)	HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0)	2025
CVE-2025-1723	Onjuist sessiebeheer (CWE-287) in ManageEngine ADSelfService Plus; geauthenticeerde gebruiker met lage rechten benut onjuist sessiebeheer om andere accounts over te nemen	HOOG (9.3)	Zohocorp ManageEngine ADSelfService Plus (≤ build 6510)	2025
CVE-2024-38513	Session fixation (CWE-384) in GoFiber session middleware; accepteert door gebruiker aangeleverde session_id waarden, waardoor de aanvaller controle krijgt over de geauthenticeerde sessiesleutel	CRITIEK (9.8)	GoFiber: Fiber (< 2.52.5)	2024
CVE-2024-22250	Session hijacking (CWE-384) in verouderde VMware Enhanced Authentication Plug-in; lokale niet-geprivilegieerde aanvaller kaapt geauthenticeerde EAP-sessie van geprivilegieerde domeingebruiker	HOOG (7.8)	VMware: Enhanced Authentication Plug-in (verouderd)	2024
CVE-2024-22245	Authenticatierelay en session hijacking in verouderde VMware EAP; kwaadwillende actor laat domeingebruiker Kerberos service tickets relayeren voor willekeurige Active Directory SPN's	CRITIEK (9.6)	VMware: Enhanced Authentication Plug-in (verouderd)	2024
CVE-2023-27524	Standaard SECRET_KEY in Apache Superset gebruikt om sessiecookies te ondertekenen; aanvaller met kennis van de standaardwaarde kan geldige sessiecookies vervalsen en zich authenticeren als elke gebruiker, inclusief admins; CISA KEV	CRITIEK (9.8)	Apache Superset (≤ 2.0.1)	2023
CVE-2021-34428	Sessie-ID blijft geldig in session ID manager wanneer een uitzondering wordt opgegooid vanuit SessionListener#sessionDestroyed() (CWE-613); vorige gebruikerssessie toegankelijk na uitloggen op gedeelde computers	LAAG (3.5)	Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3)	2021
CVE-2020-17526	Sessietokens ondertekend met de standaard geheime sleutel geaccepteerd over verschillende Airflow-implementaties; geauthenticeerde gebruiker op de ene instantie kan toegang krijgen tot een andere zonder opnieuw te authenticeren	HOOG (8.8)	Apache Airflow Webserver (< 1.10.14)	2020

Conclusie

Session fixation maakt misbruik van één, goed begrepen fout: uw applicatie regenereert het sessie-ID niet na authenticatie. Formeel geclassificeerd als CWE-384 en gekoppeld aan OWASP Top 10 2025 A07, blijft het voorkomen op CMS-platforms, Java-frameworks, PHP-applicaties en ICS/SCADA-systemen. 

U verlaagt het risico door sessie-ID's te roteren bij elke privilegewijziging, strikte sessieacceptatie af te dwingen, cookiebereik te hardenen en post-authenticatie-activiteit te beoordelen op misbruik.

Veelgestelde vragen

Wat is de Session Fixation-kwetsbaarheid?

Session fixation treedt op wanneer een applicatie dezelfde sessie-ID behoudt vóór en na het inloggen. Een aanvaller zorgt er eerst voor dat het slachtoffer een bekende sessie-ID gebruikt en wacht vervolgens tot het slachtoffer zich authentiseert. 

Als de applicatie geen nieuwe ID uitgeeft, kan de aanvaller diezelfde geauthenticeerde sessie gebruiken. De belangrijkste verdediging is eenvoudig: ongeldig maken van de oude sessie en een nieuwe aanmaken na inloggen en andere privilegewijzigingen.

Is session fixation onderdeel van de OWASP Top 10?

Ja. CWE-384 valt onder OWASP Top 10 2025 A07: Authentication Failures. Voor jou als verdediger is dat minder belangrijk als label dan als prioriteitssignaal: session fixation wordt behandeld als een authenticatiefout, niet alleen als een cookie-misconfiguratie. 

Het hoort thuis in beoordelingen van login-flows, testen van sessiebeheer en het versterken van authenticatie.

Kan session fixation op afstand worden misbruikt?

Ja. Afstandslevering komt vaak voor omdat de aanvaller meestal alleen een manier nodig heeft om het slachtoffer een gekozen sessie-ID te laten gebruiken. Dat kan via een aangepaste URL, een script aan de browserzijde, een kwaadaardig antwoord of een zwakkere applicatie op hetzelfde hoofddomein. 

Fysieke toegang is alleen vereist in scenario's zoals gedeelde of openbare terminals.

Welke typen applicaties zijn het meest kwetsbaar voor session fixation?

De applicaties met het hoogste risico zijn die welke door de gebruiker aangeleverde sessie-ID's accepteren of deze niet vernieuwen na authenticatie. Veelvoorkomende voorbeelden in het artikel zijn op URL gebaseerde sessieschema's, CMS-authenticatiemodules, Java-applicatiestacks, omgevingen met gedeeld domein, workflowplatforms en ICS/SCADA-webinterfaces. 

Het gedeelde patroon is zwakke afhandeling van de sessielevenscyclus, niet één specifieke programmeertaal of sector.

Hoe ontdekken aanvallers doorgaans session fixation?

Ze testen of een sessie het inloggen ongewijzigd overleeft. Een eenvoudige methode is het vastleggen van een pre-authenticatie sessie-ID, hiermee authenticeren en de waarde daarna vergelijken. 

Als dezelfde ID nog steeds geldig is, is de kwetsbaarheid aanwezig. Scantools kunnen helpen, maar handmatig testen is vaak nodig voor randgevallen zoals gedeeltelijke regeneratie of cross-subdomein cookiegedrag.

Wat zijn de vroege signalen van session fixation-exploitatie?

Let op één sessie die zich gedraagt alsof deze door twee gebruikers wordt gebruikt. Praktische waarschuwingssignalen zijn dezelfde sessie vanaf verschillende IP-adressen, plotselinge apparaat- of locatieverschuivingen, of toegangs­patronen die direct na het inloggen veranderen. 

Verzoeken die sessie-identificatoren in URL's naar authenticatie-endpoints bevatten, kunnen ook wijzen op een poging tot fixation in plaats van normaal browsen.

Hoe ernstig is session fixation vergeleken met andere kwetsbaarheden?

De ernst hangt af van wat het gecompromitteerde account kan doen. In situaties met lage waarde kan het als medium worden beoordeeld. In systemen met hoge waarde kan hetzelfde probleem volledige overname van accounts en misbruik van beheerdersrechten mogelijk maken. 

De CVE-voorbeelden in het artikel variëren van 4.6 tot 9.8, wat aantoont dat session fixation niet per definitie gering is; de impact wordt bepaald door privileges, blootstelling en omliggende controles.

Kan session fixation leiden tot volledige systeemcompromittering?

Het kan direct leiden tot volledige compromittering van het doelaccount, en dat kan breder worden als het slachtoffer een beheerder is. Zodra de aanvaller verhoogde rechten erft, kan deze instellingen wijzigen, gevoelige gegevens benaderen of acties uitvoeren die de hele omgeving beïnvloeden. 

De kwetsbaarheid zelf richt zich op sessies, maar de zakelijke impact kan veel verder reiken dan één login.

Is session fixation eenvoudig te vinden met beveiligingstools?

De eenvoudigste vorm is relatief makkelijk te detecteren omdat tools sessie-ID's voor en na authenticatie kunnen vergelijken. Moeilijkere gevallen betreffen gedeeltelijke regeneratie, overgeërfde cookies over subdomeinen of voorwaarden die samenhangen met transport- en browsergedrag. 

In de praktijk is scannen nuttig voor dekking, maar gericht handmatig testen blijft belangrijk om daadwerkelijke exploitatie te bevestigen.

Welke sectoren lopen het meeste risico op session fixation?

Elke sector die geauthenticeerde webapplicaties gebruikt, loopt risico, vooral waar gebruikers gevoelige gegevens of transacties verwerken. Het artikel benadrukt e-commerce, enterprise-platforms, omgevingen met gedeeld domein, gereguleerde systemen zoals in de gezondheidszorg en ICS/SCADA-implementaties. 

Het risico neemt toe wanneer organisaties vertrouwen op plug-ins, legacy sessiebeheer of meerdere applicaties die een hoofddomein delen.