7 luk w zabezpieczeniach WordPress nie mogą cię chronić (i jak je naprawić)

Opublikowany: 2025-01-27

Jeśli jesteś jak większość użytkowników WordPress, prawdopodobnie zainstalowałeś wtyczkę bezpieczeństwa, aby zapewnić bezpieczeństwo witryny. Jest to doskonały pierwszy krok i poradzi sobie z dużą ilością twojej ochrony-szczególnie jeśli włączyłeś uwierzytelnianie dwuskładnikowe.

Ale zauważam, że podkreśliłem pierwszy krok. Zrobiłem to celowo, ponieważ wiele osób uważa, że ​​to jedyny krok, jaki muszą zrobić. Jeśli naprawdę zależy ci na bezpieczeństwie swojej witryny, nie powinno to być.

Dobra wiadomość jest taka, że ​​dzięki lekkiej konfiguracji ręcznej możesz poprawić swoje bezpieczeństwo WordPress na poziomie serwera i uczynić witrynę znacznie bardziej odporną na ataki. Jako dodatkowy bonus poczujesz się jak ekspert ds. Bezpieczeństwa WordPress podczas tego - prawdopodobnie najważniejszą częścią całego procesu. 😉

Jeśli więc jesteś gotowy, aby przekształcić się z swobodnego użytkownika WordPress w profesjonalistę i sprawić, że Twoja witryna jest kuloodporna, zacznijmy.

Spis treści

Narzędzia

Wierzcie lub nie, aby to zrobić, będziesz potrzebować tylko trzech (prawdopodobnie czterech) narzędzi.

  • STRONA STRONY STRONY : bezpłatne narzędzie do uruchomienia początkowego skanowania i weryfikacji zmian.
  • Nagłówki bezpieczeństwa : Kolejne bezpłatne narzędzie, które zawiera szczegółowe informacje zwrotne na temat konfiguracji bezpieczeństwa witryny.
  • Dostęp do twojego panelu sterowania hostingowego : Używam cPanel, ale omówię, co zrobić, jeśli masz coś innego.
  • Edytor tekstu (być może): Twój panel sterowania hostingiem prawdopodobnie ma wbudowany, więc może nie być potrzebny, ale na wszelki wypadek wymieniam go tutaj.

Najbardziej skomplikowaną rzeczą z powyższej listy będzie dostęp do CPANEL. To nie jest trudne, ale każda firma hostingowa ma swój własny sposób, a jeśli nigdy wcześniej tego nie zrobiłeś, musisz to rozgryźć.

Najłatwiejszym sposobem na podejście (jeśli nie masz pewności), jest przejście do bazy wiedzy firmy hostingowej i poszukiwanie „cPanel”. Jeśli to nie daje ci nigdzie, skontaktuj się z ich obsługą klienta.

Uruchamianie wstępnych kontroli bezpieczeństwa

Zanim zaczniesz majstrować przy kodzie swojej witryny, najpierw chcesz sprawdzić, jak obecnie zajmuje się bezpieczeństwem. Zmiany, które pokazuję, są bardzo konkretne, więc chcesz upewnić się, że są one niezbędne dla Twojej witryny.

W większości przypadków - zwłaszcza jeśli polegasz na wspólnym hostingu - będziesz musiał je zrobić. Jednak w niektórych planach hostingu WordPress na wyższym poziomie możliwe jest, że Twój gospodarz może wprowadzić poprawki w Twoim imieniu. Dlatego ważne jest, dlaczego wcześniejsze prowadzenie tych skanów jest ważne.

Sprawdź witrynę Sucuri

Aby rozpocząć, przejdź do narzędzia do sprawdzania witryny Sucuri i wklej adres witryny do skanera:

Strona sprawdzania witryny Sucuri.

Kliknij Prześlij i pozwól Sucuri działać w swojej magii.

Na potrzeby tego samouczka celowo niechroniłem mojej osobistej witryny, aby pokazać, jak wygląda standardowa konfiguracja WordPress (zanim dokonasz edycji):

Wyniki początkowego skanowania Sucuri pokazujące luki w zabezpieczeniach.

Jak widać, skan ujawnił pięć luk bezpieczeństwa, które zobaczysz w dowolnej konfiguracji WordPress. Za chwilę wyjaśnię, co mają na myśli.

Nagłówki bezpieczeństwa

