Session hijacking treedt op wanneer een aanvaller de geldige sessie-identifier van een gebruiker steelt of zich voordoet om ongeautoriseerde toegang tot webapplicaties te verkrijgen. Dit kan op verschillende manieren gebeuren, waaronder XSS, netwerk-sniffing of voorspelbare sessietokens. Preventie omvat veilig sessiebeheer, gebruik van HTTPS en implementeren van juist sessie-timeout beleid.
Nadat een gebruiker inlogt, geeft de server een sessie-identificatie uit, meestal opgeslagen in een cookie of token, die bij elk volgend verzoek in de plaats staat van de login. Session hijacking is elke techniek waarmee een aanvaller die identificatie kan bemachtigen of reproduceren en gebruiken om zich als de gebruiker voor te doen, zonder ooit het wachtwoord te leren. Diefstal kan op meerdere manieren gebeuren: cross-site scripting of een kwaadaardig third-party script dat de cookie leest, netwerk-sniffing van onversleuteld verkeer, malware op het apparaat, of het raden van zwakke, voorspelbare tokens. Zodra de aanvaller een geldig sessie-ID afspeelt, behandelt de applicatie hun verzoeken als die van de echte gebruiker, totdat de sessie verloopt of wordt ingetrokken.
Een gestolen sessie verleent direct geauthenticeerde toegang, dus het omzeilt de login volledig, inclusief multi-factor-authenticatie die alleen bij het inloggen werd gecontroleerd. Dit is de kern van een pass-the-cookie-aanval: met een geldige sessiecookie heeft de aanvaller vaak geen wachtwoord en geen tweede factor nodig. Afhankelijk van het account kunnen ze private data lezen, aankopen doen, geld verplaatsen of instellingen wijzigen om de echte gebruiker buiten te sluiten. Omdat de verzoeken een legitieme sessie dragen, zien ze er normaal uit voor de server, dus detectie hangt vaak af van subtielere signalen zoals een plotselinge verandering van apparaat of locatie in plaats van een duidelijke fout.
Stuur sessiecookies alleen over HTTPS, markeer ze als HttpOnly zodat client-side JavaScript ze niet kan lezen, en stel het SameSite-attribuut in om cross-site verzending te beperken. Gebruik lange, willekeurige tokens, roteer ze bij wijzigingen in rechten, en dwing verstandige time-outs en server-side intrekking af. Omdat een veelvoorkomende diefstalroute een kwaadaardig of gecompromitteerd third-party script is dat cookies of tokens in de browser leest, is het sturen van client-side code van belang: cside stuurt third-party scripts via een Script-methode, analyseert de payload, en kan een script dat sessiegegevens probeert te exfiltreren in realtime blokkeren, met behoud van een forensisch verslag. Het detecteren van een apparaatmismatch op een hergebruikte sessie kan ook een gekaapt token markeren.
Het is session hijacking met een gestolen sessiecookie. Omdat de cookie al een geauthenticeerde sessie vertegenwoordigt, kan een aanvaller die hem bemachtigt hem in zijn eigen browser importeren en toegang krijgen zonder het wachtwoord of een tweede factor. Het is een geliefde manier om multi-factor-authenticatie achteraf te omzeilen.
Nee. HttpOnly belet client-side JavaScript, inclusief XSS-payloads, om een cookie te lezen, wat één grote diefstalroute afsluit. Maar sessies kunnen nog steeds worden gekaapt via netwerk-sniffing, apparaatmalware of voorspelbare tokens. Het is een belangrijke laag, het best gecombineerd met HTTPS, SameSite, sterke tokengeneratie en time-outs.
We answer client-side security questions every day. Bring yours.