Podatności Authlib

Authlib w wersji 1.7.2 i niższych zawiera podatność, w której metadane JSON discovery są buforowane bez walidacji lub powiązania z originem issuera. Pozwala to zatrutemu discovery response na zastąpienie wszystkich wartości endpointów wartościami kontrolowanymi przez atakującego, zamiast URL endpointów współdzielących origin ze skonfigurowanym URL metadanych serwera.

Biblioteka Authlib w wersji v1.7.2 i wcześniejszych zawiera podatność polegającą na obejściu weryfikacji podpisu. Metoda JsonWebSignature.deserialize_json() akceptuje obiekt JWS w formacie JSON Serialization i zwraca ładunek jako pomyślnie zweryfikowany bez sprawdzania podpisu i bez wymagania klucza kryptograficznego.

Podatność w bibliotece Authlib (wersje przed 1.6.9) umożliwia atakującemu wstrzyknięcie klucza JWK do nagłówka JWT. Pozwala to na podrobienie dowolnego tokena JWT, który przechodzi weryfikację podpisu, ponieważ biblioteka używa klucza dostarczonego przez atakującego zamiast zaufanego klucza serwera.

Biblioteka Authlib w wersjach od 1.6.5 do 1.6.6 nieprawidłowo przepuszczała złośliwe tokeny JWT z algorytmem 'none' i pustym podpisem, co omijało weryfikację podpisu. Problem został naprawiony w wersji 1.6.7.

Authlib (biblioteka Python do OAuth/OIDC) w wersjach od 0.15 do 1.9.1 zawiera błąd w implementacjach ClientConfigurationEndpoint.authenticate_client i check_permission, które nie weryfikują, czy poświadczenie należy do docelowego klienta. Może to pozwolić na odczyt, modyfikację lub usunięcie rejestracji innego klienta. Problem naprawiono w wersji 1.9.1.

W bibliotece Authlib przed wersją 1.9.0 implementacja RFC 9101 JWTAuthenticationRequest przekazuje kontrolowany przez klienta parametr request_uri do hooka get_request_object() przed zastosowaniem polityki docelowej lub rejestracyjnej. W instalacjach, w których integrator zaimplementował ten hook jako nieograniczone pobieranie HTTP, zdalny atakujący może wymusić żądania do wewnętrznych lub niepożądanych adresów URL.

W Authlib przed wersją 1.9.0 metoda OpenIDImplicitGrant.validate_authorization_request() sprawdza kontrolowany przez klienta surowy parametr request.payload.scope pod kątem openid po tym, jak nadrzędny grant przefiltrował dozwolone zakresy do request.scope. Zarejestrowany klient uprawniony do typu odpowiedzi ID token, ale nie do zakresu openid, może dodać openid i otrzymać podpisany ID token z danymi użytkownika.

W Authlib przed wersją 1.9.0 domyślna metoda RFC 7523 JWTBearerGrant.get_audiences() zwraca pustą listę, przez co weryfikacja roszczeń wymaga jedynie istnienia roszczenia aud bez dopasowania do bieżącego serwera autoryzacji. Atakujący posiadający ważną asercję dla innej usługi może przedstawić ją serwerowi współdzielącemu klucz podpisujący i uzyskać token dostępu.

W Authlib przed wersją 1.9.0 metoda OpenIDMixin.parse_id_token() odczytuje decyzję nonce_supported z nieufnego ID tokena i ustawia oczekiwane nonce na null, gdy roszczenie ma wartość logiczną false. W klientach implicit i hybrid atakujący z przechwyconym prawidłowo podpisanym tokenem może ominąć powiązanie nonce z sesją i odtworzyć token ofiary w swojej sesji.

Authlib to biblioteka Pythona do budowy serwerów OAuth i OpenID Connect. W wersjach przed 1.9.1 funkcje OctKey.import_key() oraz ścieżka podpisywania i weryfikacji HMAC akceptują klucz o zerowej długości, co pozwala zdalnemu atakującemu obliczyć deterministyczny podpis HS256, HS384 lub HS512 dla dowolnych roszczeń tokenu i uznać token za autentyczny. Problem naprawiono w wersji 1.9.1.