Podczas gdy Sucuri dał nam dobry widok ptaka, bądźmy naprawdę nerdy na chwilę i sprawdź, co mają do powiedzenia nagłówki bezpieczeństwa. Pierwszy krok jest dokładnie taki sam jak Sucuri - po prostu wpisz lub wklej adres swojej witryny do narzędzia i kliknij skanowanie .

W zależności od tego, jak duża jest Twoja witryna, wyniki mogą trwać od sekundy do… cóż, dłużej. 😅 Mój początkowy wynik wyglądał tak:

SecurityHeaders.com nieudany skan bezpieczeństwa.

Wszystkie czerwone kolory i gigant F mogą wyglądać nieco zastraszające, ale w rzeczywistości daje nam bardzo przydatne informacje. Każde z tych czerwonych znaków wskazuje na brakujący nagłówek bezpieczeństwa, który sprawia, że ​​Twoja witryna jest bardziej wrażliwa.

Chcę również ponownie podkreślić , że zobaczysz te wyniki , nawet przy posiadaniu WordFence lub innej wtyczce bezpieczeństwa zainstalowanej w Twojej witrynie. Wyjątkiem jest to, że Twoja firma hostingowa lub ktoś inny dokonuje edycji, które zamierzamy dokonać przed tobą.

Zrozumienie wszystkich czerwonych flag

Zorganizujmy teraz wszystko, co znaleźli nasze skany - narzędzia nakładają się na narzędzia, ale każdy z nich również złapał kilka unikalnych problemów.

Problemy oba złapane narzędzia 🤝

  • Całkowicie brakuje treści-bezpieczeństwa- co oznacza, że ​​nic nie kontroluje, jakie skrypty i treść mogą załadować na stronie. ℹ️ Dlaczego to jest złe? Bez tych elementów sterujących złośliwy kod można wstrzykiwać i działać na twoich stronach, potencjalnie zagrażając Twojej witryny i gości.
  • Brakuje X-Frame-Options , co powoduje, że witryna jest podatna na próby kliknięcia w nieautoryzowanym osadzeniu. ℹ️ Dlaczego to jest złe? Clickjacking ma miejsce, gdy atakujący oszukują użytkowników, aby kliknęli coś innego niż to, co widzą, często poprzez niewidoczne nakładanie legalnej witryny pod złośliwą treścią.
  • Opcje typu treści nie są ustawione, co może umożliwić ataki zamieszania typu MIME. ℹ️ Dlaczego to jest złe? Zamieszanie typu MIME ma miejsce, gdy przeglądarka jest oszukana w trakcie traktowania jednego typu pliku jako innego, potencjalnie wykonując szkodliwy kod.

Unikalne odkrycia Sucuri 🔍

  • Wersja PHP jest widoczna w nagłówkach HTTP. ℹ️ Dlaczego to jest złe? Kiedy atakujący mogą zobaczyć twoją wersję PHP, wiedzą dokładnie, które luki mogą działać przeciwko Twojej witrynie - na przykład posiadanie systemu bezpieczeństwa.

Dodatkowe spostrzeżenia nagłówka bezpieczeństwa 🔬

  • Brak polityki polecających . ℹ️ Dlaczego to jest złe? Bez tej zasady Twoja witryna może wyciekać poufne informacje o wzorcach przeglądania użytkowników na inne strony internetowe.
  • Polityka uprawnień nie została skonfigurowana. ℹ️ Dlaczego to jest złe? Oznacza to, że każda strona w Twojej witrynie może potencjalnie zażądać dostępu do kamer odwiedzających, mikrofonów lub danych lokalizacji bez ograniczeń.
  • Brakuje bezpieczeństwa ścisłego transportu . ℹ️ Dlaczego to jest złe? Bez tego nagłówka połączenia z twoją witryną mogą obniżyć się z HTTPS do HTTP, co czyni je podatnymi na przechwycenie.

Piękno rozwiązania tych problemów polega na tym, że nie musisz rozumieć wszystkich szczegółów technicznych - wystarczy poprawnie wdrożyć rozwiązania. Co wygodnie jest dokładnie tym, co zamierzamy zrobić.

Znalezienie drogi do plików serwera

Zakładając, że masz cpanel tak jak ja, kliknij menedżer plików na desce rozdzielczej:

Dostęp do menedżera plików za pośrednictwem cPanel.

