Atak typu session hijacking: na czym polega przejęcie sesji i jak się chronić

Atak typu hijacking (session hijacking, przejęcie sesji) polega na przejęciu kontroli nad istniejącym połączeniem lub sesją między komunikującymi się stronami. Atakujący nie łamie hasła — wykorzystuje to, że użytkownik już się uwierzytelnił, i podszywa się pod niego, posługując się jego identyfikatorem sesji.

To również odpowiedź na pytanie, które często pojawia się w testach z egzaminów zawodowych dla techników informatyków: atak typu hijacking na serwer sieciowy charakteryzuje się przejęciem kontroli nad połączeniem między komunikującymi się komputerami. Pozostałe typowe odpowiedzi opisują inne ataki: przeciążenie aplikacji to DoS/DDoS, a zbieranie informacji o sieci i szukanie luk to rekonesans (skanowanie).

Na czym polega przejęcie sesji

Protokół HTTP jest bezstanowy, więc po zalogowaniu serwer wydaje przeglądarce identyfikator sesji — najczęściej w ciasteczku, czasem jako token w nagłówku (np. JWT). Przy każdym kolejnym żądaniu przeglądarka go odsyła, a serwer na tej podstawie wie, kim jesteś. Hasło i drugi składnik sprawdzane są tylko raz, przy logowaniu.

Kto ma identyfikator sesji, ten dla serwera jest zalogowanym użytkownikiem. Atak polega więc na zdobyciu tego identyfikatora (kradzież, przewidzenie, narzucenie) albo na wpięciu się w trwające połączenie. Skutki zależą od uprawnień ofiary: od zakupów na cudzym koncie, przez przejęcie skrzynki pocztowej, po dostęp do paneli administracyjnych firmy.

Przejęcie sesji na poziomie sieci i aplikacji

Warto rozróżnić dwa poziomy, bo egzaminy i podręczniki często mieszają je w jednym pojęciu:

Klasyczny hijacking TCP był groźny w czasach nieszyfrowanych protokołów, takich jak Telnet czy rlogin. Dziś, przy powszechnym TLS i SSH, atakujący, który wejdzie w środek połączenia, widzi zwykle tylko zaszyfrowane dane. Dlatego współczesne ataki skupiają się na poziomie aplikacji, a dokładniej na ciasteczkach sesyjnych.

Najczęstsze techniki ataku session hijacking

Kradzież ciasteczek przez infostealery (pass-the-cookie)

To obecnie jedna z najpowszechniejszych metod. Złośliwe oprogramowanie typu infostealer, zainstalowane np. z pirackiego programu, „cracka” do gry albo fałszywej aktualizacji, kopiuje z przeglądarki zapisane hasła i ciasteczka. Atakujący importuje ciasteczka do swojej przeglądarki i od razu jest zalogowany — bez hasła i bez drugiego składnika. Tak przejmowane są m.in. konta na YouTube, w mediach społecznościowych i w usługach chmurowych firm.

Phishing AiTM (adversary-in-the-middle)

Ofiara dostaje link do strony, która wygląda jak logowanie do Microsoft 365 czy Google, ale działa jako serwer pośredniczący. Użytkownik wpisuje hasło i kod 2FA, strona przekazuje je do prawdziwego serwisu, a ciasteczko sesji, które serwis odsyła, przechwytuje atakujący. Gotowe zestawy do takich ataków są szeroko dostępne, dlatego kody SMS i jednorazowe kody z aplikacji nie wystarczają jako ochrona.

Cross-site scripting (XSS)

Jeśli aplikacja ma lukę XSS, atakujący może wstrzyknąć skrypt, który odczyta document.cookie i wyśle wartość na jego serwer. Działa to tylko wtedy, gdy ciasteczko sesyjne nie ma flagi HttpOnly. Nawet z tą flagą XSS pozwala wykonywać operacje w imieniu użytkownika w jego przeglądarce. Mechanizm opisuje szerzej artykuł o atakach Cross Site Scripting.

Session sidejacking (podsłuch sieci)

