enumeracja użytkowników

Enumeracja użytkowników to pozyskiwanie listy istniejących loginów lub kont w aplikacji, zwykle jako przygotowanie do ataku na hasła. Umożliwia ją słabość, którą MITRE opisuje jako CWE-204: aplikacja odpowiada na żądania w różny sposób, a ta różnica ujawnia nieuprawnionej osobie wewnętrzny stan systemu ^[1]. Jeśli formularz logowania zwraca inny komunikat dla nieznanego loginu, a inny dla błędnego hasła, atakujący metodą prób i błędów ustala, które loginy istnieją ^[1]. Sama lista kont nie daje dostępu, ale usuwa połowę niewiadomych w ataku siłowym (brute-force).

Jak działa

Atakujący wysyła serię żądań z różnymi loginami i porównuje odpowiedzi. Źródłem różnicy może być treść komunikatu, kod odpowiedzi HTTP, przekierowanie albo czas przetwarzania. OWASP zwraca uwagę, że czas obsługi żądania bywa wyraźnie inny dla sukcesu i porażki, co pozwala na atak czasowy: kod, który kończy pracę od razu po stwierdzeniu, że konta nie ma, zdradza jego brak ^[2]. Dlatego logowanie powinno przechodzić ten sam proces bez względu na to, jaki login i hasło podano ^[2].

Enumeracja rzadko jest celem sama w sobie. Zwykle otwiera łańcuch prowadzący do przejęcia konta, jak na schemacie poniżej.

RYS. 1Od enumeracji do przejęcia konta

Niebezpiecznik opisuje ten scenariusz na przykładzie ataku, w którym przestępcy biorą jedno popularne hasło, enumerują listę użytkowników serwisu i próbują zalogować się na każde konto tym jednym hasłem ^[6]. Taki password spraying omija blokadę pojedynczego konta, bo na każdy login przypada tylko jedna próba ^[6].

Odmiany

Źródła różnicy w odpowiedziach są różne, a każde wymaga osobnej poprawki.

OWASP zaleca, by logowanie, reset hasła i odzyskiwanie konta zwracały ogólny komunikat bez względu na to, czy błędny był login, czy hasło, czy konto nie istnieje albo jest zablokowane ^[2].

W WordPressie

WordPress ma kilka miejsc, które z natury publikują informacje o autorach. Pierwsze to archiwa autorów. Sekurak opisuje, że przekazanie w adresie parametru author z identyfikatorem liczbowym uruchamia sprawdzenie, czy taki użytkownik istnieje, a gdy istnieje, serwer odpowiada przekierowaniem 301 z loginem w nagłówku Location ^[5]. Wystarczy więc przejść kolejne numery, żeby zebrać listę kont.

GET /?author=1 HTTP/1.1
Host: example.com

HTTP/1.1 301 Moved Permanently
Location: https://example.com/author/jan/

Drugie miejsce to endpoint REST API /wp/v2/users. Dokumentacja REST API wymienia pola zwracane w publicznym kontekście view: między innymi id, name, link i slug ^[3]. Endpoint ma też parametry zawężające wynik do autorów i do osób, które opublikowały wpisy ^[3]. W wersji 4.7.1 z 11 stycznia 2017 roku poprawiono błąd, przez który REST API ujawniało dane wszystkich użytkowników będących autorami wpisu publicznego typu; poprawka ograniczyła to do typów wpisów wyraźnie udostępnionych w REST API ^[4].

Trzecie miejsce to sam formularz wp-login.php i funkcja resetu hasła, które należy oceniać tak jak w każdej innej aplikacji. Sekurak jako narzędzie do sprawdzenia własnej witryny wskazuje WPScan z opcją enumeracji użytkowników ^[5].

Dokumentacja WordPressa radzi, by przy tworzeniu konta administratora unikać łatwych do odgadnięcia nazw, takich jak admin czy webmaster, bo to na nie atakujący próbują w pierwszej kolejności ^[8]. Zasada ta ma sens właśnie dlatego, że login nie jest tajemnicą: jeśli da się go poznać przez enumerację, całą ochronę konta niesie hasło i uwierzytelnianie dwuskładnikowe (2FA).

Zagrożenia i skutki

MITRE przypisuje słabości CWE-204 skutki w obszarze poufności i kontroli dostępu: odczyt danych aplikacji i obejście mechanizmu ochrony ^[1]. W praktyce lista loginów zawęża atak siłowy do kont, które naprawdę istnieją, i ułatwia credential stuffing, czyli próby z parami login–hasło z cudzych wycieków. Znajomość loginu administratora pozwala też celować w konkretne osoby, na przykład wiadomościami podszywającymi się pod obsługę strony.

Enumeracja jest formą ujawnienia informacji. Zwykle ocenia się ją jako błąd o niskiej wadze, ale jej wpływ zależy od tego, jak mocno chronione są konta, które zdradza.

Jak się bronić

• Jednakowe odpowiedzi. Ten sam komunikat, kod HTTP i czas przetwarzania dla konta istniejącego i nieistniejącego ^{[1] [2]}.
• Ograniczenie publicznych danych o autorach. Blokada parametru author na serwerze, co Sekurak pokazuje jako regułę dla Apache ^[5], i przegląd tego, co zwraca REST API; zob. zabezpieczenia w .htaccess.
• Utrudnienie zgadywania haseł. Limit prób logowania, CAPTCHA po kilku nieudanych próbach i silne, unikalne hasła.
• Drugi składnik logowania, który sprawia, że znany login i odgadnięte hasło nie wystarczą.

Ukrywanie loginów jest security through obscurity: utrudnia rozpoznanie, ale nie zastępuje ochrony samego konta. Warto je stosować jako warstwę uzupełniającą.

Historia i przykłady

Luka w REST API naprawiona w WordPressie 4.7.1 jest jednym z najlepiej znanych przypadków enumeracji w rdzeniu tego systemu ^[4]. Tego samego typu błędy wciąż pojawiają się w innych systemach zarządzania treścią. CERT Polska 16 marca 2026 roku opisał podatności w Raytha CMS; jedna z nich, CVE-2025-69243, umożliwiała enumerację użytkowników w funkcji resetowania hasła, bo różnice w komunikatach pozwalały ustalić, czy login jest prawidłowy ^[7]. Problem usunięto w wersji 1.5.0 ^[7].