Session hijacking obchází heslo i MFA krádeží cookie. Jak útok funguje, jak se bránit a co říkají NIS2 a GDPR o hlášení incidentu.
Většina firem si kybernetickou bezpečnost spojuje s hesly a vícefaktorovým ověřováním. Session hijacking – odcizení relačního souboru cookie – je právě proto tak nebezpečný útok: obchází obě tyto obrany najednou. Útočník se nemusí přihlašovat, protože si jednoduše „vypůjčí“ již přihlášenou relaci někoho jiného.
Co přesně je relační cookie
Když se přihlásíte do webové aplikace, server vám namísto opakovaného zadávání hesla při každém požadavku vydá tzv. session token – náhodný řetězec uložený v cookie ve vašem prohlížeči. Tento token sděluje serveru: „Tato osoba je ověřená, důvěřuj jejím dalším požadavkům.“ Problém spočívá v tom, že samotný token je pro server ekvivalentem hesla i druhého faktoru dohromady – ten, kdo jej vlastní, je v systému přihlášen, bez ohledu na to, jak se k němu dostal.
Jak se cookie ve skutečnosti dostane do rukou útočníka
Způsoby, jakými může dojít k odcizení relačního tokenu, spadají do několika kategorií:
- XSS (cross-site scripting) – pokud je webová aplikace zranitelná vůči vložení škodlivého skriptu, může tento skript běžet v kontextu přihlášeného uživatele a odeslat jeho cookie útočníkovi. Toto je nejčastější způsob odcizení relačního tokenu.
- Odposlouchávání sítě (network sniffing) – při nezabezpečené HTTP komunikaci nebo v nedůvěryhodné WiFi síti (např. na letišti či v kavárně) může útočník zachytit datový provoz včetně souborů cookie, pokud není celá komunikace šifrována přes TLS.
- Malware typu infostealer – škodlivý software nainstalovaný v zařízení oběti dokáže přímo načíst uložené soubory cookie z prohlížeče a odeslat je útočníkovi, bez ohledu na to, jak silné bylo původní heslo.
- Session fixation – útočník donutí oběť použít předem známý identifikátor relace (například prostřednictvím upraveného odkazu) a jakmile se oběť přihlásí, útočník získá přístup pomocí stejného, již ověřeného tokenu.
- Škodlivá nebo nesprávně nakonfigurovaná rozšíření prohlížeče – některá rozšíření mají přístup k obsahu stránek včetně souborů cookie a mohou je exfiltrovat.
Nebezpečí tohoto útoku spočívá v tom, že se v protokolech jeví jako zcela legitimní aktivita – server totiž nemá důvod rozlišovat požadavek útočníka od požadavku skutečného uživatele, protože oba předkládají stejný platný token. Oběť si tak často všimne problému až ve chvíli, kdy se v účtu objeví neočekávaná změna.
Technická obrana: vícevrstvý přístup
Žádné opatření samo o sobě nestačí – bezpečné řízení relací vyžaduje kombinaci:
- Atributy cookie: HttpOnly (znemožňuje přístup k cookie z JavaScriptu, tedy blokuje krádež založenou na XSS), Secure (cookie se přenáší výhradně přes HTTPS), SameSite=Strict nebo alespoň Lax (omezuje odesílání cookie při cross-site požadavcích a pomáhá také proti CSRF).
- TLS a HSTS všude – žádná část komunikace by neměla probíhat přes nešifrované HTTP, hlavička HSTS navíc zabrání útokům typu „downgrade“ na HTTP.
- Obnova ID relace po přihlášení – token vydaný před autentizací by se po ní nikdy neměl dále používat; to je přímá obrana proti fixaci relace.
- Časové limity relace – kombinace časového limitu nečinnosti (odhlášení po nečinnosti) a absolutního časového limitu (relace vyprší po uplynutí stanovené doby bez ohledu na aktivitu) zkracuje časové okno, během kterého je ukradený token vůbec použitelný.
- Opakovaná autentizace při citlivých akcích – změna hesla, platební operace či změna e-mailové adresy by měly vyžadovat nové ověření identity, nikoli pouze platný token ze starší relace.
- Detekce anomálií – vazba ID relace na IP adresu a User-Agent a sledování změn těchto vlastností během relace dokáže odhalit únos relace dříve, než dojde ke škodě.
- Možnost hromadného zneplatnění relací – systém by měl být schopen na požádání zneplatnit všechny aktivní relace uživatele (například po změně hesla nebo při podezření na incident).
Proč se nejedná pouze o technickou, ale také o otázku dodržování předpisů
Pro společnosti podléhající směrnici NIS2 je únos relace vedoucí k neoprávněnému přístupu do systému poskytujícího základní nebo důležitou službu závažným kybernetickým bezpečnostním incidentem – s povinností podat Národnímu bezpečnostnímu úřadu včasné varování do 24 hodin od zjištění, podrobnější oznámení do 72 hodin a závěrečnou zprávu do jednoho měsíce (§ 24 zákona č. 69/2018 Z. z. o kybernetické bezpečnosti ve znění novely č. 366/2024 Z. z.; podrobnosti upravuje vyhláška NBÚ č. 226/2025 Z. z.).
Pokud v důsledku incidentu dojde také k neoprávněnému přístupu k osobním údajům (například prostřednictvím převzatého účtu zaměstnance s přístupem do CRM), spouští se souběžně také oznamovací povinnost podle čl. 33 GDPR– správce musí porušení ochrany osobních údajů bez zbytečného odkladu, zpravidla nejpozději do 72 hodin od zjištění, oznámit Úřadu pro ochranu osobních údajů SR. Kvalitní protokolování a monitorování proto není pouze bezpečnostním opatřením – je to také podklad, díky kterému může firma prokázat, kdy přesně k incidentu došlo a jaký měl rozsah, což je nezbytné pro splnění obou těchto souběžných povinností v jejich přísných lhůtách.
Co si z toho vzít
Únos relace (session hijacking) nám připomíná, že bezpečnost účtu nekončí přihlášením – pokračuje po celou dobu trvání relace. Společnost, která investuje pouze do silných hesel a MFA, ale zanedbává správné nastavení souborů cookie, časových limitů a monitorování relací, nechává otevřené právě to okno, přes které lze obojí obejít najednou.
S nastavením bezpečného řízení relací, přístupů i s ohlašovacími povinnostmi podle NIS2 vám rádi pomůžeme – více o této službě najdete zde.
