Sessie Hijacking: Zo werkt het

Sessie hijacking is wanneer een aanvaller een bestaande, geauthenticeerde sessie overneemt door sessiecookies of bearer tokens te stelen of te manipuleren, wat tokens zijn die toegang bieden aan degene die ze bezit. Dit stelt de aanvaller in staat om beveiligingsmaatregelen te omzeilen die alleen bij inloggen worden toegepast, zoals rate limiting of multi-factor authenticatie (MFA).

Belangrijke Hoogtepunten

• Sterke sessie verdedigingen combineren TLS overal, verharde cookies, korte tokenlevensduur, tokenrotatie en intrekking, en anomalie-gebaseerde stap-voor-stap authenticatie. In OAuth-stijl implementaties kunnen zender-beperkte tokens (bijvoorbeeld DPoP of mTLS) de token replay verder verminderen waar dit wordt ondersteund.
• Gestolen sessietokens kunnen MFA omzeilen als MFA alleen bij de initiële login wordt afgedwongen.
• Veelvoorkomende paden zijn onder andere MitM-interceptie, XSS-token diefstal, malware of browsergegevensdiefstal, en sessiefixatie.
• Sterke sessie verdedigingen combineren TLS overal, verharde cookies, korte tokenlevensduur, tokenbinding of rotatie, en anomalie-gebaseerde herauthenticatie.
• Apparaat- en gebruikersrisicosignalen kunnen helpen beslissen wanneer de authenticatie moet worden versterkt of een sessie moet worden beëindigd.

Wat is sessie hijacking?

Bij een sessie hijacking aanval (ook bekend als een sessie overname of token replay aanval) steelt de aanvaller de sessietoken (cookie, bearer token, enz.), die wordt gebruikt om een ingelogde gebruiker te authentiseren. Dit stelt de aanvaller in staat om de gebruiker te imiteren terwijl hij de noodzaak om inloggegevens te stelen en MFA en soortgelijke verdedigingen te omzeilen, vermijdt. Veelvoorkomende doelwitten van deze aanvallen zijn consumentenwebapps, SaaS-sessies, VPN-portalen, externe toegangssessies en bevoorrechte admin consoles.

Hoe werkt sessie hijacking van begin tot eind?

Sessie hijacking aanvallen richten zich op het stelen van een token om zich voor te doen als een legitieme gebruiker. Een aanvalsstroom kan er als volgt uitzien:

• Wacht op of laat de gebruiker een geldige sessie creëren.
• Steal een sessiecookie of bearer token via malware, kwaadaardige scripts, browserextensies of andere middelen.
• Hijack de sessie door een verzoek naar de server te sturen met de gestolen cookie.
• Voer kwaadaardige acties uit op het account van de gebruiker met de gestolen token voordat deze verloopt of wordt ingetrokken.

Sessiekapingaanvallen zijn afhankelijk van toegang tot de token, die op verschillende plaatsen kan worden gevonden, waaronder browseropslag, cookies, autorisatieheaders, app-geheugen en apparaatsystemen. Aanvallers hebben mogelijk ook manieren nodig om te voorkomen dat herauthenticatie of risicocontroles worden geactiveerd, zoals het overeenkomen van apparaatspecifieke vingerafdrukken, IP-reputatie of normale gedrags patronen.

Meest voorkomende soorten sessiekaping

Sessiekaping kan op verschillende manieren worden uitgevoerd. Enkele bekende methoden zijn:

• Sessiefixatie: Bij een sessiefixatie-aanval wordt de gebruiker gedwongen zich te authentiseren met een sessie-ID die bekend is bij de aanvaller, zoals een ID die is ingebed in een phishinglink. Dit kan gebeuren doordat sessie-ID’s niet worden gegenereerd na inloggen, voorspelbare tokens of zwakke sessie-invalidatie.
• Token Diefstal via XSS: Cross-site scripting (XSS) embed kwaadaardige scripts binnen een webpagina. Wanneer gebruikers de site bezoeken, kunnen deze scripts sessietokens stelen. De Secure, HttpOnly en SameSite-vlaggen kunnen helpen dit te voorkomen door scripts te blokkeren die toegang hebben tot sessiecookies.
• Malware/Browsersysteem Diefstal: Malware die op het systeem van een gebruiker is geïnstalleerd of in kwaadaardige browserextensies kan cookies stelen uit het bestandssysteem, de browser en andere caches.
• Zijjacking: Zijjacking-aanvallen omvatten het afluisteren van sessietokens uit netwerkverkeer. Dit is grotendeels verouderd door het gebruik van TLS om netwerkverkeer te versleutelen.
• MitM Afluisteren: Bij een man-in-the-middle (MitM) of on-path aanval plaatst een aanvaller zichzelf in het communicatiepad tussen de gebruiker en de server. Dit stelt hen in staat om sessiecookies van het webverkeer van de gebruiker te onderscheppen. Echter, het gebruik van TLS maakt dit ook moeilijker uit te voeren.

