PricingLoginStart free
Cyber Security Academy · Lekcja

Ataki na tokeny i wzmacnianie zabezpieczeń

Ochrona przepływów uwierzytelniania przed nadużyciami

Lekcja 4 z 413 kroki

Ataki na tokeny i wzmacnianie zabezpieczeń to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Tokeny jako poświadczenia

We współczesnych mechanizmach uwierzytelniania tokeny są poświadczeniami. Każdy, kto posiada ważny token typu bearer, jest traktowany jako uwierzytelniona strona do czasu jego wygaśnięcia lub unieważnienia.

  • Oznacza to, że kradzież tokenu jest równoznaczna z kradzieżą poświadczeń.
  • Wzmacnianie zabezpieczeń koncentruje się na ograniczaniu czasu życia tokenów, wiązaniu ich z posiadaczem i umożliwieniu szybkiego unieważniania.

Ta lekcja omawia ataki na tokeny OAuth/OIDC/SAML oraz mechanizmy obronne, które im przeciwdziałają.

Pomylenie algorytmów JWT

Klasyczny atak na JWT wykorzystuje nagłówek alg.

  • Akceptowanie alg: none pozwala atakującemu tworzyć sfałszowane tokeny bez podpisu.
  • W przypadku pomylenia RS256 z HS256 atakujący ponownie podpisuje token, używając publicznego klucza RSA jako sekretu HMAC.

Obrona: po stronie serwera należy przypiąć oczekiwany algorytm i nigdy nie pozwalać, aby token decydował o uruchamianej ścieżce weryfikacji.

Vulnerable: verify(token, key)  // alg taken from header
Hardened:   verify(token, key, { algorithms: ["RS256"] })
// reject alg:none, reject HS* when RS* expected

Kradzież tokenów przez XSS i logi

Najczęstszym sposobem przejęcia tokenu jest po prostu kradzież ważnego tokenu.

  • XSS odczytuje tokeny z localStorage lub pamięci.
  • Tokeny umieszczone w adresach URL wyciekają przez historię przeglądarki, nagłówki referrer i logi serwera.
  • Rozbudowane logowanie nagłówków Authorization.

W przypadku sesji przeglądarkowych należy preferować pliki cookie httpOnly, Secure, SameSite oraz usuwać tokeny z logów i adresów URL.

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
// keeps JS (and thus XSS) from reading the token

Ataki powtórzeniowe

Atak powtórzeniowy polega na ponownym użyciu przechwyconego, ważnego tokenu w celu działania jako ofiara.

  • Ograniczają go krótkie okresy ważności, jednorazowy nonce (OIDC) oraz śledzenie identyfikatorów asercji (SAML).
  • TLS uniemożliwia bierne przechwytywanie w sieci.
  • Tokeny powiązane z nadawcą uniemożliwiają ponowne użycie nawet po ich kradzieży.
Replay defenses:
  short exp + nonce/jti uniqueness
  TLS everywhere
  sender-constrained tokens (mTLS / DPoP)

Tokeny powiązane z nadawcą

Tokeny typu bearer może wykorzystać każdy, kto je posiada. Tokeny powiązane z nadawcą wiążą token z kluczem konkretnego klienta.

  • Tokeny powiązane z mTLS (RFC 8705) wiążą token z certyfikatem TLS klienta.
  • DPoP (RFC 9449) wiąże token z kluczem dowodu posiadania, którym klient podpisuje każde żądanie.

Skradziony token staje się wtedy bezużyteczny bez odpowiadającego mu klucza prywatnego.

DPoP: each request carries a signed proof JWT
  DPoP: <proof-jwt signed with client private key>
  Authorization: DPoP <access_token>

Krótki czas życia i rotacja tokenów odświeżających

Należy ograniczyć czas, przez który skradziony token pozostaje użyteczny.

  • Należy utrzymywać krótki czas życia tokenów dostępu (minuty).
  • Należy stosować rotację tokenów odświeżających: przy każdym odświeżeniu wydawany jest nowy token odświeżający, a stary zostaje unieważniony.
  • Wykrywanie ponownego użycia obróconego tokenu odświeżającego należy traktować jako sygnał kradzieży i unieważnić cały łańcuch.
On /token refresh:
  issue new RT, invalidate old RT
  if old RT presented again -> breach -> revoke family

Unieważnianie tokenów i introspekcja

Samowystarczalne tokeny JWT zachowują ważność do wygaśnięcia, co komplikuje ich unieważnianie. Należy zapewnić mechanizmy szybkiego odcinania dostępu.

  • Endpoint unieważniania (RFC 7009) unieważnia tokeny odświeżające i tokeny dostępu.
  • Introspekcja (RFC 7662) pozwala serwerowi zasobów sprawdzać status tokenu w czasie rzeczywistym.
  • W przypadku krytycznych unieważnień należy utrzymywać listę blokad według jti.