Authlib to biblioteka Pythona do budowy serwerów OAuth i OpenID Connect. W wersjach od 1.3.1 do 1.9.0 funkcja OctKey.import_key() sprawdza znaczniki kluczy asymetrycznych tylko na bajcie zerowym, podczas gdy loadery PEM akceptują wiodące białe znaki, komentarze lub BOM. W konfiguracjach z mieszanym rejestrem algorytmów nieuwierzytelniony atakujący znający te same bajty klucza publicznego może użyć ich jako sekretu HMAC i sfałszować tokeny HS256 z dowolnymi roszczeniami. Problem naprawiono w wersji 1.9.0.

W bibliotece Authlib od wersji 0.13 do 1.8.0 funkcja authlib.common.security.is_secure_transport() używa tekstowego porównania prefiksu dla wyjątków HTTP loopback, przez co URL, którego część userinfo zaczyna się od hosta loopback, może zostać zaakceptowany mimo zewnętrznego hosta. Strona zewnętrzna mogąca dostarczyć URL do rejestracji wylogowania OIDC RP-Initiated Logout lub walidacji metadanych serwera autoryzacji może obejść wymóg TLS i spowodować przekierowanie lub akceptację punktów końcowych w postaci jawnej.

W bibliotece Authlib (wersje przed 1.6.9) wykryto podatność w walidacji tokenów ID protokołu OpenID Connect. Funkcja _verify_hash błędnie akceptuje nieobsługiwane algorytmy kryptograficzne, zwracając True zamiast odrzucić token. Umożliwia to atakującemu ominięcie integralności tokena poprzez dostarczenie sfałszowanego tokena z nieznanym algorytmem.

Authlib to biblioteka Pythona do budowania serwerów OAuth i OpenID Connect. W wersjach 1.0.0 do 1.6.5, przechowywanie stanu/tokenów żądań w pamięci podręcznej nie jest powiązane z sesją inicjującego użytkownika, co umożliwia CSRF dla każdego atakującego, który posiada ważny stan (łatwo uzyskany poprzez inicjowany przez atakującego przepływ uwierzytelniania). Gdy pamięć podręczna jest dostarczona do rejestru klienta OAuth, FrameworkIntegration.set_state_data zapisuje cały stan pod _state_{app}_{state}, a get_state_data ignoruje sesję wywołującego. Problem został naprawiony w wersji 1.6.6.

Authlib to biblioteka Pythona do budowy serwerów OAuth i OpenID Connect. W wersjach przed 1.6.5 ścieżka JWE zip=DEF wykonuje nieograniczoną dekompresję DEFLATE, co pozwala atakującemu na wyczerpanie pamięci i CPU oraz spowodowanie odmowy usługi.

Authlib w wersjach przed 1.6.5 akceptuje nieograniczone nagłówki i segmenty podpisu JWS/JWT. Zdalny atakujący może spreparować token, którego nagłówek lub podpis w base64url zajmuje setki megabajtów, co podczas weryfikacji prowadzi do wysokiego zużycia CPU i pamięci, umożliwiając atak denial of service.

Authlib, biblioteka Pythona do budowy serwerów OAuth i OpenID Connect, w wersjach przed 1.6.4 akceptuje tokeny JWS deklarujące nieznane krytyczne parametry nagłówka (crit), naruszając semantykę „must-understand” z RFC 7515. Atakujący może spreparować podpisany token z krytycznym nagłówkiem, który rygorystyczne weryfikatory odrzucają, ale Authlib akceptuje, co w środowiskach mieszanych może prowadzić do rozbieżnej weryfikacji, obejścia polityk, powtórzenia lub eskalacji uprawnień. Podatność naprawiono w wersji 1.6.4.