Zabezpieczanie debug log WordPress

Gdy debugowanie WordPress jest włączone, błędy i ostrzeżenia są zapisywane do pliku log pod /wp-content/debug.log. Jest to niezwykle przydatne podczas tworzenia. Jednak na witrynie produkcyjnej publicznie dostępny debug log to poważne ryzyko bezpieczeństwa. Każdy, kto zna URL, może go odczytać, a często zawiera znacznie bardziej poufne informacje, niż większość właścicieli witryn zdaje sobie sprawę.

Co zawiera debug log

Plik debug.log to nie tylko lista ostrzeżeń PHP. W zależności od konfiguracji Twojej witryny i używanych wtyczek może zawierać:

• Błędy i ostrzeżenia PHP: Zawierają ścieżki plików, numery linii i nazwy funkcji. Atakujący może użyć tych informacji do mapowania struktury katalogów Twojego serwera i identyfikacji podatnego kodu.
• Błędy zapytań do bazy danych: Nieudane zapytania czasami zawierają nazwy tabel, nazwy kolumn, a nawet fragmenty pobieranych danych. Daje to atakującym wgląd w schemat Twojej bazy danych.
• Błędy wtyczek i motywów z stack trace: Stack trace ujawniają, jakich wtyczek używasz, ich wersje i jak współdziałają. Jest to cenne do planowania ukierunkowanych ataków na znane podatności wtyczek.
• Klucze API i dane uwierzytelniające: Źle napisane wtyczki czasami logują odpowiedzi API lub błędy połączeń zawierające tokeny uwierzytelniające, klucze API lub nawet hasła w postaci jawnej.
• Dane użytkowników i adresy e-mail: Błędy związane z rejestracją użytkowników, przesyłaniem formularzy lub wysyłaniem e-maili mogą zawierać dane osobowe takie jak imiona, adresy e-mail i wprowadzane dane formularzy.
• Ścieżki systemu plików: Każdy błąd PHP zawiera pełną ścieżkę serwerową do pliku, w którym wystąpił błąd. Ujawnia to strukturę katalogów hostingu, nazwę użytkownika, a czasem dostawcę hostingu.

Dlaczego debug log jest publicznie dostępny

Domyślnie WordPress przechowuje debug.log w katalogu wp-content. Ten katalog jest serwowany przez Twój serwer webowy tak samo jak każdy inny folder w Twojej instalacji WordPress. O ile specjalnie nie zablokujesz dostępu, każdy może wpisać https://twojawitryna.pl/wp-content/debug.log w przeglądarce i odczytać plik.

Wielu dostawców hostingu nie blokuje tej ścieżki domyślnie. A ponieważ plik rośnie z czasem bez automatycznej rotacji, może gromadzić miesiące lub nawet lata poufnych danych o błędach.

Jak atakujący znajdują debug logi

Automatyczne skanery rutynowo sprawdzają /wp-content/debug.log na każdej napotkanej witrynie WordPress. Jest to jedna z pierwszych ścieżek, które testują narzędzia skanowania bezpieczeństwa. Niektórzy atakujący sprawdzają też typowe warianty:

• /wp-content/debug.log (domyślna lokalizacja)
• /debug.log (czasem źle skonfigurowane)
• /wp-content/uploads/debug.log (kolejna typowa niepoprawna konfiguracja)
• /error_log lub /error.log (ogólne nazwy logów błędów)

Te skany są tanie, szybkie i w pełni zautomatyzowane. Jeśli Twój debug log jest dostępny, zostanie znaleziony.

Blokowanie dostępu przez .htaccess (Apache)

Jeśli Twój serwer działa na Apache, dodaj tę regułę do pliku .htaccess w katalogu wp-content:

    Order allow,deny
    Deny from all

To mówi Apache, aby odmawiał wszystkich żądań HTTP dla pliku debug.log. Plik nadal istnieje na dysku, a PHP nadal może do niego pisać, ale nikt nie może go pobrać przez przeglądarkę. Jeśli chcesz zablokować wszystkie pliki log dla ostrożności, możesz użyć szerszej reguły:

    Order allow,deny
    Deny from all