Al deze methoden kunnen toegang bieden tot het sessietoken of cookie. Vervolgens wordt het gebruikt in een cookie-herhalings- of “pass-the-cookie”-aanval, waarbij de browser of API-client van de aanvaller het gebruikt om de legitieme gebruikerssessie over te nemen.

De tekenen van een gekaapte sessie

Gekapte sessies houden in dat een aanvaller een sessie van hun apparaat/browser gebruikt die ze van een legitieme gebruiker hebben genomen. Enkele indicatoren hiervan zijn:

• Onmogelijk reizen
• Nieuwe apparaatsignatuur
• Ongebruikelijke ASN of geolocatie
• Gelijktijdige sessies
• Abnormale aanvraagpatronen
• Pogingen tot privilege-escalatie
• Atypische beheerdersacties
• Tokenhergebruik vanaf twee locaties
• Herhaling van sessiecookies zonder normale browserheaders
• Plotselinge verandering in cliëntkenmerken

Hoewel deze allemaal kunnen wijzen op een sessie-hijackingaanval, zijn ze niet allemaal perfect. Bijvoorbeeld, mobiele IP-wisselingen, VPN-uitgangswijzigingen of een gedeelde NAT kunnen valse positieven veroorzaken. Om deze reden biedt het correlateren van meerdere indicatoren detectie met een hogere betrouwbaarheid.

Telemetrie die helpt om sessieovername te bevestigen

Verschillende logs en telemetriebronnen kunnen helpen om een vermoedelijke sessieovername-aanval te bevestigen, waaronder:

• Web/App Logs: Authenticatie-evenementen, patronen van tokenvernieuwing en sessie-uitgifte en intrekking.
• Identiteitslogs: Aanmeldingen bij de identiteitsprovider (IdP), triggers voor voorwaardelijke toegang en stap-om-uitdagingen.
• Netwerk- en Eindpunt Signaleringen: Risicovolle bestemmingen, malwarewaarschuwingen, signalen van browserintegriteit en veranderingen in apparaathouding.

Gevolgen van Sessieovername

Sessieovername-aanvallen kunnen aanzienlijke zakelijke gevolgen hebben, zoals overname van accounts zonder diefstal van wachtwoorden, toegang tot gegevens, frauduleuze transacties en compromittering van de beheerdersconsole. Vaak zijn websessies een belangrijk doelwit omdat browsers tokens vasthouden, gebruikers apparaten hergebruiken en veel apps aannemen dat “sessie gelijk staat aan vertrouwen.”

Sessieovername is zo gevaarlijk omdat het belangrijke identiteitsverdedigingen ondermijnt, waaronder:

• MFA Omzeiling: Sessieovername kan MFA omzeilen als MFA alleen bij aanmelding wordt toegepast. Sessie-tokens blijven geldig na aanmelding, waardoor een aanvaller een sessie kan overnemen en MFA kan omzeilen. Beste praktijken om dit te voorkomen zijn stap-om-authenticatie, continue validatie, korte token TTL’s en intrekking van tokens voor risicovolle sessies.
• Onwerkzaam ZTNA: Standaard is zero-trust network access (ZTNA) ontworpen om de privileges die aan legitieme gebruikers worden verleend te beperken. Bij sessieovername wordt een aanvaller beschouwd als een legitieme gebruiker, waardoor ZTNA geen bescherming biedt. Continue verificatie beheert dit risico door regelmatig identiteit, apparaathouding en risicosignalen gedurende de sessie opnieuw te controleren, niet alleen bij aanmelding.

Praktische verdedigingen tegen sessie-overname

Organisaties kunnen verdedigingen tegen sessie-overname op meerdere niveaus implementeren. Dit omvat expliciet werken aan het voorkomen van sessie-overname en het beschermen van sessietokens tegen mogelijke blootstelling.

Sessiebeheercontroles die de herhalingswaarde verminderen

Sessie-overname-aanvallen omvatten het gebruik van een gestolen token om een legitieme sessie over te nemen. Enkele manieren om dit risico te verminderen zijn:

• Korte levensduur en herauthenticatie voor gevoelige acties.
• Tokenrotatie, intrekkingslijsten, anomalie-gedreven ongeldigverklaring.
• Detectie van gelijktijdig tokengebruik vanuit verschillende cliëntcontexten.

