Podatności better-auth

Biblioteka Better Auth w wersji przed 1.6.11 zawiera podatność w pluginie @better-auth/sso. Punkty końcowe POST /sso/register i POST /sso/update-provider akceptują kontrolowane przez atakującego adresy URL (oidcConfig.userInfoEndpoint, tokenEndpoint, jwksEndpoint) przy włączonej opcji skipDiscovery: true, przechowują je bez walidacji pochodzenia i pobierają podczas wywołania zwrotnego OIDC, co umożliwia nieślepe fałszerstwo żądań po stronie serwera (SSRF) oraz potencjalne łączenie kont, gdy trustEmailVerified: true jest skonfigurowane.

Biblioteka Better Auth przed wersją 1.6.11 zawiera podatność w pluginach legacy oidcProvider i mcp, gdzie endpointy tokenów OAuth uwierzytelniają jedynie posiadanie ważnego refresh_token i client_id, bez weryfikacji client_secret. Pozwala to atakującemu z ważnym refresh_token na generowanie nowych tokenów dostępu i odświeżonych tokenów przez /api/auth/oauth2/token lub /api/auth/mcp/token.

Biblioteka better-auth (npm) przed wersją 1.4.2 pozwala na zewnętrzne żądanie skonfigurowania baseURL, gdy nie jest on zdefiniowany (np. BETTER_AUTH_URL nie jest ustawione). Atakujący, który wykona pierwsze żądanie do serwera po uruchomieniu, może zatruć bazową ścieżkę routera, powodując zwracanie 404 dla wszystkich tras i użytkowników (odmowa usługi). Problem nie występuje, gdy baseURL jest jawnie skonfigurowane lub na typowych platformach hostingowych.

better-auth passkey przed wersją 1.4.0 zawiera podatność na niebezpieczne bezpośrednie odwołanie do obiektu w punkcie końcowym usuwania passkey. Uwierzytelnieni użytkownicy mogą usuwać dowolne passkey innych użytkowników.

Better Auth używa biblioteki rou3, która normalizuje ścieżki URL przez usuwanie pustych segmentów. W wersjach Better Auth przed 1.4.5 atakujący może ominąć konfigurację disabledPaths oraz ograniczenia szybkości oparte na ścieżce, wysyłając żądania z dodatkowymi ukośnikami w ścieżce URL. Problem nie występuje, gdy proxy lub platforma normalizuje adresy URL przez zwijanie wielu ukośników.

Better-auth przed wersją 1.4.9 zawiera podatność na obejście uwierzytelniania dwuskładnikowego (2FA), gdy włączona jest opcja session.cookieCache. Atakujący posiadający prawidłowe podstawowe dane uwierzytelniające mogą uzyskać dostęp do uwierzytelnionych tras bez przechodzenia drugiego składnika weryfikacji, wykorzystując przedwczesne buforowanie sesji.

better-auth przed wersją 1.6.11 zawiera niebezpieczne domyślne ustawienia kryptograficzne w pluginach oidcProvider i mcp, które reklamują algorytm none i domyślnie akceptują zwykły PKCE. Atakujący mogą wykorzystać negocjację algorytmów do zaakceptowania niepodpisanych tokenów lub przechwycenia kodów autoryzacyjnych, gdy używany jest zwykły PKCE zamiast wymaganej metody S256.

Better-auth przed wersją 1.6.2 nie waliduje parametru stanu OAuth względem przechowywanego nonce, gdy używane jest przechowywanie stanu w ciasteczkach bez PKCE. Atakujący mogą sfałszować parametr stanu i dostarczyć kontrolowany przez atakującego kod autoryzacyjny, aby utworzyć uwierzytelnione sesje powiązane z zewnętrzną tożsamością atakującego lub trwale połączyć konta atakującego z profilami ofiary.

better-auth przed wersją 1.6.11 nie usuwa buforowanych sesji podczas usuwania użytkowników przez endpointy admin, anonymous lub SCIM, gdy skonfigurowano secondaryStorage i storeSessionInDatabase jest ustawione na false. Atakujący mogą ponownie użyć tokenów sesji usuniętych użytkowników, aby utrzymać uwierzytelnienie przez okres do siedmiu dni po usunięciu konta.

better-auth przed wersją 1.6.13 (oraz wersje pre-release 1.7.0-beta.0 do 1.7.0-beta.3) nie waliduje schematu redirect_uris zarejestrowanych przez przestarzały plugin oidc-provider oraz plugin mcp. Atakujący może zarejestrować klienta OAuth z redirect_uri o schemacie javascript:, który serwer autoryzacyjny zwraca bez zmian w odpowiedzi na zgodę. Jeśli strona zgody przekierowuje przeglądarkę do zwróconego redirectURI (np. przypisując go do window.location.href), JavaScript atakującego wykonuje się w kontekście serwera autoryzacyjnego, ujawniając sesję ofiary i umożliwiając przejęcie konta.

better-auth SCIM w wersjach od 1.5.0 do 1.7.0-beta.3 domyślnie nie wiąże dostawców SCIM spoza organizacji z ich twórcą, umożliwiając uwierzytelnionym użytkownikom zarządzanie dostawcami innych użytkowników. Atakujący mogą regenerować tokeny SCIM, unieważniać prawidłowe tokeny i uwierzytelniać się do interfejsów API SCIM przy użyciu kontrolowanego przez siebie tokena.

