Podatności SuperTokens Core

W SuperTokens Core w wersjach od 7.0.0 do 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 występuje wyścig (race condition) między createNewSession a unlinkAccounts. Użytkownik kontrolujący powiązaną metodę logowania może wykorzystać ten wyścig, aby zachować podpisaną, opartą na bazie danych sesję odświeżania jako dawna tożsamość główna po odłączeniu tej metody.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 10.1.0 do 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 funkcje loadOptionsById_Transaction i getUserInfoByCredentialId_Transaction wykonują wyszukiwania WebAuthn w zakresie aplikacji bez ograniczania ich do żądanego tenanta, a WebAuthN.signIn nie weryfikuje przynależności do tenanta. W środowisku wielodostępnym z WebAuthn i współdzieloną pulą użytkowników zwykły użytkownik posiadający własny ważny klucz dostępu w jednym tenancie może przesłać jego asercję do punktu końcowego logowania innego tenanta w tej samej aplikacji i zostać tam uwierzytelniony, mimo braku członkostwa w docelowym tenancie. Problem naprawiono w wersjach 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.3.0 do 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 licencjonowane wdrożenie z skonfigurowanym klientem SAML może uwierzytelnić tożsamość na podstawie asercji, która nie spełniała sprawdzenia odbiorcy (audience). Gdy dostawca tożsamości używa podpisywania na poziomie asercji, atakujący posiadający nadal ważną asercję podpisaną przez IdP wskazującą ofiarę dla dowolnego odbiorcy oraz własną ważną asercję dla docelowego odbiorcy może je połączyć, ponieważ validateSamlResponseAudience akceptuje odbiorcę z jednej asercji, podczas gdy extractAllClaims pobiera końcowy NameID i atrybuty z innej; podpisywanie na poziomie odpowiedzi nie ujawnia tego wariantu z wieloma asercjami. Niezależnie, asercja od dostawcy tożsamości skonfigurowanego dla docelowego wdrożenia, ale wydana innemu wdrożeniu SuperTokens używającemu współdzielonego domyślnego saml_sp_entity_id, może spełnić sprawdzenie odbiorcy celu. Skuteczne wykorzystanie uwierzytelnia atakującego jako użytkownika IdP ofiary. Problem naprawiono w wersjach 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.3.0 do 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 funkcja SAML.handleCallback nie zużywa RelayState, nie rejestruje identyfikatorów asercji ani nie wymusza Response.InResponseTo. W przepływie inicjowanym przez SP atakujący, który uzyska legalnie wydaną, nadal ważną odpowiedź SAML i pasujący RelayState, może ponownie przesłać parę do /recipe/saml/callback przed upływem czasu NotOnOrAfter asercji; w przepływie inicjowanym przez IdP asercja może być odtworzona bez RelayState. Brak sprawdzenia Response.InResponseTo pozwala również na ukończenie logowania w toku za pomocą asercji dla innej tożsamości i nie wymusza allowIDPInitiatedLogin=false. Callback nie waliduje Destination ani SubjectConfirmationData Recipient i NotOnOrAfter, a każdy zaakceptowany callback generuje nowy, niezależnie wymienialny kod autoryzacyjny niosący tożsamość przechwyconego użytkownika. Problem naprawiono w wersjach 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.0.0 do 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11 i 12.1.2 funkcja Dashboard.isValidUserSession traktuje każdy zapisany wiersz sesji jako ważny bez porównywania DashboardSessionInfo.expiry z bieżącym czasem. DashboardQueries.getSessionInfoWithSessionId również wybiera według aplikacji i identyfikatora sesji bez predykatu wygaśnięcia, pozostawiając okresowe czyszczenie DeleteExpiredDashboardSessions jako jedyne wymuszenie wygaśnięcia. Atakujący, który uzyska sesję administratora dashboardu po jej 30-dniowym okresie ważności, może nadal używać POST /recipe/dashboard/session/verify, dopóki wiersz nie zostanie usunięty, a częste restarty Core mogą uniemożliwić uruchomienie 12-godzinnego czyszczenia. Nieaktualna sesja zachowuje pełny dostęp do odczytu i zapisu dashboardu, ale luka nie zapewnia sposobu na odgadnięcie lub uzyskanie losowego identyfikatora sesji. Problem naprawiono w wersjach 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11 i 12.1.2.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.3.0 do 11.3.7, 11.4.7 i 12.0.10 funkcja SAML.verifySamlResponseSignature wywołuje OpenSAML SignatureValidator.validate bez uprzedniego zastosowania SAMLSignatureProfileValidator. Core może zatem zaakceptować kryptograficznie ważny podpis odnoszący się do innego elementu XML niż Response lub Assertion, którego NameID i atrybuty są używane do uwierzytelniania. Zwykły użytkownik skonfigurowanego dostawcy tożsamości może przenieść autentycznie podpisany element w inne miejsce dokumentu, dostarczając element niosący tożsamość autorstwa atakującego, powodując uwierzytelnienie przez XML Signature Wrapping jako inny użytkownik IdP. Dotyczy to zarówno ścieżek podpisywania na poziomie odpowiedzi, jak i asercji, a logowanie inicjowane przez SP pozostaje osiągalne bez włączania allowIDPInitiatedLogin. Problem naprawiono w wersjach 11.3.7, 11.4.7 i 12.0.10.

