Podatności Better Auth

Better Auth to biblioteka uwierzytelniania i autoryzacji dla TypeScript. Od wersji 1.4.0-beta.18 do 1.7.7 wdrożenia, które włączają Magic Link z storeToken ustawionym na plain lub z storeToken ustawionym na hashed i globalnym ustawieniem verification.storeIdentifier również ustawionym na hashed, włączają wbudowanego dostawcę społecznościowego lub Generic OAuth oraz używają account.storeStateStrategy ustawionego na database, mogą przyjąć wartość stanu logowania OAuth jako token Magic Link. Te ustawienia mogą powodować, że rekordy weryfikacji Magic Link i stan OAuth rozwiązują się do tego samego przechowywanego identyfikatora, pozwalając nieuwierzytelnionemu atakującemu rozpocząć logowanie OAuth dla znanego adresu e-mail i wykorzystać zwrócony stan poprzez Magic Link bez kontroli skrzynki pocztowej lub ukończenia callbacku dostawcy. Atakujący może uzyskać normalną sesję dla istniejącego użytkownika lub utworzyć konto błędnie oznaczone jako zweryfikowane e-mailem, gdy rejestracja jest włączona. Problem naprawiono w wersji 1.7.7.

Better Auth od wersji 1.4.0-beta.18 przed 1.7.7 zawiera lukę obejścia uwierzytelniania, która pozwala nieuwierzytelnionym atakującym zalogować się jako inni użytkownicy poprzez ponowne użycie wartości stanu OAuth jako tokenów Magic Link. Atakujący może rozpocząć logowanie OAuth z adresem e-mail ofiary i przesłać zwrócony stan do weryfikacji Magic Link, uzyskując sesje lub tworząc fałszywie zweryfikowane konta e-mail.

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.

W bibliotece Better Auth w wersjach przed 1.3.26 nieuwierzytelniony atakujący może tworzyć lub modyfikować klucze API dowolnego użytkownika, przekazując jego identyfikator w treści żądania do endpointu api/auth/api-key/create. Gdy nie ma sesji, ale w treści żądania występuje userId, flaga authRequired staje się fałszywa, a walidacja pól wykonywana tylko przy authRequired true zostaje pominięta, co pozwala ustawiać uprzywilejowane pola. Ten sam wzorzec występuje w endpoincie aktualizacji; luka stanowi krytyczne obejście uwierzytelniania i została naprawiona w wersji 1.3.26.

Better Auth w wersjach od 1.5.0-beta.12 do 1.7.7 zawiera podatność obejścia uwierzytelniania w pluginie OAuth Proxy pozwalającą nieuwierzytelnionym atakującym zalogować się jako inni użytkownicy poprzez sfałszowanie zaszyfrowanych profili. Gdy proxy współdzieli globalny sekret, a stan przechowywany w cookie jest używany, atakujący może uzyskać zaszyfrowany stan dla fałszywego profilu ze zweryfikowanym adresem e-mail ofiary, aby przejąć konto poprzez niejawne powiązanie.

W Better Auth (@better-auth/drizzle-adapter i better-auth od 1.6.17 przed 1.7.7 oraz @better-auth/kysely-adapter od 1.6.17 przed 1.7.0) występuje warunek wyścigu w ograniczaniu liczby żądań opartym na bazie danych PostgreSQL — sprawdzenie limitu nie jest atomowe względem aktualizacji licznika. Zdalni atakujący mogą wysyłać serie równoczesnych żądań, które wspólnie przechodzą sprawdzenie, przekraczając skonfigurowane limity dla logowania hasłem, weryfikacji dwuskładnikowej, kodów jednorazowych, resetu hasła i innych chronionych punktów końcowych.

better-auth w wersjach od 1.3.8-beta.3 do 1.7.0-rc.3 zawiera podatność polegającą na błędnym przedstawieniu interfejsu w pluginie deviceAuthorization, ponieważ GET /device pomija identyfikator klienta i zakres. Atakujący może rozpocząć żądanie urządzenia przez /device/code, nakłonić zalogowanych użytkowników do zatwierdzenia kodu, a następnie wykorzystać go w /device/token do uzyskania aktywnego tokena sesji.

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.

W Better Auth przed wersją 1.6.5 opcja clientPrivileges dokumentuje akcję create, ale endpointy tworzenia klienta OAuth nie wywoływały hooka przed zapisaniem nowego klienta. Wdrożenia konfigurujące clientPrivileges w celu ograniczenia rejestracji klientów nie były faktycznie ograniczone.