POST /introspect  token=...
  -> { "active": true, "sub": "...", "scope": "read" }
POST /revoke      token=...

Wymuszanie odbiorcy i zakresu

Ważny token nie oznacza automatycznie uprawnienia do korzystania z danego API. Należy wymuszać zgodność z jego przeznaczeniem.

  • Należy sprawdzać aud, aby token wystawiony dla innej usługi nie mógł zostać ponownie użyty w danej usłudze.
  • Należy wymuszać scope dla każdego endpointu; nie wolno zakładać, że ważny token zapewnia pełny dostęp.
  • Należy walidować iss, aby blokować tokeny od niezaufanych wystawców.

Zapobiega to ponownemu użyciu tokenów między usługami i nadużyciom typu confused deputy.

Ataki typu mix-up i ataki między dostawcami

Gdy klient obsługuje wielu dostawców tożsamości, ataki typu mix-up mogą nakłonić go do wysłania kodu lub tokenu wystawionego przez jednego IdP do innego, wybranego przez atakującego endpointu.

  • Klient traci informację o tym, z którego AS pochodzi odpowiedź.
  • Obrona: należy powiązać odpowiedzi z wystawcą za pomocą parametru iss (RFC 9207) i walidować state osobno dla każdego dostawcy.
/authorize ... &state=<provider-bound>
callback must include &iss=<expected-AS>
client verifies iss matches the AS it started with

Bezpieczne przechowywanie i przesyłanie

To, gdzie i w jaki sposób przechowywane są tokeny, określa poziom narażenia.

  • Sesje przeglądarkowe: pliki cookie httpOnly, Secure, SameSite; należy unikać localStorage.
  • Urządzenia mobilne: systemowy keychain/keystore, nigdy pliki w postaci jawnej.
  • Serwery: menedżer sekretów, szyfrowanie danych w spoczynku, zasada najmniejszych uprawnień w ograniczonym zakresie.
  • Zawsze należy stosować TLS podczas przesyłania; nigdy nie umieszczać tokenów w parametrach zapytania.

Lista kontrolna wzmacniania ochrony tokenów

Należy połączyć mechanizmy ochronne w operacyjny poziom bazowy.

  • Należy przypiąć algorytmy; odrzucać alg: none i ataki polegające na pomyleniu algorytmów.
  • Należy walidować iss, aud, exp, podpis, nonce/state.
  • Krótki TTL tokenu dostępu oraz rotacja tokenów odświeżających z wykrywaniem ponownego użycia.
  • W przypadku API o wysokiej wartości należy preferować tokeny powiązane z nadawcą (DPoP/mTLS).
  • Należy obsługiwać unieważnianie i introspekcję.
  • Należy przechowywać tokeny bezpiecznie; nie umieszczać ich w adresach URL ani logach.
Hardening baseline:
  [ ] alg pinned, none rejected
  [ ] iss/aud/exp/sig/nonce validated
  [ ] short TTL + RT rotation + reuse detection
  [ ] DPoP/mTLS for sensitive scopes
  [ ] revoke + introspect available

Szybki test: neutralizowanie skradzionych tokenów

Należy wybrać mechanizm, który najlepiej ogranicza szkody wynikające z samej kradzieży tokenu.

Odpowiedz w interaktywnej lekcji

Podsumowanie: ataki na tokeny i wzmacnianie zabezpieczeń

Najważniejsze informacje:

  • Tokeny są poświadczeniami; ich kradzież oznacza przejęcie konta.
  • Tokeny JWT należy chronić przez przypinanie algorytmów i walidację iss, aud, exp, podpisu, nonce.
  • Należy ograniczać narażenie za pomocą krótkiego czasu życia oraz rotacji tokenów odświeżających z wykrywaniem ponownego użycia.
  • Tokeny powiązane z nadawcą (DPoP/mTLS) neutralizują skradzione tokeny typu bearer.
  • Należy zapewnić unieważnianie i introspekcję, a także nie umieszczać tokenów w adresach URL, logach ani localStorage.
Bezpłatny start

Ucz się Cyber Security Academy dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy
76
Lekcje
303
Zacznij naukę bezpłatnieWyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Ataki na tokeny i wzmacnianie zabezpieczeń” jest bezpłatna?

Tak — pełny tekst „Ataki na tokeny i wzmacnianie zabezpieczeń” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Ataki na tokeny i wzmacnianie zabezpieczeń”?

Ochrona przepływów uwierzytelniania przed nadużyciami Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Ataki na tokeny i wzmacnianie zabezpieczeń”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Przepływy OAuth 2.0
  2. OpenID Connect (OIDC)
  3. SAML i federacja
  4. Ataki na tokeny i wzmacnianie zabezpieczeń
← Powrót do Cyber Security Academy