Luki w OAuth i wzorce ataków

Serwery autoryzacji OAuth muszą rygorystycznie weryfikować parametr redirect_uri. Jeśli serwer zezwala na dopasowanie prefiksu lub symboli wieloznacznych (np. akceptuje dowolny adres URL zaczynający się od "https://app.example.com"), napastnik może przygotować żądanie autoryzacji przekierowujące do "https://app.example.com.attacker.com/steal" albo do otwartego przekierowania w prawidłowej domenie, kradnąc kod autoryzacyjny.

Bez ochrony przed CSRF napastnik może zainicjować przepływ OAuth i nakłonić przeglądarkę ofiary do jego ukończenia. Ofiara nieświadomie autoryzuje klienta napastnika. Zapobiega temu parametr "state" (RFC 6749): klient generuje losową wartość state, dołącza ją do żądania i sprawdza, czy w wywołaniu zwrotnym otrzymał tę samą wartość. Niezgodność powoduje przerwanie przepływu.

Na platformach mobilnych złośliwe aplikacje mogą zarejestrować ten sam niestandardowy schemat URI co prawidłowy klient OAuth i przechwytywać kody autoryzacyjne przekierowywane po uwierzytelnieniu użytkownika. PKCE (RFC 7636) zapewnia pełną ochronę: przechwycony kod jest bezużyteczny bez wartości code verifier, którą na początku przepływu wygenerowała wyłącznie prawidłowa aplikacja.

Gdy token ID lub token dostępu znajduje się we fragmencie adresu URL albo w parametrze zapytania, kolejne przejścia z tej strony powodują umieszczenie adresu URL w nagłówku Referer, co może prowadzić do wycieku tokenu do skryptów analitycznych firm trzecich lub dostawców CDN. Aby uniknąć pojawiania się tokenów w adresach URL, należy zawsze używać przepływu z kodem autoryzacyjnym i dostarczaniem tokenów za pośrednictwem kanału zaplecza.

Gdy klient obsługuje wielu dostawców OAuth, ataki typu mix-up nakłaniają klienta do wysłania kodu autoryzacyjnego uzyskanego od dostawcy A do punktu końcowego tokenów dostawcy B. Klient musi zweryfikować claim "iss" w tokenach ID oraz powiązać wywołanie zwrotne z konkretnym dostawcą, który zainicjował przepływ, korzystając z parametru state lub JARM (JWT-Secured Authorization Response Mode).

Ataki typu server-side request forgery (SSRF) wymierzone są w implementacje OAuth, które wykonują żądania HTTP po stronie serwera do adresu redirect_uri. Jeśli serwer autoryzacji pobiera redirect_uri w celu jego zweryfikowania, napastnik może podać wewnętrzny adres IP (np. http://169.254.169.254/latest/meta-data/), aby uzyskać dostęp do metadanych instancji w chmurze lub usług wewnętrznych. Rygorystyczna weryfikacja redirect_uri na podstawie listy dozwolonych adresów zapobiega temu zagrożeniu.

Wiele aplikacji używa claim adresu e-mail z tokenu ID OIDC do łączenia kont między dostawcami. Jeśli napastnik kontroluje adres e-mail odpowiadający kontu ofiary u innego dostawcy, może zarejestrować się u innego dostawcy przy użyciu tego adresu i uzyskać dostęp do konta ofiary. Ochrona polega na łączeniu kont wyłącznie na podstawie pary (iss, sub), nigdy samego adresu e-mail.

Ataki polegające na pomieszaniu algorytmów JWT wykorzystują implementacje, które ufają nagłówkowi "alg" przy wyborze algorytmu weryfikacji. Atak polega na zmianie wartości "alg" z "RS256" na "HS256" i podpisaniu tokenu kluczem publicznym serwera użytym jako sekret HMAC (ponieważ klucz publiczny jest jawny). Ochrona: w kodzie weryfikującym należy zawsze jawnie określać oczekiwany algorytm i nigdy nie ufać wartości alg z nagłówka tokenu.

Napastnicy rejestrują złośliwe klientów OAuth pod nazwami i z logotypami wyglądającymi wiarygodnie, a następnie wysyłają do celów linki phishingowe. Ofiara widzi prawdziwy ekran zgody OAuth (hostowany przez Google, Microsoft itp.) dotyczący złośliwej aplikacji i udziela jej dostępu. Ochrona: należy sprawdzić, czy client_id odpowiada oczekiwanej aplikacji; Google i Microsoft udostępniają programy weryfikacji klientów dla prawidłowych aplikacji.

Eskalacja zakresu występuje, gdy klient uzyskuje tokeny z szerszymi uprawnieniami, niż użytkownik autoryzował. Błędy implementacji polegające na pomijaniu weryfikacji zakresu w punkcie końcowym tokenów, buforowaniu tokenów z połączonymi zakresami z różnych żądań lub braku sprawdzenia, czy zakres w wystawionym tokenie nie wykracza poza zakres autoryzowany, mogą prowadzić do eskalacji uprawnień za pośrednictwem OAuth.

Implementacje OAuth należy chronić przez: stosowanie walidacji redirect_uri na podstawie dokładnego dopasowania, wymaganie PKCE dla wszystkich klientów publicznych, weryfikowanie parametru state w celu ochrony przed CSRF, wiązanie tokenów ID na podstawie (iss, sub), a nie adresu e-mail, jawne określanie oczekiwanych algorytmów JWT, żądanie minimalnych zakresów, używanie krótkotrwałych tokenów dostępu z rotacją refresh tokenów oraz kontrolowanie wyglądu ekranów zgody pod kątem ryzyka podszywania się pod markę.

Najważniejsze ataki OAuth: otwarte przekierowanie wskutek zbyt liberalnej walidacji redirect_uri (należy stosować dokładne dopasowanie), CSRF wskutek braku parametru state, przechwycenie kodu na urządzeniach mobilnych (ograniczane przez PKCE), wyciek tokenów w adresach URL, ataki typu mix-up w konfiguracjach z wieloma dostawcami (należy weryfikować iss), SSRF przez pobieranie redirect_uri po stronie serwera, kolizja claim adresu e-mail (należy używać iss+sub), pomieszanie algorytmów JWT (należy wymusić oczekiwany algorytm) oraz phishing przez fałszywe ekrany zgody.