better-auth w wersjach >= 1.1.3 i < 1.6.22 (oraz wersje pre-release >= 1.7.0-beta.0 i < 1.7.0-beta.10) jest podatny na przejęcie konta przez pre-account hijacking przy logowaniu przez magic-link lub email-OTP, gdy włączona jest rejestracja przez email/hasło. Atakujący rejestruje konto z adresem e-mail ofiary i wybranym przez siebie hasłem; konto pozostaje niezweryfikowane. Gdy prawowity właściciel później loguje się przez magic-link lub email-OTP, konto zostaje oznaczone jako zweryfikowane bez usunięcia istniejącego hasła lub unieważnienia istniejących sesji, więc hasło atakującego pozostaje ważne, zapewniając mu trwały dostęp do konta ofiary. Poprawione w wersjach 1.6.22 i 1.7.0-beta.10.

better-auth w wersjach po v0.0.2 i przed 1.1.16 zawiera podatność na odbity XSS na stronie /api/auth/error, gdzie wartość parametru URL 'error' jest odbijana jako HTML bez odpowiedniej neutralizacji. Atakujący może zmusić użytkownika do odwiedzenia specjalnie spreparowanego URL, aby wykonać dowolny JavaScript w kontekście przeglądarki użytkownika.

better-auth przed wersją 1.1.20 zawiera podatność obejścia w logice walidacji trustedOrigins dla bezwzględnych adresów URL i domen z symbolami wieloznacznymi. Atakujący może skonstruować złośliwy parametr callbackURL, który przechodzi kontrolę pochodzenia i powoduje otwarte przekierowanie, umożliwiając kradzież wrażliwych tokenów i przejęcie konta.

better-auth w wersjach większych niż 1.3.34 i przed 1.4.0 zawiera podatność we wtyczce multi-session w hooku po wylogowaniu (/sign-out after-hook), który ufa surowym ciasteczkom multi-session i przekazuje wyodrębnione wartości do internalAdapter.deleteSessions bez weryfikacji podpisu ciasteczka. Atakujący może dostarczyć sfałszowane ciasteczko _multi-*, aby wywołać usunięcie dowolnych tokenów sesji.

Biblioteka Better Auth w wersjach od 1.6.0 do 1.6.11 zawiera podatność w punkcie końcowym POST /oauth2/token dla grantu authorization_code. Kod autoryzacyjny jest sprawdzany i usuwany w sposób nieatomowy (najpierw odczyt, potem usunięcie), co pozwala dwóm równoczesnym żądaniom na odczytanie tego samego kodu i wygenerowanie niezależnych tokenów dostępu, odświeżania i ID.

Biblioteka Better Auth dla TypeScript zawiera podatność w endpointzie POST /oauth2/token dla grantu refresh_token. Nieatomowa sekwencja odczytu, walidacji, unieważnienia i utworzenia tokena odświeżania pozwala współbieżnym żądaniom z tym samym tokenem nadrzędnym ominąć sprawdzenie unieważnienia i utworzyć rozwidlone rodziny tokenów odświeżania.

Podatność w bibliotece Better Auth umożliwia nieautoryzowane łączenie kont OAuth z istniejącymi kontami użytkowników. Mechanizm automatycznego łączenia kont akceptuje potwierdzenie adresu email od dostawcy OAuth bez weryfikacji, czy lokalny użytkownik ma potwierdzony email. Atakujący może zarejestrować konto z adresem email ofiary, a następnie połączyć je z kontem OAuth ofiary.

Podatność w bibliotece Better Auth w wersjach od 1.2.10 do 1.6.11. Endpoint POST /sso/register wtyczki @better-auth/sso pozwala każdemu członkowi organizacji na dodanie nowego dostawcy SSO, ponieważ funkcja registerSSOProvider sprawdza jedynie przynależność do organizacji, a nie wymaga roli właściciela lub administratora. Umożliwia to atakującemu kontrolowanie dostawców OIDC lub SAML i przejęcie procesu provisionowania organizacji przez /sso/callback/{providerId}.

Biblioteka Better Auth dla TypeScript zawiera podatność w pluginie organizacyjnym, która umożliwia użytkownikowi z niezweryfikowaną sesją dla adresu e-mail, na który wysłano zaproszenie, zaakceptowanie tego zaproszenia po uzyskaniu identyfikatora zaproszenia. Problem występuje w wersjach przed 1.6.11 oraz w 1.6.14 i nowszych, gdy identyfikatory zaproszeń są dostępne poza skrzynką pocztową zaproszonego i nie włączono opcji requireEmailVerificationOnInvitation: true.

Podatność w bibliotece Better Auth w wersjach od 1.6.0 do 1.6.11 umożliwia uwierzytelnionemu atakującemu, który pozna kod użytkownika (user_code), przejęcie sesji urządzenia oczekującego na autoryzację. Problem wynika z braku weryfikacji właściciela kodu w endpointach GET /device, POST /device/approve i POST /device/deny.

Biblioteka Better Auth dla TypeScript zawiera podatność w mechanizmie ograniczania szybkości żądań (rate limiter). Kluczowanie żądań opiera się na dokładnym tekście adresu IP z nagłówka x-forwarded-for, co pozwala atakującemu z IPv6 na obejście limitów poprzez zmianę adresu źródłowego lub formatowania tekstowego adresu.