REST API: enumeracja użytkowników

REST API: enumeracja użytkowników to parametr monitoringu stron WordPress, który sprawdza, czy anonimowy klient może z zewnątrz poznać identyfikatory kont: z listy użytkowników w REST API albo z przekierowania na archiwum autora. Pomiar kończy się jednym z trzech wyników: identyfikatory ujawnione, nieujawnione albo brak odpowiedzi w wyznaczonym czasie. Trasa /wp/v2/users REST API WordPressa zwraca rekordy użytkowników z polami takimi jak id, name, slug, link i avatar_urls ^[1].

Jak działa

Pola rekordu użytkownika są przypisane do kontekstów. W domyślnym kontekście view widać m.in. id, name, url, description, link i slug, a login (username), adres e-mail i role należą wyłącznie do kontekstu edit ^[1]. Kontroler odrzuca kontekst edit, jeśli klient nie ma uprawnienia list_users, a takim klientom zawęża listę do osób z opublikowanymi wpisami w typach treści dostępnych przez REST ^[4]. Lista ma domyślnie 10 rekordów na stronę ^[1].

Pole slug to wartość user_nicename ^[4]. Jeśli przy zakładaniu konta nie podano jej osobno, WordPress bierze pierwsze 50 znaków loginu i przepuszcza je przez sanitize_title ^[6]. Slug jest więc zwykle loginem zapisanym w postaci nadającej się do adresu, ale może się od niego różnić.

Do tej samej trasy prowadzą dwie ścieżki. Na stronach bez przyjaznych odnośników trasa trafia do parametru rest_route, np. ?rest_route=/wp/v2/posts/123 ^[2]. Kod rdzenia rejestruje rest_route jako zmienną zapytania, a adresy zaczynające się od /wp-json/ przepisuje regułami na index.php?rest_route= ^[3]. Zablokowanie samej ścieżki /wp-json/ nie zamyka zatem parametru.

Trzecia droga nie korzysta z REST. Gdy żądanie strony ma liczbowy parametr author, a użytkownik o tym numerze ma choć jeden opublikowany wpis, funkcja kanonicznych przekierowań odsyła klienta na adres archiwum autora zbudowany z user_nicename ^[5]. Podstawiając kolejne liczby, można w ten sposób odczytać slug każdego autora.

RYS. 1.1Trzy drogi do identyfikatora konta

Standardy i specyfikacje

• REST API Handbook, Users definiuje pola rekordu, ich konteksty i parametry listy, w tym per_page i has_published_posts ^[1].
• Core Contributor Handbook, FAQ bezpieczeństwa stwierdza, że projekt WordPress nie uważa nazw użytkowników ani ich numerów za prywatne: login ma identyfikować, a weryfikacja jest zadaniem hasła ^[7]. Publiczny dostęp do listy przez GET /wp-json/wp/v2/users jest według tego dokumentu zamierzony ^[7]. WordPress pozwala logować się loginem albo adresem e-mail i zamiast ukrywać identyfikator zachęca do silnych haseł ^[7].
• OWASP WSTG-IDNT-04 każe sprawdzić, czy da się zebrać listę prawidłowych nazw użytkowników, bo przydaje się ona w ataku siłowym albo przy próbach domyślnych haseł ^[8]. Przewodnik zaznacza, że część aplikacji nie traktuje nazw użytkowników jako wrażliwych i celowo je wyświetla, więc przed zgłoszeniem trzeba znać wymagania aplikacji ^[8]. Wśród zaleceń wymienia jednolite komunikaty błędów logowania i usuwanie kont domyślnych oraz testowych przed wdrożeniem ^[8].

Zagrożenia i skutki

Połowa danych logowania. Lista kont pozwala skupić próby haseł na istniejących identyfikatorach zamiast zgadywać także nazwę ^[8]. Stanowisko WordPressa przenosi ciężar ochrony na hasło ^[7], więc realne ryzyko zależy od siły haseł i od tego, czy slug pokrywa się z loginem ^[6].

RYS. 1.2Od identyfikatora do przejęcia konta

Pusta lista nie oznacza braku kont. Anonimowy klient widzi tylko autorów opublikowanych wpisów ^[4], a przekierowanie z ?author= działa tylko dla użytkownika z opublikowanym wpisem ^[5]. Administrator, który niczego nie publikuje, nie pojawi się żadną z tych dróg.

Blokada jednej ścieżki. Reguła odmawiająca dostępu do /wp-json/ nie obejmuje żądania z parametrem rest_route, bo obie drogi kończą się w tej samej obsłudze zmiennej zapytania ^[3].

Przykłady

Dokumentacja REST API odradza wyłączanie całego interfejsu, bo przestają wtedy działać funkcje panelu administracyjnego; zamiast tego pozwala wymagać uwierzytelnienia filtrem rest_authentication_errors ze sprawdzeniem is_user_logged_in ^[10]. Węższym narzędziem jest filtr rest_endpoints (od wersji 4.4.0), który filtruje tablicę dostępnych tras REST API i pozwala usunąć z niej trasy użytkowników ^[9]. Po stronie archiwum autora przekierowanie przechodzi przez filtr redirect_canonical, a zwrócenie z niego false anuluje przekierowanie ^[5].

Żądanie lub ustawienie	Odpowiedź	Co ujawnia
GET /wp-json/wp/v2/users bez logowania [1] [4]	200 z listą autorów wpisów	id, name, slug, link
GET /wp-json/wp/v2/users?context=edit bez uprawnień [4]	odmowa	login, e-mail i role pozostają ukryte
GET /?rest_route=/wp/v2/users przy blokadzie /wp-json/ [2] [3]	200 z tą samą listą	slug
GET /?author=1, autor z opublikowanym wpisem [5]	przekierowanie na archiwum autora	slug w adresie
GET /?author=1, konto bez wpisów [5]	brak przekierowania	nic
Filtr rest_endpoints usuwający trasy użytkowników [9]	brak trasy	lista niedostępna
Filtr redirect_canonical zwracający false dla ?author= [5]	brak przekierowania	slug nie trafia do nagłówka Location
rest_authentication_errors z is_user_logged_in [10]	błąd dla anonimowych	cały REST tylko po zalogowaniu