tryb debugowania na produkcji

Tryb debugowania na produkcji to pozostawienie włączonych narzędzi diagnostycznych, w WordPressie przede wszystkim stałej WP_DEBUG, na stronie dostępnej dla odwiedzających. Dokumentacja WordPressa odradza używanie WP_DEBUG i innych narzędzi debugowania na stronach produkcyjnych, bo są przeznaczone do testów lokalnych i instalacji testowych ^[1]. MITRE opisuje ogólny problem jako CWE-215: produkt umieszcza informacje wrażliwe w kodzie debugowania, co może je ujawnić, jeśli debugowanie nie zostanie wyłączone na produkcji ^[2].

Jak działa

WP_DEBUG to stała PHP, która włącza tryb debugowania w całym WordPressie ^[1]. Domyślnie ma wartość false, a na kopiach deweloperskich zwykle ustawia się ją na true w pliku wp-config.php ^[1]. Po włączeniu WordPress wyświetla wszystkie błędy, ostrzeżenia i uwagi PHP ^[1]. To zmienia domyślne zachowanie PHP, które pokazuje tylko błędy krytyczne albo pusty ekran ^[1].

Trybowi towarzyszą dwie stałe, które decydują, dokąd trafiają komunikaty.

Obie stałe zależne działają tylko wtedy, gdy WP_DEBUG ma wartość true ^[1]. Gdy WP_DEBUG_LOG ma wartość true, dziennik trafia do katalogu treści, zwykle wp-content/debug.log ^[1]. Można też podać pełną ścieżkę do innego pliku ^[1]. Dziennik przydaje się, gdy komunikaty powstają poza ekranem, na przykład podczas żądania AJAX albo zadania wp-cron ^[1]. Ta sama wygoda sprawia, że plik rośnie po cichu, a administrator często nie pamięta o jego istnieniu.

Dokumentacja przypomina pułapkę w zapisie: wartości true i false podaje się bez apostrofów. Wartość 'false' w cudzysłowie jest napisem, a WordPress potraktuje ją jak true ^[1].

W WordPressie

Na stronie WordPress ryzyko ma dwie postaci.

Komunikaty na ekranie. Przy domyślnym WP_DEBUG_DISPLAY komunikaty pojawiają się w kodzie strony, którą widzi każdy odwiedzający ^[1]. MITRE opisuje ten wzorzec jako CWE-209. Komunikat może zdradzić pełną ścieżkę zainstalowanej aplikacji, a nieudana próba SQL injection może ujawnić zapytanie i logikę bazy ^[3]. To przykład ogólniejszego zjawiska, jakim jest ujawnienie informacji. Ułatwia też ujawnianie wersji wtyczek i PHP.

Plik debug.log. Plik w wp-content leży w katalogu serwowanym przez serwer WWW. Jeśli serwer nie blokuje do niego dostępu, każdy, kto zna ścieżkę, może go pobrać. Wtedy należy do grupy publicznie dostępne pliki wrażliwe. MITRE opisuje zapis danych wrażliwych do logu jako CWE-532 ^[4]. Do dziennika zapisują się nie tylko błędy rdzenia, lecz także komunikaty wtyczek, a te bywają zbyt szczegółowe.

Przebieg nadużycia pliku dziennika pokazuje schemat poniżej.

RYS. 1Od debug.log do przejęcia konta

Zagrożenia i skutki

OWASP Top 10 z 2021 roku zalicza do kategorii A05 Security Misconfiguration obsługę błędów, która pokazuje użytkownikom zrzuty stosu albo inne zbyt szczegółowe komunikaty ^[5]. W jednym ze scenariuszy serwer aplikacji zwraca szczegółowe komunikaty błędów. To może ujawnić dane wrażliwe albo wersje komponentów, o których wiadomo, że są podatne ^[5]. Po polsku tę kategorię opisuje hasło błędna konfiguracja zabezpieczeń.

Skutki zależą od zawartości komunikatów:

• ścieżki serwera i nazwy tabel ułatwiają dalsze ataki, na przykład path traversal ^[3];
• ciasteczka i tokeny sesyjne w logu pozwalają na przejęcie sesji;
• dane dostępowe w logu prowadzą do przejęcia konta.

Jak się bronić

Podstawowa zasada wynika z dokumentacji: debugowanie włącza się na środowisku testowym, a nie na produkcji ^[1]. Jeśli trzeba zdiagnozować błąd na działającej stronie, dokumentacja zaleca ustawienie WP_DEBUG_DISPLAY na false razem z WP_DEBUG_LOG, by błędy dało się przejrzeć później ^[1]. Dziennik można skierować do pliku poza katalogiem publicznym ^[1].

// wp-config.php na produkcji
define( 'WP_DEBUG', false );

// krótka diagnostyka: log poza katalogiem strony, bez komunikatów na ekranie
// define( 'WP_DEBUG', true );
// define( 'WP_DEBUG_DISPLAY', false );
// define( 'WP_DEBUG_LOG', '/home/example/logs/wp-errors.log' );

Jeśli plik musi zostać w wp-content, serwer powinien blokować do niego dostęp. W Apache służy do tego dyrektywa Require all denied, która odmawia dostępu wszystkim żądaniom ^[7]. Stałe debugowania zapisuje się w wp-config.php; ochronę tego pliku opisuje hasło utwardzanie pliku wp-config.php. Po zakończeniu diagnozy log trzeba usunąć.

Warto też sprawdzać ustawienia debugowania samych wtyczek. Mają one własne przełączniki, niezależne od WP_DEBUG, jak pokazuje przykład poniżej.

Historia i przykłady

LiteSpeed Cache (CVE-2024-44000). Sekurak 9 września 2024 roku opisał podatność we wtyczce LiteSpeed Cache pozwalającą nieuwierzytelnionemu atakującemu przejąć konto ^[6]. Po włączeniu trybu debugowania w ustawieniach wtyczki powstawał plik debug.log w katalogu wp-content ^[6]. Trafiały do niego nagłówki odpowiedzi, w tym Set-Cookie z ciasteczkami pozwalającymi przejąć sesję zalogowanego użytkownika, także administratora ^[6]. Warunkami były włączona opcja debugowania, która nie jest ustawieniem domyślnym, oraz dostępność pliku do odczytu ^[6]. Poprawki wydano w wersji 6.5.0.1 ^[6].

Ten sam artykuł przypomina, że wcześniejsza analiza CVE-2024-28000 wykazała zapis do tego pliku wartości tokenu, który przy tamtej podatności pozwalał przejąć konto użytkownika ^[6].