Fałszywe rejestracje kont w WordPress: jak zatrzymać boty bez utrudniania życia klientom

Fałszywe rejestracje WordPress zatrzymuje się warstwami, nie jednym trikiem. Niewidoczne pułapki, potwierdzenie adresu e-mail, kontrola tego, skąd i jak szybko powstaje konto. Sama CAPTCHA? Nie załatwi sprawy, a do tego potrafi odstraszyć prawdziwych kupujących. Piszę to dla właściciela sklepu WooCommerce albo strony firmowej, któremu baza użytkowników puchnie od kont-widm. Pokażę, jak rozpoznać problem, które zabezpieczenia klient w ogóle nie zauważy i jak posprzątać to, co już się namnożyło, bez wylewania dziecka z kąpielą.

Skąd biorą się fałszywe rejestracje w WordPress i czym grożą?

Konta zakładają automaty. Szukają formularzy pod przewidywalnymi adresami, jak wp-login.php?action=register albo strona „Moje konto” w WooCommerce. Po co? Różnie. Żeby wrzucić linki spamowe w profilach i komentarzach, przetestować wykradzione loginy i hasła, zapisać się do newslettera albo spróbować dobrać się do wyższych uprawnień przez dziurę we wtyczce. I to nie jest problem tylko admina. Baza klientów przestaje być cokolwiek warta, odbite maile psują reputację domeny nadawcy, statystyki pokazują wzrost, którego nie ma, a serwer mieli ruch bez żadnej wartości. No i RODO (o którym wszyscy lubią zapominać): trzymasz zbędne dane osobowe, to masz też obowiązek regularnie porządkować bazę.

Jak rozpoznać spam rejestracji użytkowników w panelu?

Po wzorcach. Prawdziwi klienci po prostu tak się nie zachowują. Na co patrzę najpierw:

• losowe ciągi znaków jako nazwy użytkowników,
• adresy z domen jednorazowych skrzynek,
• seria kont założonych w odstępie kilku sekund lub minut,
• konta bez zamówienia i bez ani jednego logowania.

Otwórz listę Użytkownicy, posortuj po dacie rejestracji. Do tego raport klientów WooCommerce i logi serwera dla adresu formularza. A potem pytanie, które moim zdaniem zadaje się za rzadko: czy ta rejestracja jest wam w ogóle potrzebna? Jeśli sklep obsługuje zakupy jako gość, wystarczy odznaczyć „Każdy może się zarejestrować” w Ustawienia > Ogólne. Koniec tematu.

Zabezpieczenia niewidoczne dla klienta: honeypot, czas wypełnienia, limity

Najlepsza ochrona przed botami w formularzu rejestracji to taka, o której klient nie ma pojęcia. Honeypot to ukryte pole. Człowiek go nie widzi, więc wypełnia je tylko automat, a takie zgłoszenie od razu leci do kosza. Z czasem jest podobnie: formularz wysłany ułamek sekundy po załadowaniu strony raczej nie wyszedł spod palców żywej osoby. Kto tak szybko pisze? Nikt. Zestaw, który nie dokłada kupującemu ani jednego kliknięcia:

• ukryte pole-pułapka (honeypot),
• minimalny czas między otwarciem a wysłaniem formularza,
• limit rejestracji z jednego adresu IP w określonym czasie,
• blokada domen jednorazowych skrzynek pocztowych.

CAPTCHA to druga linia obrony, nie pierwsza. I najlepiej niewidoczna, bez zagadek. Klasyczne obrazki z przejściami dla pieszych wkurzają ludzi i potrafią ubić zakup albo zapis na wydarzenie w połowie.

Weryfikacja e-mail przy rejestracji: jak ją wdrożyć, żeby nie zgubić klientów

Zasada jest prosta: konto robi się aktywne dopiero po kliknięciu linku z maila. Bot z fałszywym adresem nigdy go nie kliknie. Sama wiadomość ma być krótka i jasna, z wyraźnym przyciskiem, opcją ponownego wysłania linku i sensownym czasem ważności. Ale uwaga, w sklepie nie blokuj zakupu do czasu potwierdzenia. Daj dokończyć zamówienie, aktywację zostaw na potem. Inaczej tracisz sprzedaż na własne życzenie. I jeszcze dostarczalność, o której mało kto myśli na starcie. Jeśli WordPress wysyła pocztę bez porządnie skonfigurowanego SMTP i rekordów domeny, link wyląduje w spamie albo nie dojdzie wcale. Oberwą prawdziwi klienci, nie boty.

Własny formularz zamiast domyślnego: mniej przewidywalny cel dla botów w formularzu rejestracji

Przenosisz rejestrację z wp-login.php na zwykłą stronę serwisu, na której sam decydujesz o wyglądzie i działaniu formularza. Da się to zrobić wtyczką Custom User Forms PRO. Shortcode [custom-register-form] pokazuje formularz rejestracji na wybranej stronie, a [custom-login-form], [custom-password-lost-form] i [custom-password-reset-form] obsługują logowanie, odzyskiwanie i reset hasła. Dla programisty jest jeszcze hook cuf_notification_new_user, którym ustawia się, gdzie i jakie powiadomienia idą po utworzeniu konta. Na przykład do administratora, który przegląda nowe rejestracje. Aha, i bonus: własny formularz łatwo dopasować wyglądem do reszty strony, więc klient nie ląduje nagle na obcym, systemowym ekranie.

Jak posprzątać istniejące fałszywe konta krok po kroku?

Najpierw kopia zapasowa. Na końcu kontrola treści przypisanych do usuwanych kont. Pomiędzy tym spokojnie, po kolei:

1. Zrób pełną kopię zapasową bazy danych.
2. Odfiltruj konta bez zamówień i bez żadnego logowania.
3. Przejrzyj ręcznie próbkę wyników, żeby potwierdzić, że to boty.
4. Usuwaj partiami, a nie wszystko naraz.
5. Sprawdź, czy usuwane konta nie mają przypisanych wpisów, komentarzy ani zamówień.

Ostrożnie z prawdziwymi klientami, którzy kupili jako gość albo po prostu dawno się nie logowali. W filtrze wyglądają bardzo podobnie. Po sprzątaniu patrz na nowe rejestracje przez kilka tygodni. Dopiero wtedy widać, które zabezpieczenie naprawdę robi robotę.

W sumie przepis jest krótki: niewidoczne pułapki, potwierdzenie adresu e-mail i własny formularz zamiast domyślnej strony rejestracji. Jeśli jesteś zarobionym adminem, idź w tej kolejności. Najpierw honeypot i limity, bo klientom w niczym nie przeszkadzają. Potem weryfikacja e-mail. A porządki w bazie na sam koniec, kiedy napływ nowych kont-widm wyraźnie siądzie.

Najczęstsze pytania