obejście uwierzytelniania

Obejście uwierzytelniania to podatność, która pozwala zalogować się albo działać jako inny użytkownik bez znajomości jego hasła ani drugiego składnika. Klasyczny wariant MITRE opisuje jako słabość CWE-288: produkt wymaga uwierzytelnienia, ale ma alternatywną ścieżkę lub kanał, który go nie wymaga ^[1]. W hierarchii MITRE CWE-288 jest odmianą słabości CWE-306, czyli braku uwierzytelnienia dla funkcji krytycznej ^[1]. Szerszą kategorią jest CWE-287, czyli niewłaściwe uwierzytelnianie: system nie dowodzi albo niedostatecznie dowodzi, że użytkownik jest tym, za kogo się podaje ^[2]. OWASP ujmuje to podobnie: podatność istnieje, gdy atakujący potrafi skłonić system do uznania niewłaściwego użytkownika za uprawnionego ^[3].

Jak działa

Uwierzytelnianie odpowiada na pytanie, kim jest użytkownik, a autoryzacja na pytanie, co mu wolno. Obejście uwierzytelniania atakuje pierwszy etap. Zamiast łamać hasło, atakujący szuka drogi, na której kontrola tożsamości nie działa: innego punktu końcowego, trybu awaryjnego, interfejsu serwisowego albo błędu w logice, który przepuszcza żądanie mimo nieudanej weryfikacji.

MITRE podaje przykłady z bazy CVE: bezpośrednie żądanie do plików instalatora, które pozwala utworzyć konto, oraz zgadywanie haseł przez API, które omijało blokadę działającą tylko w interfejsie graficznym ^[1]. Wspólne jest to, że główne drzwi są zamknięte, a boczne otwarte. MITRE ocenia prawdopodobieństwo wykorzystania słabości z grupy CWE-287 jako wysokie ^[2]. Wśród skutków wymienia odczyt danych aplikacji, uzyskanie uprawnień albo przyjęcie cudzej tożsamości oraz wykonanie nieautoryzowanego kodu lub poleceń ^[2]. Obejście uwierzytelniania często łączy się więc z eskalacją uprawnień.

RYS. 1Błąd logiki w drugim etapie logowania

Odmiany

CWE-287 jest kategorią nadrzędną wielu konkretnych słabości ^[2]. Najczęstsze warianty zestawia tabela.

Kategoria A07:2025 w zestawieniu OWASP obejmuje 36 słabości CWE i 7147 rekordów CVE ^[3]. OWASP wymienia w niej też ataki credential stuffing bez obrony przed automatyzacją, brak lub nieskuteczność wieloskładnikowego uwierzytelniania oraz błędy zarządzania sesją ^[3]. Te ostatnie prowadzą do obejścia przez przejęcie ważnej sesji, na przykład session fixation.

W WordPressie

Rdzeń WordPressa uwierzytelnia użytkowników w kilku kanałach: formularzem logowania, ciasteczkiem sesji, hasłami aplikacji w REST API i przez XML-RPC. Każdy dodatkowy kanał to miejsce, w którym wtyczka może wprowadzić własną, słabszą ścieżkę. Typowe źródła błędów:

• wtyczki dodające uwierzytelnianie dwuskładnikowe, logowanie społecznościowe albo logowanie bez hasła, które same wydają sesję;
• własne punkty końcowe REST API bez właściwej funkcji permission_callback; podręcznik podaje, że od WordPressa 5.5 jej brak wywołuje ostrzeżenie, a dla punktów publicznych należy świadomie użyć __return_true ^[7];
• akcje AJAX zarejestrowane dla niezalogowanych, które wykonują operacje wymagające konta.

Obejście uwierzytelniania prowadzi zwykle wprost do przejęcia konta, a jeśli ofiarą jest administrator, do przejęcia całej strony. Błędy tego typu należą do grupy podatności wykorzystywanych bez uwierzytelnienia, bo do ataku nie są potrzebne żadne dane logowania.

Jak się bronić

MITRE zaleca przepuszczanie całego dostępu przez jeden punkt kontroli i sprawdzanie uprawnień przy każdym dostępie do zasobu ^[1]. OWASP w A07:2025 wymienia wieloskładnikowe uwierzytelnianie, sprawdzanie nowych haseł w bazach wycieków, generowanie identyfikatorów sesji o wysokiej entropii po stronie serwera, jednolite komunikaty o nieudanym logowaniu i ograniczanie liczby nieudanych prób ^[3].

• uwierzytelnianie wieloskładnikowe dla kont z uprawnieniami administracyjnymi;
• wyłączanie nieużywanych kanałów logowania i usuwanie wtyczek, które je dodają;
• limit prób logowania we wszystkich kanałach, nie tylko w formularzu;
• szybka automatyczna aktualizacja wtyczek odpowiedzialnych za logowanie.

Historia i przykłady

W listopadzie 2024 roku opisano CVE-2024-10924 we wtyczce Really Simple Security, instalowanej na około 4 milionach witryn ^[5]. Według Sekuraka funkcja check_login_and_get_user() sprawdzała dane, ale jej wynik był ignorowany, a kod i tak wywoływał authenticate_and_redirect(), logując użytkownika na podstawie samego parametru user_id ^[5]. Badacze zwrócili uwagę, że nawet przy nieprawidłowym tokenie nonce przetwarzanie było kontynuowane, a użytkownik zostawał uwierzytelniony, choć jego tożsamości nie potwierdzono ^[5]. Dokładnie taki błąd logiki pokazuje diagram sekwencji wyżej. Błąd dotyczył punktów końcowych REST API i działał tylko przy włączonym uwierzytelnianiu dwuskładnikowym ^[5]. Kaspersky podaje, że podatne były wersje od 9.0.0 do 9.1.1.1, poprawkę przyniosła wersja 9.1.2, ocena CVSS wynosiła 9,8, a WordPress.org uruchomił wymuszoną aktualizację ^[6]. Paradoks polegał na tym, że podatne były tylko witryny, które włączyły dodatkową ochronę ^[6]. Według Kaspersky badacze Wordfence nazwali ten błąd najpoważniejszą podatnością, jaką widzieli w ciągu 12 lat pracy nad bezpieczeństwem WordPressa ^[6].

Obejście uwierzytelniania dotyczy też urządzeń. CERT Polska 27 maja 2026 roku opisał CVE-2026-35087: centrale telefoniczne Slican umożliwiały obejście uwierzytelniania w protokole administracyjnym, sklasyfikowane jako CWE-288 ^[4]. W tej samej publikacji opisano CVE-2026-35090, w którym nieuwierzytelniony atakujący uzyskiwał pełny dostęp do zdalnego zarządzania przez połączenie z określonego numeru, oraz przewidywalnie generowany klucz bezpieczeństwa ^[4]. To podręcznikowy przykład alternatywnego kanału. Według komunikatu starsze wersje 4.xx pozostają bez poprawek ^[4].