SuperTokens Core przed wersjami 11.3.6, 11.4.6 i 12.0.8 pozwala żądaniom zarządzania specyficznym dla aplikacji z nieznaną ścieżką tenanta i starszą obsługiwaną wersją cdi-version obejść wymuszanie klucza API i publicznego tenanta. W WebserverAPI.java funkcje checkIPAccess i assertThatAPIKeyCheckPasses tłumią TenantOrAppNotFoundException, a ochrona publicznego tenanta dotyczy tylko CDI 5.0 i nowszych. Nieuwierzytelniony wywołujący może użyć PUT /ghosttenant/recipe/role i GET /ghosttenant/recipe/roles do tworzenia i wyliczania ról aplikacji bez ważnego klucza API.

W SuperTokens Core w wersjach od 6.0.0 do 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 funkcja Multitenancy.checkPermissionsForCreateOrUpdate nieprawidłowo autoryzuje aktualizacje domeny nadrzędnej URI połączenia lub dzierżawy bazowej. W licencjonowanym wdrożeniu wielodostępnym z wieloma aplikacjami w ramach jednej domeny URI połączenia innej niż domyślna i oddzielnymi kluczami API atakujący posiadający ważny klucz API jednej aplikacji może zaktualizować domenę nadrzędną, a następnie zastąpić klucze aplikacji siostrzanych, czytać lub modyfikować użytkowników siostrzanych, uzyskiwać sesje jako ci użytkownicy, utrwalić dostęp przez użytkownika pulpitu nawigacyjnego siostrzanej aplikacji i zablokować własny klucz aplikacji siostrzanej. Warianty obsługi tworzenia lub aktualizacji v2 z pominięciem opcjonalnego identyfikatora tworzą cel dzierżawy bazowej, który pomija gałęzie uprawnień i bramkę funkcji enterprise, umożliwiając zmiany w firstFactors, wymaganych czynnikach dodatkowych i flagach włączonych przepisów, co wpływa na integralność i dostępność logowania. Wariant celu bazowego nadal odrzuca coreConfig i nie prowadzi do kradzieży kluczy. Problem naprawiono w wersjach 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

W SuperTokens Core w wersjach od 6.0.0 do 11.4.0 brakuje separacji dzierżawców (tenantów). Uwierzytelniony użytkownik jednego dzierżawcy może uzyskać dostęp do sesji, danych i punktów końcowych innego dzierżawcy.