Jeśli używasz czegoś innego niż CPANEL, możesz pobrać FileZilla (jest to bezpłatne, a oto szybki przewodnik, jak go używać). Po zainstalowaniu użyj szczegółów FTP z pulpitu hostingowego, aby połączyć się z serwerem:

  • Host: ftp.yoursite.com - Sprawdź dwukrotnie, czy to poprawny adres w sekcji FTP CPANEL
  • Nazwa użytkownika: your-username
  • Hasło: your-password
  • Port: 21 - Sprawdź także, czy jest to port, którego używana jest konfiguracja (FTP w cPanel)

Niektórzy gospodarze zapewnią również własną alternatywę CPANEL, która może działać podobnie. Innymi słowy, być może absolutnie nie musisz używać FileZilla. Jeśli nie jesteś pewien, zapytaj o obsługę klienta.

Zlokalizowanie pliku .htaccess

Po zalogowaniu zobaczysz coś, co wygląda jak przeglądarka plików komputera. Musimy znaleźć konkretny plik o nazwie .htaccess - kontroluje on, w jaki sposób serwer obsługuje różne ustawienia bezpieczeństwa. Najłatwiejszym sposobem na znalezienie go jest użycie funkcji wyszukiwania menedżera plików CPANEL w prawym górnym rogu. Użytkownicy FileZilla mogą polegać na podobnej funkcji.

Wpisz .htaccess w oknie i kliknij Go .

Wyszukiwanie pliku .htaccess w menedżerze plików CPANEL.

Jeśli masz tylko jedną stronę internetową powiązaną z konto hostingowym, powinno to być dość proste. Jeśli masz wiele witryn, upewnij się, że klikasz plik .htaccess , który jest powiązany z witryną, do której zamierzasz dokonać tych edycji.

Kolejnym potencjalnym detaliem Tripwire, na który należy uważać, jest fakt, że nawet w jednej konfiguracji witryny prawdopodobnie nadal będziesz mieć inne pliki .htaccess -ish. Zasadniczo pliki, które mają .htaccess w ich imieniu, ale także inne słowa lub znaki.

Nie chcesz żadnego z nich. Chcesz tylko tego, który nazywa się .htaccess i nic więcej.

Dodanie kodu do pliku .htaccess w celu rozwiązania problemów bezpieczeństwa

Po zlokalizowaniu pliku będziesz miał go pobrać przed dokonaniem edycji. W ten sposób, jeśli coś pójdzie nie tak, masz kopię zapasową, którą możesz przesłać z powrotem do folderu.

Pobierz plik .htaccess przed dokonywaniem edycji.

Nic nie powinno pójść nie tak, ale lepiej być bezpiecznym niż wiesz-co .

Po bezpiecznym pobraniu kopii zapasowej możesz kontynuować edycję pliku .htaccess . W menedżerze plików CPANEL kliknij prawym przyciskiem myszy plik i wybierz Edytuj . Jeśli używasz FileZilla, kliknij prawym przyciskiem myszy i wybierz Wyświetl/Edytuj -otworzy to plik w domyślnym edytorze tekstu.

Następną częścią jest wierzchołek całej tej misji. Tutaj możesz przez chwilę poczuć się jak ekspert ds. Bezpieczeństwa WordPress. Ciesz się, gdy trwa.

Gdzie umieścić kod w swoim pliku .htaccess 👨🏻‍💻

Instalacje WordPress zazwyczaj mają tutaj kilka sekcji, oznaczone komentarzami, które zaczynają się od # BEGIN i # END .

Poszukaj linii, która to mówi:

 # END WordPress

Najbezpieczniejszym podejściem jest dodanie nagłówków bezpieczeństwa zaraz po tym . Jeśli nie widzisz dokładnej linii lub nie jesteś pewien, możesz dodać nagłówki na samym końcu pliku - po prostu zostawną pustą linię między dowolnym istniejącym kodem a nowymi dodatkami.

Oto kod:

 # BEGIN Security Headers Header unset X-Powered-By php_flag expose_php Off Header set X-Frame-Options "SAMEORIGIN" Header set X-Content-Type-Options "nosniff" Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' *; script-src 'self' 'unsafe-inline' 'unsafe-eval' * data: blob:; style-src 'self' 'unsafe-inline' *; img-src 'self' data: *; frame-src 'self' *; font-src 'self' data: *; media-src 'self' *;" Header set Referrer-Policy "strict-origin-when-cross-origin" Header set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" # END Security Headers