Atakujący w tej samej sieci podsłuchuje ruch i wyciąga z niego ciasteczka wysyłane bez szyfrowania. W 2010 r. rozgłos zyskała wtyczka Firesheep, która robiła to jednym kliknięciem w publicznych sieciach Wi-Fi. Upowszechnienie HTTPS i HSTS w dużej mierze zamknęło ten wektor, ale nadal dotyczy stron i paneli urządzeń działających po samym HTTP. W sieci lokalnej atakujący może się wpiąć w ruch przez zatruwanie ARP albo fałszywy punkt dostępowy w stylu Evil Twin.

Session fixation (utrwalenie sesji)

Atakujący najpierw sam uzyskuje od serwera identyfikator sesji, a potem podsuwa go ofierze, np. w linku z parametrem w adresie URL. Jeśli aplikacja po zalogowaniu nie wygeneruje nowego identyfikatora, ofiara uwierzytelni sesję, którą atakujący już zna.

Przewidywalne identyfikatory sesji

Gdy identyfikator jest krótki albo generowany według prostego wzoru (licznik, znacznik czasu, skrót nazwy użytkownika), można go odgadnąć metodą prób. Współczesne frameworki generują identyfikatory kryptograficznie bezpiecznym generatorem, więc problem dotyczy głównie własnych, „domowych” implementacji.

Jak rozpoznać, że ktoś przejął Twoją sesję

Przejęcie sesji jest trudne do zauważenia, bo z punktu widzenia serwisu atakujący jest Tobą. Sygnały ostrzegawcze:

• na liście aktywnych sesji lub urządzeń widzisz logowanie z nieznanej lokalizacji, systemu albo przeglądarki,
• w koncie pojawiają się zmiany, których nie robiłeś: nowe reguły przekierowania poczty, zmieniony e-mail kontaktowy, nowe aplikacje z dostępem do konta,
• dostajesz powiadomienia o operacjach, których nie wykonywałeś,
• nagle zostajesz wylogowany z wielu serwisów naraz (atakujący zmienił hasło lub zabezpieczenia).

Większość dużych usług ma podgląd sesji. W Google znajdziesz go w ustawieniach konta, w sekcji Bezpieczeństwo → Twoje urządzenia, w Microsoft w panelu konta w zakładce urządzeń i aktywności logowania, a w serwisach Meta w Centrum kont → Hasło i zabezpieczenia → Gdzie jesteś zalogowany(-a).

Co zrobić po wykryciu przejęcia sesji

1. Wyloguj wszystkie sesje opcją „Wyloguj ze wszystkich urządzeń” — to unieważnia skradzione ciasteczka.
2. Zmień hasło, najlepiej z innego, pewnego urządzenia.
3. Sprawdź i usuń reguły przekierowania poczty, nieznane aplikacje z dostępem OAuth, dodane numery telefonów i adresy odzyskiwania.
4. Przeskanuj komputer pod kątem złośliwego oprogramowania. Jeśli źródłem był infostealer, skradzione mogły zostać hasła i ciasteczka do wszystkich serwisów w przeglądarce — zmień hasła także tam.
5. W firmie zgłoś incydent zespołowi bezpieczeństwa: administrator może unieważnić tokeny odświeżania w systemie tożsamości i przejrzeć logi logowań.

Ważne: Sama zmiana hasła nie zawsze kończy aktywne sesje. Jeśli serwis ma opcję wylogowania ze wszystkich urządzeń, użyj jej zawsze, a nie tylko „na wszelki wypadek”.

Jak zabezpieczyć aplikację przed przejęciem sesji

Jeśli tworzysz lub utrzymujesz aplikację internetową, poniższe zabezpieczenia eliminują większość opisanych technik.

Bezpieczne ciasteczka sesyjne

Ciasteczko z identyfikatorem sesji powinno mieć trzy flagi:

• Secure — wysyłane tylko przez HTTPS, więc nie da się go podsłuchać w nieszyfrowanym ruchu,
• HttpOnly — niedostępne dla JavaScriptu, co odcina kradzież przez XSS,
• SameSite=Lax lub Strict — nie jest dołączane do większości żądań z innych domen, co utrudnia także ataki CSRF.

