Jak sprawdzić, co ujawnia moja witryna WordPress?

Dlaczego to ważne

Większość porad bezpieczeństwa dotyczy przełączników: włącz to, wyłącz tamto. Ale przełącznik mówi, o co prosiłeś, a nie co się stało. Warstwa cache może serwować starą odpowiedź. Reguła CDN może zablokować plik, zanim WordPress w ogóle zobaczy żądanie. Jedna wtyczka może ponownie otworzyć coś, co zamknęła inna. Jedyna uczciwa odpowiedź na pytanie „co ujawnia moja witryna?” to zapytać ją tak, jak zrobiłby to obcy.

Dobra wiadomość: lista rzeczy, które warto sprawdzić po stronie logowania, jest krótka. Boty szukają tej samej garstki adresów na każdej witrynie WordPress:

Żaden z nich sam w sobie nie jest katastrofą. Razem dają botowi listę nazw i dwoje drzwi, na których może je wypróbować. Wiedząc, które są otwarte, możesz zamykać je we właściwej kolejności: najpierw drzwi, potem nazwy.

Częste błędy

• Testowanie jako zalogowany. WordPress pokazuje zalogowanym więcej. Użyj okna prywatnego lub curl.
• Testowanie strony z cache. Jeśli właśnie zmieniłeś ustawienie, najpierw wyczyść pamięć podręczną stron i CDN, inaczej zobaczysz starą odpowiedź.
• Zatrzymanie się na pierwszym zielonym świetle. Zamknięcie formularza logowania przy otwartym XML-RPC to najczęstsza połowiczna poprawka, jaką widzimy.
• Oczekiwanie pełnego audytu bezpieczeństwa. Te testy dotyczą dróg wejścia. Nic nie mówią o malware, zmianach plików ani nieaktualnych wtyczkach.

Bez wtyczki

Pięć poleceń curl z kroku 1 to metoda ręczna i warto ją znać. Wyniki czytaj tak:

• HTTP/2 200 dla wp-login.php: domyślne logowanie jest publiczne. 404: jest ukryte.
• XML-RPC server accepts POST requests only. z xmlrpc.php: endpoint działa. Aby sprawdzić, czy przyjmuje logowanie, trzeba wysłać wywołanie wp.getUsersBlogs z kontem testowym.
• Tablica JSON z /wp/v2/users z polami "slug": nazwy użytkowników są publiczne. 401 lub pusta tablica: zamknięte.
• Location: /author/name/ z ?author=1: wyciek. Powtórz z 2, 3 i kolejnymi, by zobaczyć, ilu użytkowników mógłby zebrać bot.
• 200 dla mapy witryny z użytkownikami: adresy autorów są wymienione.

Wadą jest czas i interpretacja. Trzeba to powtarzać po każdej zmianie, a porządne przetestowanie logowania przez XML-RPC wymaga ręcznego składania XML.

Jeśli coś pójdzie nie tak

• Skan pokazuje „otwarte”, choć to wyłączyłeś. Wyczyść pamięć podręczną stron i CDN i przeskanuj ponownie. Jeśli nadal jest otwarte, ustawienie może nadpisywać inna wtyczka lub reguła serwera.
• Skan nie może dotrzeć do witryny. Niektórzy hostingodawcy blokują witrynie wysyłanie żądań do samej siebie (loopback). Poproś hosting o zezwolenie na żądania loopback albo użyj metody curl z zewnątrz.
• Po wzmocnieniu nadal wycieka nazwa użytkownika. Sprawdź ramkę autora w motywie i mapę witryny autorów we wtyczce SEO. Zmień nazwę wyświetlaną autora, jeśli motyw ją pokazuje.

Z Hushfort

Skan powierzchni ataku jest dostępny bez opłat w Hushfort Security, darmowej wtyczce bezpieczeństwa WordPress.

Skan powierzchni ataku znajduje się w panelu Redukcja powierzchni ataku w Hushfort. Mierzy, co witryna faktycznie ujawnia, prawdziwymi żądaniami — tak jak metoda ręczna — i wymienia z nazwy znalezione nazwy użytkowników. Każde znalezisko odpowiada warstwie Hushfort, która je zamyka:

• logowanie przez XML-RPC → Blokada tylnych drzwi (Pro)
• lista użytkowników REST, skanowanie autorów, mapa witryny → Osłona nazw użytkowników (Pro)
• domyślne logowanie → Ukrywanie logowania (za darmo)

Zbudowaliśmy Skan powierzchni ataku po tym, jak sklep wciąż otrzymywał próby haseł przez XML-RPC, choć jego strona logowania była ukryta. Ustawienie wyglądało dobrze; dopiero prawdziwe żądanie pokazało otwarte drzwi.