--- id: CP-048 slug: kradziez-ciasteczek-sesji-tokeny-okaziciela lang: pl title: Kradzież ciasteczek sesji i tokeny okaziciela description: Skradzione ciasteczko sesji pozwala podszyć się pod pracownika bez hasła i drugiego składnika. Mechanizm, prawdziwy przypadek i odruchy. canonical_url: https://startbrain.io/cyberpedia/pl/articles/kradziez-ciasteczek-sesji-tokeny-okaziciela/ markdown_url: https://startbrain.io/cyberpedia/pl/articles/kradziez-ciasteczek-sesji-tokeny-okaziciela.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, „Kradzież ciasteczek sesji i tokeny okaziciela”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/pl/articles/kradziez-ciasteczek-sesji-tokeny-okaziciela/ (CC BY 4.0) wing: 1 theme: master_passwords reflex: cr-023 schema: G3 updated: "2026-11-03" translations: pl: https://startbrain.io/cyberpedia/pl/articles/kradziez-ciasteczek-sesji-tokeny-okaziciela/ fr: https://startbrain.io/cyberpedia/fr/articles/vol-cookies-session-jetons-porteurs/ en: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ de: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ es: https://startbrain.io/cyberpedia/es/articles/robo-cookies-sesion-tokens-portador/ it: https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/ nl: https://startbrain.io/cyberpedia/nl/articles/diefstal-sessiecookies-bearer-tokens/ pt: https://startbrain.io/cyberpedia/pt/articles/roubo-cookies-sessao-tokens-portador/ sources: - "n": 1 title: Steal Web Session Cookie publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 2 title: "Use Alternate Authentication Material: Web Session Cookie" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/004/ accessed: "2026-11-03" - "n": 3 title: Session hijacking attack publisher: OWASP url: https://community.owasp.org/attacks/Session_hijacking_attack accessed: "2026-11-03" - "n": 4 title: Steal Application Access Token publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 5 title: NIST Special Publication 800-63B publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63b.html accessed: "2026-11-03" - "n": 6 title: "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud" publisher: Microsoft url: https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ published: "2022-07-12" accessed: "2026-11-03" - "n": 7 title: Session Management - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: Browser Session Hijacking publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1185/ accessed: "2026-11-03" --- # Kradzież ciasteczek sesji i tokeny okaziciela Gdy pracownik loguje się do poczty lub narzędzia online, usługa przekazuje mu niewielki element identyfikacyjny, najczęściej ciasteczko (cookie), który dowodzi, że jest już uwierzytelniony. Jeśli atakujący zdobędzie ten element, może wejść jako ofiara, nie znając jej hasła [1]. Po stronie pracownika zwykle nie widać niczego: sesja trwa dalej, praca również. Ta strona wyjaśnia, skąd bierze się kradzież, co atakujący z nią robi i co każdy może zrobić, by zmniejszyć ryzyko. ## W 30 sekund - Gdzie to się zdarza: na stanowisku pracy (złośliwe oprogramowanie), na fałszywej stronie, która przekazuje dalej prawdziwą stronę logowania [1], albo w przejętej przeglądarce [8]. - Czego chce atakujący: przejąć sesję już otwartą, czytać wiadomości i działać w imieniu ofiary, omijając niektóre drugie składniki uwierzytelniania [2]. - Odruch: wylogowywać się z usług po zakończeniu pracy, unieważniać swoje sesje w razie wątpliwości, regularnie zamykać sesje przeglądarki. - Jeśli już się stało: bez zwłoki powiadomić wsparcie IT, ponieważ skradziona sesja pozostaje użyteczna, dopóki jest aktywna [2]. ## Pytania wprost ### Czym jest ciasteczko sesji? Po udanym logowaniu wiele aplikacji internetowych używa ciasteczka sesji jako dowodu uwierzytelnienia [1]. Protokół sieciowy sam z siebie nie pamięta, kto jest kim w kolejnych żądaniach: serwer wysyła więc przeglądarce token, który przeglądarka okazuje przy każdej wymianie [3]. ### Czym jest token dostępu i czym różni się od ciasteczka? Token dostępu służy do wysyłania autoryzowanych żądań w imieniu użytkownika lub usługi. Jest powszechny w aplikacjach online (SaaS) i usługach chmurowych [4]. Oba obiekty mają tę samą słabość: kto go okaże, zostaje uznany za osobę, która go uzyskała. Dokument NIST SP 800-63B, wersja zastąpiona od 1 sierpnia 2025 r. przez SP 800-63-4, wskazywał zresztą, że obecności tokenu dostępu OAuth nie należy interpretować jako obecności użytkownika bez innych sygnałów oraz że taki token może pozostać ważny długo po zakończeniu sesji uwierzytelniania [5]. ### Czy mój drugi składnik mnie nie chroni? Chroni logowanie, a nie sesję, która po nim następuje. MITRE wskazuje, że ta technika omija niektóre protokoły uwierzytelniania wieloskładnikowego, skoro sesja jest już uwierzytelniona [2]. Microsoft zaznacza, że nie jest to luka w uwierzytelnianiu wieloskładnikowym: skradzione ciasteczko uwierzytelnia atakującego niezależnie od metody logowania użytkownika [6]. ### Jak długo skradzione ciasteczko pozostaje użyteczne? Ciasteczka często pozostają ważne przez długi czas, nawet jeśli aplikacja nie jest aktywnie używana [1]. Atakujący może z nich korzystać, dopóki ciasteczko jest aktywne [2]. OWASP zauważa też, że limit czasu bezczynności nie ogranicza atakującego, który przejął sesję: może on generować aktywność, by utrzymać ją otwartą [7]. ## W skórze atakującego Atakujący szuka elementu nadającego się do ponownego użycia, a nie sekretu do odgadnięcia. Ciasteczka znajdują się na dysku, w pamięci przeglądarki i w ruchu sieciowym do systemów zdalnych. Inne aplikacje na stanowisku mogą też przechowywać w pamięci ciasteczka uwierzytelniające, na przykład te, które łączą się z usługami chmurowymi [1]. Po zdobyciu ciasteczka atakujący importuje je do przeglądarki, którą kontroluje. Następnie korzysta ze strony jak użytkownik, dopóki sesja jest aktywna. Może przeglądać poufne informacje, czytać wiadomości e-mail lub robić wszystko, na co konto ofiary ma uprawnienia [2]. W przypadku tokenu dostępu opisaną drogą jest phishing: atakujący rejestruje podstawioną aplikację i wysyła link, by skłonić ofiarę do udzielenia jej dostępu. Gdy token zostanie przyznany, aplikacja może uzyskać potencjalnie długotrwały dostęp do konta [4]. Tokeny dostępu mają czasem ograniczony czas życia, ale atakujący może też ukraść token odświeżania, który daje mu nowe tokeny dostępu bez pytania użytkownika o cokolwiek [4]. ## Co widać na ekranie Pracownik nie widzi niczego: alerty mogą istnieć po stronie administratora (zob. niżej). W przypadku fałszywej strony przekaźnikowej (opisanej niżej) strona wygląda dokładnie jak prawdziwa: jedyną widoczną różnicą jest adres [6]. Po wpisaniu hasła ofiara zostaje przekierowana na legalną stronę, a atak trwa w tle [6]. Oto zneutralizowana ilustracja adresu fałszywej strony przekaźnikowej. Jest zmyślona na potrzeby przykładu. ```text Ilustracja (adres fikcyjny, zneutralizowany): hxxps://login[.]exemple-connexion[.]invalid/ [strona identyczna z prawdziwą stroną logowania, różni się tylko adres] ``` Istnieje kilka pośrednich oznak. Jeśli atakujący loguje się, gdy ofiara pracuje, po stronie administratora mogą pojawić się alerty o „niemożliwej podróży” [6]. Inną oznaką są nieznane reguły skrzynki odbiorczej: w opisanym niżej przypadku atakujący utworzył taką regułę, aby ofiara nie widziała odpowiedzi swojego celu [6]. ## Pod maską Cytowane tu źródła opisują trzy drogi kradzieży. - Złośliwe oprogramowanie kradnące dane: szkodliwe programy atakują ciasteczka przeglądarek obecnych na stanowisku [1]. Niektóre wyodrębniają ciasteczko sesji i wysyłają je na serwer atakującego [1]. - Fałszywa strona przekaźnikowa: w ataku zwanym adversary-in-the-middle (pośrednik w komunikacji) atakujący umieszcza serwer proxy między użytkownikiem a atakowaną stroną. W ten sposób przechwytuje hasło i ciasteczko sesji [6]. Darmowe narzędzia, takie jak Evilginx2, Modlishka i Muraena, automatyzują ten proces [6]. - Przejęta przeglądarka: atakujący może wstrzyknąć oprogramowanie do przeglądarki, aby odziedziczyć ciasteczka użytkownika, sesje HTTP i certyfikaty klienta, a następnie wykorzystać je do wejścia do uwierzytelnionego intranetu [8]. Ta technika może też omijać uwierzytelnianie dwuskładnikowe [8]. Może wymagać szczególnych uprawnień na stanowisku [8]. Dlaczego ponowne odtworzenie sesji działa? Ciasteczko jest dowodem zalogowania: serwer nie sprawdza hasła ponownie przy każdej stronie [6]. NIST SP 800-63B dopuszcza inne metody bezpiecznej identyfikacji urządzenia, w tym wzajemny TLS i wiązanie tokenu (token binding) [5]. OWASP zaleca powiązanie identyfikatora sesji z innymi właściwościami klienta, takimi jak adres IP lub User-Agent. Przyznaje jednak, że zręczny atakujący może obejść tę kontrolę, na przykład dzieląc tę samą sieć z ofiarą lub kopiując User-Agent [7]. Co do czasów, OWASP podaje typowe limity bezczynności od 2 do 5 minut dla aplikacji o wysokiej wartości i od 15 do 30 minut dla aplikacji o niskim ryzyku. Dla pracownika biurowego, który używa aplikacji przez cały dzień, podaje bezwzględny limit od 4 do 8 godzin [7]. NIST SP 800-63B, zastąpiony od 1 sierpnia 2025 r. przez SP 800-63-4, wymagał, aby sekrety sesji były usuwane lub unieważniane przy wylogowaniu [5]. ## Analizy incydentów ### Kampania phishingowa z fałszywą stroną przekaźnikową przeciwko Microsoft 365 (udokumentowana 12 lipca 2022 r.) 12 lipca 2022 r. Microsoft opublikował analizę kampanii na dużą skalę. Według jego danych próbowała ona objąć ponad 10 000 organizacji od września 2021 r. [6]. Atakujący używali stron przekaźnikowych, by kraść hasła i przejmować sesję ofiary, nawet gdy uwierzytelnianie wieloskładnikowe było włączone [6]. W jednej z zaobserwowanych fal wiadomość e-mail z załącznikiem HTML zapowiadała wiadomość głosową. Załącznik wyświetlał fałszywy pasek pobierania, a potem przekierowywał na stronę przekaźnikową zbudowaną za pomocą Evilginx2, która odtwarzała stronę logowania organizacji [6]. Ofiara wpisywała dane logowania, była przekierowywana na legalną stronę office.com, a atakujący był tymczasem uwierzytelniony w jej imieniu [6]. Dalszy ciąg miał prowadzić do oszustwa płatniczego. Według Microsoftu między kradzieżą a początkiem oszustwa upłynęło czasem zaledwie pięć minut. Atakujący używał skradzionego ciasteczka, by wejść do poczty online, czasem z ciasteczkiem, które już niosło oznaczenie uwierzytelniania wieloskładnikowego [6]. Następnie szukał wymian związanych z płatnościami, usuwał pierwotną wiadomość phishingową i tworzył regułę skrzynki odbiorczej, która archiwizowała i oznaczała jako przeczytane odpowiedzi swojego celu, aby ofiara niczego nie zauważyła [6]. Na koniec usuwał własne odpowiedzi z folderów elementów wysłanych i usuniętych [6]. Microsoft zaleca uwierzytelnianie odporne na phishing (FIDO 2.0 lub certyfikaty) oraz zasady dostępu warunkowego, które oceniają każdą próbę użycia skradzionego ciasteczka [6]. ## Co Pan/Pani robi Te czynności pochodzą z cytowanych tu źródeł. Ich skutkiem jest skrócenie czasu lub ograniczenie zasięgu skradzionej sesji, a nie gwarancja, że do kradzieży nie dojdzie. - Wylogowywać się jawnie z usług po zakończeniu pracy. OWASP wskazuje, że zamknięcie przeglądarki nie wymusza wylogowania w niezawodny sposób, i zaleca jawne wylogowanie wraz z limitami czasu po stronie serwera [7]. - Unieważniać swoje sesje, gdy pojawi się wątpliwość (zainfekowane stanowisko, podejrzana strona logowania). Cytowane tu źródła nie opisują procedury: podaje ją wsparcie IT firmy. - Regularnie zamykać sesje otwarte w przeglądarce. MITRE zaleca regularne zamykanie wszystkich sesji przeglądarki [8]. - Sprawdzać adres przed wpisaniem hasła: adres jest jedyną widoczną różnicą między fałszywą stroną przekaźnikową a prawdziwą [6]. - Zgłaszać każdą wątpliwość wsparciu IT bez zwłoki: dopóki sesja jest aktywna, atakujący może z niej korzystać [2]. Po stronie firmy MITRE wskazuje konfigurację przeglądarek tak, by regularnie usuwały trwałe ciasteczka [2]. ## Źródła 1. MITRE ATT&CK, „Steal Web Session Cookie”. https://attack.mitre.org/techniques/T1539/ (dostęp 3 listopada 2026) 2. MITRE ATT&CK, „Use Alternate Authentication Material: Web Session Cookie”. https://attack.mitre.org/techniques/T1550/004/ (dostęp 3 listopada 2026) 3. OWASP, „Session hijacking attack”. https://community.owasp.org/attacks/Session_hijacking_attack (dostęp 3 listopada 2026) 4. MITRE ATT&CK, „Steal Application Access Token”. https://attack.mitre.org/techniques/T1528/ (dostęp 3 listopada 2026) 5. NIST, „NIST Special Publication 800-63B”. https://pages.nist.gov/800-63-3/sp800-63b.html (dostęp 3 listopada 2026) 6. Microsoft, „From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud”, 12 lipca 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (dostęp 3 listopada 2026) 7. OWASP, „Session Management - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (dostęp 3 listopada 2026) 8. MITRE ATT&CK, „Browser Session Hijacking”. https://attack.mitre.org/techniques/T1185/ (dostęp 3 listopada 2026) --- Źródło oryginalne: Cyberpedia, publiczna encyklopedia cyberbezpieczeństwa i AI wydawana przez Brain. Wersja kanoniczna: https://startbrain.io/cyberpedia/pl/articles/kradziez-ciasteczek-sesji-tokeny-okaziciela/ Możesz swobodnie wykorzystywać ten tekst na licencji CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), pod warunkiem podania „Brain, Cyberpedia” wraz z odnośnikiem do powyższego adresu.