Session hijacking obchádza heslo aj MFA ukradnutím cookie. Ako útok funguje, ako sa brániť a čo hovorí NIS2 a GDPR o nahlasovaní incidentu.
Väčšina firiem si kybernetickú bezpečnosť spája s heslami a viacfaktorovým overením. Session hijacking – ukradnutie relačného cookie – je práve preto taký nebezpečný útok: obchádza obe tieto obrany naraz. Útočník sa nemusí prihlásiť, pretože si jednoducho „požičia" už prihlásenú reláciu niekoho iného.
Čo presne je relačné cookie
Keď sa prihlásite do webovej aplikácie, server vám namiesto opakovaného zadávania hesla pri každej requeste vydá tzv. session token – náhodný reťazec uložený v cookie vo vašom prehliadači. Tento token hovorí serveru „táto osoba je overená, dôveruj jej ďalším požiadavkám". Problém je, že token samotný je pre server rovnocenný s heslom aj druhým faktorom dokopy – kto ho vlastní, ten je v systéme prihlásený, bez ohľadu na to, ako sa k nemu dostal.
Ako sa cookie reálne dostane do rúk útočníka
Cesty, ktorými môže dôjsť k odcudzeniu relačného tokenu, spadajú do niekoľkých kategórií:
- XSS (cross-site scripting) – ak je webová aplikácia zraniteľná voči vloženiu škodlivého skriptu, tento skript môže bežať v kontexte prihláseného používateľa a odoslať jeho cookie útočníkovi. Toto je najčastejšia cesta k odcudzeniu session tokenu.
- Sieťové odpočúvanie (network sniffing) – na nezabezpečenej HTTP komunikácii alebo v nedôveryhodnej WiFi sieti (napr. na letisku či v kaviarni) môže útočník zachytiť dátovú prevádzku vrátane cookie, ak nie je celá komunikácia šifrovaná cez TLS.
- Infostealer malvér – škodlivý softvér nainštalovaný v zariadení obete dokáže priamo vyčítať uložené cookies z prehliadača a odoslať ich útočníkovi, bez ohľadu na to, aké silné bolo pôvodné heslo.
- Session fixation – útočník prinúti obeť použiť vopred známy session identifikátor (napríklad cez upravený odkaz), a keď sa obeť prihlási, útočník získa prístup s rovnakým, už autentifikovaným tokenom.
- Škodlivé alebo zle nastavené prehliadačové rozšírenia – niektoré rozšírenia majú prístup k obsahu stránok vrátane cookies a môžu ich exfiltrovať.
Nebezpečenstvo tohto útoku spočíva v tom, že sa v logoch javí ako úplne legitímna aktivita – server totiž nemá dôvod odlíšiť požiadavku útočníka od požiadavky skutočného používateľa, keďže obaja predkladajú rovnaký platný token. Obeť si tak často všimne problém až vo chvíli, keď sa v účte objaví neočakávaná zmena.
Technická obrana: viacvrstvový prístup
Žiadne jedno opatrenie samo osebe nestačí – bezpečné riadenie relácií vyžaduje kombináciu:
- Atribúty cookie: HttpOnly (znemožní prístup ku cookie z JavaScriptu, teda blokuje XSS-based krádež), Secure (cookie sa prenáša výhradne cez HTTPS), SameSite=Strict alebo aspoň Lax (obmedzuje odosielanie cookie pri cross-site requestoch a pomáha aj proti CSRF).
- TLS a HSTS všade – žiadna časť komunikácie by nemala prebiehať cez nešifrované HTTP, HSTS hlavička navyše zamedzí downgrade útokom na HTTP.
- Regenerácia session ID po prihlásení – token vydaný pred autentifikáciou by sa nikdy nemal používať ďalej po nej; to je priama obrana proti session fixation.
- Časové limity relácie – kombinácia idle timeoutu (odhlásenie po neaktivite) a absolútneho timeoutu (relácia vyprší bez ohľadu na aktivitu po určenom čase) skracuje okno, počas ktorého je ukradnutý token vôbec použiteľný.
- Opätovná autentifikácia pri citlivých akciách – zmena hesla, platobné operácie či zmena e-mailu by mali vyžadovať čerstvé overenie totožnosti, nie len platný token zo staršej relácie.
- Detekcia anomálií – viazanie session ID na IP adresu a User-Agent a sledovanie zmien týchto vlastností počas relácie dokáže odhaliť únos relácie skôr, než dôjde k škode.
- Možnosť hromadného zneplatnenia relácií – systém by mal vedieť na požiadanie zneplatniť všetky aktívne session tokeny používateľa (napríklad po zmene hesla alebo pri podozrení na incident).
Prečo to nie je len technická, ale aj compliance otázka
Pre firmy podliehajúce NIS2 je únos relácie vedúci k neoprávnenému prístupu do systému poskytujúceho základnú alebo dôležitú službu závažným kybernetickým bezpečnostným incidentom – s povinnosťou podať Národnému bezpečnostnému úradu včasné varovanie do 24 hodín od zistenia, podrobnejšie oznámenie do 72 hodín a záverečnú správu do jedného mesiaca (§ 24 zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti v znení novely č. 366/2024 Z. z.; podrobnosti upravuje vyhláška NBÚ č. 226/2025 Z. z.).
Ak pri incidente dôjde aj k neoprávnenému prístupu k osobným údajom (napríklad cez prevzatý účet zamestnanca s prístupom do CRM), spúšťa sa paralelne aj oznamovacia povinnosť podľa čl. 33 GDPR – prevádzkovateľ musí porušenie ochrany osobných údajov bez zbytočného odkladu, spravidla najneskôr do 72 hodín od zistenia, oznámiť Úradu na ochranu osobných údajov SR. Kvalitné logovanie a monitorovanie preto nie je len bezpečnostné opatrenie – je to aj podklad, vďaka ktorému firma vie preukázať, kedy presne k incidentu došlo a aký mal rozsah, čo je nevyhnutné pre splnenie oboch týchto paralelných povinností v ich prísnych lehotách.
Čo si z toho odniesť
Session hijacking je pripomienkou, že bezpečnosť účtu nekončí pri prihlásení – pokračuje počas celej relácie. Firma, ktorá investuje len do silných hesiel a MFA, ale zanedbá správne nastavenie cookies, časových limitov a monitorovania relácií, necháva otvorené presne to okno, cez ktoré sa dá oboje obísť naraz.
S nastavením bezpečného riadenia relácií, prístupov aj s NIS2 nahlasovacími povinnosťami vám radi pomôžeme – viac o tejto službe nájdete tu.