Po zakończeniu kliknij Zapisz zmiany w prawym górnym rogu. W przypadku użytkowników spoza Canel znajdź bez względu na to, co równoważny przycisk jest na własnym interfejsie.

Po tym, na uboczu możesz ponownie uruchomić skanowanie bezpieczeństwa, aby zobaczyć wpływ twoich zmian.

Ponownie wykonanie kontroli bezpieczeństwa

Najpierw sprawdź nagłówki bezpieczeństwa:

SecurityHeaders.com przekazał skanowanie bezpieczeństwa.

Nieźle, co?

Poszliśmy z F do A.

Porozmawiaj o blasku!

Każdy skonfigurowany nagłówek bezpieczeństwa pokazuje się jako poprawnie zaimplementowany.

Następnie sprawdźmy Sucuri:

Scan Sucuri po dodaniu kodu nagłówka.

Znacznie lepiej, ale dziwne, że są jeszcze dwa ostrzeżenia.

Pierwszy jest w rzeczywistości fałszywie pozytywny, ponieważ wiem, że moja witryna ma działanie słów. Nie mam żadnego wyjaśnienia tego innego niż być może Sucuri nie rozpoznaje fazu słów z jakiegokolwiek powodu. Jeśli widzisz to samo ostrzeżenie, a także wiesz, że masz zainstalowany WAF, po prostu go zignoruj.

Druga wiadomość jest jednak trochę inna. Pojawia się również w wyniku nagłówków bezpieczeństwa, poniżej gwiezdnego raportu ocen, który już ci pokazałem:

SecurityHeaders.com przekazał skan bezpieczeństwa, ale z ostrzeżeniami.

Oto rzecz:

Pomimo tego, że oba narzędzia były oznaczone jako „niebezpieczne”, korzystanie z niebezpiecznej in-linii jest w rzeczywistości całkowicie w porządku.

WordPress potrzebuje pewnych zdolności JavaScript i CSS do funkcjonowania - szczególnie w przypadku edytora bloków i wtyczek. Tak więc, chociaż istnieją technicznie surowsze sposoby, aby sobie z tym poradzić (o tym są te odniesienia nonces ), zrobienie tego złamałoby twoją stronę. Dosłownie.

Najlepszą analogią tutaj jest myślenie o domu. Możesz technicznie sprawić, by Twój dom był „bezpieczniejszy”, uszczelniając wszystkie okna i drzwi cementem, ale to czyni to twój dom niefunkcjonalny. To ten sam pomysł.

Owinięcie

Wtyczki bezpieczeństwa WordPress są podstawą dobrej strategii bezpieczeństwa - ale nie mogą sięgnąć do poziomu serwera, w którym należy ustawić pewne krytyczne zabezpieczenia.

7 podatności na wtyczki #WordPress #Security nie mogą cię chronić przed 🔐
Kliknij, aby tweetować

Zrzuty ekranu przed i po skanach bezpieczeństwa, które widziałeś, są tego dowodem.

A teraz, kiedy przeczytałeś ten samouczek, Ty również możesz przejąć swoje zabezpieczenia WordPress z „Plugin chronione” do „Zabezpieczonego na poziomie serwera”.

Ostatnio, jako najlepsza praktyka bezpieczeństwa, zalecam również wykonanie:

  • Uruchom te skany bezpieczeństwa co miesiąc.
  • Zachowaj dokumentację swoich konfiguracji bezpieczeństwa.
  • Przetestuj po głównych aktualizacjach WordPress, aby upewnić się, że wszystko działa zgodnie z przeznaczeniem.
  • Zmień adres strony logowania.
  • Ograniczyć próby logowania.
  • Aktywuj uwierzytelnianie dwuskładnikowe (lub w skrócie 2FA).
  • Informuj wtyczki i motywy i usuń te, których nie używasz.

… I wiele więcej. Bezpieczeństwo WordPress może zabrać Cię w głęboką króliczą dziurę, ale to, czego się tu nauczyłeś, wystarczy, aby zacząć i chronić witrynę przed większością ataków.

Czy masz jakieś pytania? Daj mi znać w komentarzach. Z przyjemnością ci pomogę.

Yay! Doszedłeś do końca artykułu!