Zabezpieczanie logowania do WordPressa: WP Admin Captcha

Pytania i odpowiedzi

Czy zabezpieczenie przed zablokowaniem dostępu obejmuje też błędny Secret Key albo weryfikację, która nie dociera do Google?

Obejmuje wyłącznie sytuację braku kluczy. Gdy klucze są zapisane, wtyczka wymaga rozwiązania zadania, a zadanie, którego nie da się potwierdzić, uznaje za nierozwiązane. Dla zabezpieczenia to zachowanie prawidłowe, podczas awarii jednak niewygodne.

Błędny Secret Key i nieosiągalny punkt weryfikacji wyglądają więc od strony formularza logowania tak samo: formularz odrzuca próbę. Wtedy potrzebna jest druga droga odzyskania dostępu, niezależna od wtyczki: przez WP-CLI albo zmianę nazwy katalogu wtyczki przez SSH. Przy wdrażaniu captchy na stronie logowania warto raz wypróbować tę drogę, zanim stanie się potrzebna.

Do tego dochodzi jeden szczegół dotyczący limitu. Do 10 000 ocen miesięcznie korzystanie jest bezpłatne, a każde żądanie weryfikacji wlicza się do tej liczby. Witryna pod stałym naporem botów może ją osiągnąć bez ani jednego udanego logowania. Co dzieje się po przekroczeniu limitu, zależy od ustawień rozliczeń projektu Google Cloud; jeśli weryfikacja przestaje wtedy cokolwiek potwierdzać, błąd przychodzi tymi samymi drzwiami co wspomniana wyżej awaria.

Czy WP Admin Captcha obejmuje też próby logowania przez xmlrpc.php?

Pośrednio tak, choć nie w taki sposób jak na stronie logowania. Pole wyboru wymaga interfejsu, a ten punkt dostępu go nie ma, bo przyjmuje dane logowania w jednym wywołaniu i odpowiada maszynowo. Kontrola wtyczki nie jest jednak związana z formularzem, lecz z filtrem wp_authenticate_user, przez który WordPress przechodzi przy każdym logowaniu nazwą użytkownika i hasłem konta, także przy wywołaniu przez xmlrpc.php. Takiemu wywołaniu brakuje tokenu captcha, który wysyła tylko formularz logowania, więc logowanie kończy się niepowodzeniem, zanim hasło w ogóle zostanie sprawdzone.

Wynikają z tego dwie rzeczy. Próby odgadnięcia hasła przez ten punkt dostępu trafiają w próżnię, dopóki zapisany jest Secret Key; bez niego działa zabezpieczenie przed zablokowaniem dostępu i ochrona znika także tutaj. Nie zalogują się również programy, które logują się przez XML-RPC hasłem konta; hasła aplikacji WordPress sprawdza inną drogą, której wtyczka nie dotyka.

Obciążenie jednak pozostaje: każde wywołanie dociera do PHP, a pojedyncze żądanie mogło w przeszłości łączyć kilka prób logowania, co obchodzi limity liczone na żądanie. Tam, dokąd wtyczka nie sięga, działają dwa środki. Gdzie nic nie potrzebuje tego punktu dostępu (żadna aplikacja, żaden zewnętrzny edytor, żadna usługa dostarczająca wpisy), należy go wyłączyć; to najskuteczniejsza i najtańsza odpowiedź. Gdzie jest potrzebny, ograniczenie powinno działać poziom niżej, w serwerze WWW: blokada po kilku nieudanych próbach z jednego adresu, niezależnie od tego, do którego pliku skierowano żądanie.

Czy brak pola reCAPTCHA na stronie logowania mimo wpisanych kluczy może wynikać z polityki bezpieczeństwa treści (CSP)?

Tak, polityka CSP jest częstą przyczyną tego objawu. Widżet ładuje skrypty z www.google.com/recaptcha/ i www.gstatic.com/recaptcha/, a samo pole osadza w ramce z www.google.com/recaptcha/. Polityka, która nie dopuszcza tych źródeł, blokuje je bez widocznego śladu na stronie.

Konsekwencja jest poważniejsza niż samo brakujące pole. Zabezpieczenie przed zablokowaniem dostępu obejmuje wyłącznie sytuację braku kluczy. Skoro klucze są wpisane, wtyczka wymaga rozwiązania zadania, którego nikt nie widzi, i formularz odrzuca wtedy każde logowanie, także logowanie administratora.

Rozstrzyga konsola przeglądarki na stronie logowania: zablokowane zasoby są tam wymienione razem z nazwą dyrektywy. Do script-src należy dopisać oba źródła skryptów, a do frame-src źródło ramki. Warto też zawczasu znać drogę wejścia niezależną od wtyczki: zmiana nazwy jej katalogu przez SSH przywraca logowanie w kilkanaście sekund.