Dodatkowo prefiks __Host- w nazwie wymusza Secure, ścieżkę / i brak atrybutu Domain, więc ciasteczka nie nadpisze subdomena:

Set-Cookie: __Host-sid=8f3c...; Path=/; Secure; HttpOnly; SameSite=Lax
Strict-Transport-Security: max-age=31536000; includeSubDomains

Nagłówek HSTS (drugi wiersz) każe przeglądarce łączyć się z serwisem wyłącznie przez HTTPS, co blokuje próby „zdegradowania” połączenia do HTTP.

Nowy identyfikator po zalogowaniu i rozsądne czasy życia

Po każdej zmianie poziomu uprawnień (logowanie, podniesienie uprawnień, zmiana hasła) wygeneruj nowy identyfikator sesji, a stary unieważnij. Przykład w PHP:

<?php
// php.ini lub ini_set(): session.use_strict_mode=1, session.use_only_cookies=1
session_set_cookie_params([
    'lifetime' => 0,
    'path'     => '/',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);
session_start();

if (zaloguj($login, $haslo)) {
    session_regenerate_id(true); // nowy ID, stara sesja usunięta
    $_SESSION['user_id'] = $uzytkownik->id;
}

Ustaw limit bezczynności (np. kilkanaście–kilkadziesiąt minut dla paneli administracyjnych) i bezwzględny maksymalny czas życia sesji. Przy wylogowaniu niszcz sesję po stronie serwera, a nie tylko usuwaj ciasteczko w przeglądarce. Nigdy nie przekazuj identyfikatora sesji w adresie URL.

Ponowne uwierzytelnienie i wykrywanie anomalii

Dla operacji wrażliwych — zmiana e-maila, hasła, danych do wypłat, dodanie klucza API — wymagaj ponownego potwierdzenia hasłem lub kluczem. Nawet przejęta sesja nie pozwoli wtedy przejąć konta na stałe. Duże platformy dodatkowo porównują parametry sesji (kraj, sieć, odcisk urządzenia) i przy nagłej zmianie wymuszają ponowne logowanie. Pomaga też zapora aplikacyjna — o tym, co realnie potrafi, przeczytasz w tekście Co to jest WAF.

Warto śledzić mechanizmy wiązania sesji z urządzeniem. Google rozwija w Chrome Device Bound Session Credentials (DBSC), w którym sesja jest powiązana z kluczem przechowywanym w module sprzętowym, np. TPM, więc samo skopiowanie ciasteczek na inny komputer nie wystarcza.

Jak chronić się jako użytkownik

• Używaj passkeys lub kluczy FIDO2 wszędzie, gdzie to możliwe. Są powiązane z prawdziwą domeną serwisu, więc fałszywa strona AiTM nie przechwyci logowania. Jak to działa, wyjaśnia artykuł FIDO2 — jak działa.
• Nie instaluj pirackiego oprogramowania, „cracków” ani rozszerzeń przeglądarki z niepewnych źródeł — to główna droga infostealerów.
• Aktualizuj system i przeglądarkę; luki w przeglądarkach bywają wykorzystywane do kradzieży danych sesji.
• Wylogowuj się z ważnych serwisów na cudzych i współdzielonych komputerach i co jakiś czas przeglądaj listę aktywnych sesji.
• Nie ignoruj ostrzeżeń przeglądarki o nieprawidłowym certyfikacie, zwłaszcza w publicznym Wi-Fi.
• Sprawdzaj adres strony przed zalogowaniem, szczególnie gdy trafiasz na nią z linku w e-mailu lub SMS-ie.

Żadne pojedyncze zabezpieczenie nie wystarcza, ale połączenie odpornego na phishing logowania, czystego urządzenia i dobrze skonfigurowanych ciasteczek po stronie serwisu sprawia, że przejęcie sesji staje się dla atakującego trudne i mało opłacalne.