Blokowanie dostępu z Nginx

Dla serwerów Nginx dodaj ten blok location do konfiguracji serwera:

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Zwracanie 404 zamiast 403 jest świadomym wyborem. Odpowiedź 403 (Forbidden) mówi atakującemu, że plik istnieje, ale jest chroniony. 404 (Not Found) nie zdradza niczego. Po dodaniu tej reguły przeładuj konfigurację Nginx za pomocą sudo nginx -s reload.

Przenieś plik log poza webroot

Najbezpieczniejszym podejściem jest przechowywanie debug log w katalogu, którego Twój serwer webowy w ogóle nie może serwować. W wp-config.php ustaw stałą WP_DEBUG_LOG na bezwzględną ścieżkę poza webroot:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/twojuzytkownik/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

Katalog /home/twojuzytkownik/logs/ musi istnieć i być zapisywalny przez proces serwera webowego. Ustawienie WP_DEBUG_DISPLAY na false jest równie ważne: zapobiega bezpośredniemu wyświetlaniu błędów PHP na Twoich stronach, gdzie odwiedzający (i atakujący) mogliby je zobaczyć.

Wyłącz tryb debugowania na witrynach produkcyjnych

Na żywej witrynie produkcyjnej debugowanie powinno być prawie zawsze wyłączone. Rzadko istnieje dobry powód, aby pozostawić je trwale włączone. Ustaw te wartości w wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Jeśli musisz debugować problem na produkcji, włącz tryb debugowania tymczasowo, odtwórz problem, sprawdź log i wyłącz go natychmiast po. Nigdy nie zostawiaj debugowania "na wszelki wypadek". Ryzyko nie jest warte wygody.

Monitoruj rozmiar pliku debug log

Jeśli pozostawisz debugowanie włączone na witrynie staging lub deweloperskiej, monitoruj rozmiar debug log. Bez rotacji logów może urosnąć do setek megabajtów i ostatecznie wypełnić Twój dysk. Rozważ ustawienie cron job do jego rotacji lub przycinania:

# Rotate debug.log weekly, keep 4 backups
# Add to /etc/logrotate.d/wp-debug
/home/twojuzytkownik/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Co zrobić, jeśli poufne dane zostały już ujawnione

Jeśli Twój debug log był publicznie dostępny i zawierał poufne informacje, natychmiast podejmij te kroki:

• Usuń plik debug log: Usuń go bezpośrednio z serwera.
• Zrotuj wszystkie klucze API i dane uwierzytelniające: Każdy klucz API, hasło lub token, który pojawił się w logu, należy uznać za skompromitowany. Wygeneruj je ponownie.
• Zmień hasła do bazy danych: Jeśli logowane były błędy połączenia z bazą danych, dane uwierzytelniające mogły zostać ujawnione.
• Sprawdź pod kątem nieautoryzowanego dostępu: Przejrzyj logi dostępu serwera pod kątem żądań dla debug.log. Jeśli ktoś go pobrał, oceń, jakie informacje zdobył.
• Powiadom dotkniętych użytkowników: Jeśli logowane były dane osobowe (e-maile, imiona, przesłane formularze), możesz mieć obowiązek GDPR lub w zakresie prywatności informowania dotkniętych osób.

Weryfikacja z InspectWP

InspectWP sprawdza, czy /wp-content/debug.log jest publicznie dostępny na Twojej witrynie. Po zabezpieczeniu pliku (zablokowanie dostępu, przeniesienie lub wyłączenie trybu debugowania) uruchom nowe skanowanie InspectWP. Sekcja bezpieczeństwa raportu potwierdzi, czy plik jest nadal osiągalny. Jeśli ostrzeżenie się utrzymuje, wyczyść wszelkie pamięci podręczne po stronie serwera i zweryfikuj, że Twoje reguły .htaccess lub Nginx są stosowane do odpowiedniego katalogu.