Essentiële browser- en cookie-versterking

Sessie-overname-aanvallen vereisen de mogelijkheid om een token te stelen. Enkele manieren om dit te voorkomen zijn:

• Gebruik van Secure, HttpOnly en SameSite HTTP-vlaggen om diefstal van cookies via scripts (XSS) en cross-site scripting (CSF) te voorkomen.
• Handhaaf het gebruik van HTTPS voor alle pagina’s.
• Bescherming van lokaal opgeslagen tokens (localStorage-tokens zijn toegankelijk voor scripts).

Voorkomen van sessie-overname-aanvallen

Sessie-overname is een veelvoorkomende bedreiging, aangezien authenticatietokens waardevol zijn en een aanvaller in staat stellen om login-gerichte verdedigingen te omzeilen. Organisaties hebben gelaagde verdedigingen en continue risicobeoordeling nodig om gecompromitteerde sessies na de initiële login te identificeren.

Bij het zoeken naar sessie-overname-aanvallen, let op:

• Gedetecteerde sessie-anomalieën
• Tijd om in te trekken
• Verhoogde authenticatiepercentages voor risicovolle gebeurtenissen
• Vermindering van token-herhalingsincidenten.

VEELGESTELDE VRAGEN

Kan sessieovername plaatsvinden, zelfs als MFA is ingeschakeld?

Ja, omdat MFA alleen de inloggebeurtenis beschermt, niet de sessietoken die na inloggen wordt gebruikt. Als een aanvaller de sessiecookie of token steelt, kan hij deze gebruiken om toegang te krijgen tot een geauthenticeerde sessie. Beheersmaatregelen zoals verhoogde authenticatie voor gevoelige acties, korte sessielevensduur, tokenrotatie en intrekking bij verdachte activiteiten verminderen het risico hierop, plus organisaties kunnen signalen zoals een nieuw apparaat, ongebruikelijke locatie of abnormaal gedrag voor een geauthenticeerde sessie monitoren.

Is sessieovername hetzelfde als credential stuffing?

Nee, credential stuffing gebruikt gecompromitteerde gebruikersnaam/wachtwoordparen om in te loggen als de gebruiker, en MFA en snelheidsbeperkingen kunnen helpen dit te voorkomen. Sessieovername neemt een bestaande sessie over, wat kan worden verminderd door sterke sessiebeheer en tokenbescherming.

Wat is sessiefixatie en hoe wordt het voorkomen?

Sessiefixatie is wanneer de aanvaller de slachtoffer dwingt om zich te authentiseren met een sessie-ID die bekend is bij de aanvaller. Dit is problematisch als een applicatie geen nieuwe sessie-ID aanmaakt na authenticatie of privilegeveranderingen. Beste praktijken om dit te voorkomen zijn onder andere het regenereren van sessie-ID’s bij inloggen en privilegeverhoging, het ongeldig maken van oude sessies, het afwijzen van sessie-ID’s in URL’s en het waarborgen van veilige cookie-afhandeling.

Welke logs of signalen helpen een overgenomen sessie te bevestigen?

Overgenomen sessies kunnen worden geïdentificeerd met behulp van logs van webapplicaties en identiteitsproviders, inclusief gegevens over sessie-uitgifte, verversingspatronen, aanmeldgebeurtenissen, triggers voor voorwaardelijke toegang en uitlog- of intrekkingsgebeurtenissen. Hoge vertrouwensindicatoren van een gecompromitteerde sessie zijn dezelfde sessietoken die vanuit twee verre locaties wordt gebruikt, gelijktijdige sessies die niet overeenkomen met normale gebruikerspatronen, of plotselinge veranderingen in clientkenmerken. Detectie kan worden versterkt met signalen zoals veranderingen in apparaathouding, endpointdetecties, verdachte browseractiviteit en abnormale actievolgordes binnen de app.

Stoppen Secure, HttpOnly en SameSite cookies volledig sessieovername?

Deze vlaggen zijn ontworpen om het risico te verminderen dat sessiecookies worden gestolen door scripts, downgrade-aanvallen en sommige cross-site misbruikpatronen, maar ze voorkomen deze aanvallen niet. Bijvoorbeeld, een aanvaller kan een sessiecookie stelen met malware die op het apparaat van de gebruiker is geïnstalleerd. Het gebruik van TLS overal, CSP, XSS-preventie, kortdurende sessies, tokenrotatie en anomalie-gedreven stap-voor-stap authenticatie kan helpen het risico op sessieovername te verminderen.