przejęcie sesji

Przejęcie sesji (session hijacking) to atak, w którym napastnik zdobywa identyfikator trwającej sesji zalogowanego użytkownika i posługuje się nim, by działać na jego koncie. OWASP opisuje go jako wykorzystanie mechanizmu kontroli sesji WWW, który zwykle opiera się na tokenie sesyjnym ^[1]. Napastnik nie musi znać hasła ani przechodzić uwierzytelniania: serwer uznaje go za ofiarę, bo przedstawia ważny token. MITRE ATT&CK zauważa, że skradzione ciasteczko sesji pozwala ominąć uwierzytelnianie wieloskładnikowe, ponieważ sesja jest już uwierzytelniona ^[4].

Jak działa

Protokół HTTP nie pamięta, kto wysłał poprzednie żądanie. Aplikacja po zalogowaniu wydaje więc przeglądarce losowy identyfikator, najczęściej w ciasteczku, i przy każdym kolejnym żądaniu sprawdza, do kogo należy. Kto ma ten identyfikator, ten jest zalogowany. Przejęcie sesji polega na zdobyciu go i dołączeniu do własnych żądań.

RYS. 1Przejęcie sesji skradzionym ciasteczkiem

Odmiany

OWASP wymienia kilka dróg, którymi token sesji może trafić do napastnika ^[1].

Zgadywanie identyfikatora jest dziś rzadkie, bo wymaga słabego generatora. OWASP wylicza, że przy 64 bitach entropii napastnik próbujący 10 000 identyfikatorów na sekundę potrzebowałby średnio około 585 lat, by trafić w ważną sesję ^[2]. Dlatego współczesne ataki celują w kradzież gotowego identyfikatora, a nie w jego odgadnięcie.

Podsłuch dotyczy zwłaszcza stron bez szyfrowania używanych w sieciach otwartych, co opisuje hasło zagrożenia publicznych sieci Wi-Fi. Atak przez pośrednika to dziś najczęściej phishing AiTM (adversary-in-the-middle), w którym reverse proxy przechwytuje ciasteczko wydane po poprawnym logowaniu. Session fixation działa odwrotnie: napastnik nie kradnie identyfikatora, tylko narzuca go ofierze przed zalogowaniem. MITRE opisuje tę słabość jako CWE-384, czyli ustanowienie nowej sesji bez unieważnienia istniejącego identyfikatora ^[3].

Osobną drogą jest infostealer, który kopiuje ciasteczka z plików przeglądarki na zainfekowanym komputerze. Z punktu widzenia strony wygląda to jak zwykłe żądanie z ważną sesją.

W WordPressie

WordPress przechowuje stan zalogowania w ciasteczkach. Ciasteczko wordpress_[hash] służy uwierzytelnianiu w obszarze /wp-admin/, a wordpress_logged_in_[hash] wskazuje, że użytkownik jest zalogowany i kim jest ^[5]. Zawierają nazwę użytkownika, czas wygaśnięcia i skrót potwierdzający ważność sesji; z hasła trafiają tam tylko 4 znaki jego skrótu, więc hasła nie da się z ciasteczka odtworzyć ^[5]. Nie trzeba go jednak odtwarzać: do przejęcia sesji wystarczy samo ciasteczko.

Funkcja wp_set_auth_cookie() przy opcji „Zapamiętaj mnie” ustawia ciasteczko trwałe, domyślnie ważne 14 dni, a bez niej ciasteczko wygasające po zamknięciu przeglądarki ^[6]. Czas ten zmienia filtr auth_cookie_expiration ^[5]. Przy logowaniu rdzeń tworzy też token w menedżerze sesji WP_Session_Tokens ^[6], dzięki czemu sesję można unieważnić po stronie serwera. W profilu użytkownika służy do tego przycisk „Log Out Everywhere Else”, wylogowujący pozostałe urządzenia ^[7].

Jedną z dróg kradzieży ciasteczka administratora jest XSS (Cross-Site Scripting) we wtyczce albo motywie, bo skrypt wykonuje się w przeglądarce zalogowanego użytkownika. Właściwe flagi ciasteczek ograniczają skutki: ciasteczko z flagą HttpOnly nie jest dostępne dla JavaScriptu ^[2].

Zagrożenia i skutki

Przejęta sesja daje te same uprawnienia co konto ofiary. W panelu WordPressa oznacza to możliwość instalowania wtyczek, zakładania kont i zmiany treści, a więc w praktyce przejęcie konta i często całej strony. MITRE opisuje przypadki użycia skradzionych ciasteczek do dostępu do poczty i zasobów chmurowych z pominięciem MFA ^[4].

CERT Polska opisał w czerwcu 2025 roku kampanię grupy UNC1151, która wykorzystywała błędy XSS w poczcie Roundcube (CVE-2024-42009 i CVE-2025-49113) ^[8]. Za najpoważniejszy skutek takiej podatności uznano całkowite przejęcie kontroli nad kontem poprzez przejęcie sesji użytkownika ^[8].

Jak się bronić

OWASP w ściągawce o zarządzaniu sesją zaleca ^[2]:

• identyfikatory o entropii co najmniej 64 bitów;
• nowy identyfikator po każdej zmianie poziomu uprawnień, przede wszystkim po zalogowaniu;
• ciasteczka z atrybutami Secure, HttpOnly i SameSite, najlepiej w trybie Strict, a dla najsilniejszej ochrony z prefiksem nazwy __Host-;
• limit bezczynności od 2–5 minut dla aplikacji wysokiej wartości do 15–30 minut dla aplikacji niskiego ryzyka oraz limit bezwzględny;
• unieważnienie sesji po stronie serwera przy wylogowaniu.

OWASP zaznacza, że wiązanie sesji z adresem IP albo nagłówkiem User-Agent pomaga wykrywać nadużycia, ale sprawny napastnik może te kontrole obejść ^[2]. Na poziomie całej strony pomaga HSTS (HTTP Strict Transport Security), wymuszający połączenia przez TLS. MITRE zaleca też regularne usuwanie trwałych ciasteczek w przeglądarkach ^[4].

Przy podejrzeniu przejęcia sesji administratora WordPressa trzeba unieważnić pozostałe sesje, a następnie sprawdzić, co napastnik mógł zrobić w tym czasie: listę kont, wtyczek i ostatnie zmiany treści, a przy śladach włamania przejść czyszczenie przejętej strony.