środowisko testowe

Środowisko testowe (staging) to odrębna kopia strony, utrzymywana obok wersji produkcyjnej i służąca do sprawdzania zmian, zanim trafią do odwiedzających. WordPress rozpoznaje cztery typy środowisk: local, development, staging i production ^[1]. Z punktu widzenia bezpieczeństwa środowisko testowe jest częścią powierzchni ataku tak samo jak produkcja. Zawiera ten sam kod, często kopię tych samych danych i kont, a bywa chronione słabiej i aktualizowane rzadziej.

Jak działa

Punktem wyjścia jest zwykle kopia produkcji. Dokumentacja WordPressa opisuje rozsądną strategię kopii jako regularne migawki całej instalacji, razem z plikami rdzenia i bazą danych, przechowywane w zaufanym miejscu ^[8]. Taka kopia zapasowa (backup) nadaje się też do postawienia stagingu. Na kopii wprowadza się zmianę, na przykład aktualizację wtyczki, nową wersję motywu albo inną konfigurację serwera, sprawdza jej skutki i dopiero potem powtarza ją na produkcji.

RYS. 1Zmiana przez środowisko testowe

Tę samą zasadę stosują zespoły reagowania na incydenty. CERT Polska w komunikacie z 11 grudnia 2021 roku o krytycznej podatności w bibliotece Log4j zalecił, aby tymczasowe obejście, wymagające restartu usługi, zostało najpierw przeprowadzone w środowisku testowym ^[6]. Nawet pilna łatka (patch) albo obejście niesie ryzyko awarii, a sprawdzenie ich na kopii to ryzyko ogranicza.

Rodzaje środowisk

Podział na typy środowisk nie jest specyficzny dla WordPressa, ale rdzeń nadaje mu konkretne nazwy i skutki. Zestawienie poniżej odpowiada wartościom zwracanym przez funkcję wp_get_environment_type().

W WordPressie

Typ środowiska ustawia się zmienną środowiskową PHP albo stałą WP_ENVIRONMENT_TYPE; stała nadpisuje wartość zmiennej ^[2]. Gdy podana wartość nie należy do listy dozwolonych, WordPress zwraca domyślne production ^[2]. Funkcja wp_get_environment_type() jest dostępna od wersji 5.5.0 ^[1]. Najprostszy sposób to stała w pliku konfiguracyjnym kopii:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Motyw albo wtyczka może odczytać tę wartość i na stagingu zachowywać się inaczej niż na produkcji. Trzeba jednak pamiętać o skutku ubocznym typu development: jeśli stała WP_DEBUG nie jest zdefiniowana, WordPress ją włącza ^[2]. Na kopii dostępnej z internetu oznacza to ryzyko trybu debugowania widocznego dla obcych.

Indeksowanie. W ustawieniach czytania WordPress ma opcję „Discourage search engines from indexing this site”. Od wersji 5.3 powoduje ona dodanie do nagłówka strony znacznika robots z wartością noindex,nofollow ^[3]. Dokumentacja zaznacza jednak, że opcja nie blokuje dostępu do witryny, a uszanowanie prośby zależy od wyszukiwarek ^[3]. Google podobnie ostrzega, że plik robots.txt nie jest sposobem na utrzymanie strony poza wynikami wyszukiwania; zaleca noindex albo ochronę hasłem ^[4]. Dlatego staging zamyka się przed obcymi, na przykład przez zabezpieczenie katalogu hasłem albo białą listę adresów IP.

Zagrożenia i skutki

OWASP zalicza do błędnej konfiguracji zabezpieczeń między innymi niepotrzebnie włączone funkcje, strony, konta i uprawnienia, domyślne konta z niezmienionymi hasłami oraz komunikaty błędów ujawniające ślady stosu ^[5]. Środowisko testowe łatwo spełnia kilka tych warunków naraz, bo uchodzi za tymczasowe.

• Porzucona kopia. Staging, którego nikt nie aktualizuje, zachowuje stare wersje wtyczek. Znana podatność we wtyczce, załatana na produkcji, pozostaje wtedy otwarta na kopii w tej samej domenie lub na tym samym serwerze.
• Kopia danych. Baza skopiowana z produkcji zawiera konta użytkowników i dane klientów. Ich wyciek ze słabiej chronionej kopii ma te same skutki co wyciek z produkcji.
• Wspólne hasła. Te same dane uwierzytelniające na obu środowiskach sprawiają, że przejęcie stagingu otwiera drogę do produkcji.
• Ślad w wyszukiwarce. Zaindeksowany adres testowy to ujawnienie informacji o wersjach i planowanych zmianach.
• Połączenie z produkcją. Kopia, która korzysta z produkcyjnej bazy albo usług, wykonuje realne operacje, na przykład wysyła wiadomości do prawdziwych klientów.

Dobre praktyki

OWASP zaleca powtarzalny, najlepiej zautomatyzowany proces utwardzania, w którym środowiska deweloperskie, testowe i produkcyjne są skonfigurowane identycznie, ale każde ma inne dane uwierzytelniające ^[5]. Zaleca też minimalną platformę bez zbędnych funkcji, komponentów i przykładów ^[5].

• Ustawić WP_ENVIRONMENT_TYPE na staging, aby kod mógł rozpoznać kopię ^[2].
• Zamknąć dostęp hasłem albo listą adresów, zamiast polegać na prośbie o nieindeksowanie ^[4].
• Nadać kopii osobne hasła i klucze, a konta ograniczyć zgodnie z zasadą najmniejszych uprawnień.
• Objąć staging tą samą aktualizacją oprogramowania co produkcję albo usuwać go po zakończeniu prac.
• Odciąć kopię od produkcyjnej bazy, bramek płatności i wysyłki poczty.

Historia i przykłady

Niebezpiecznik 25 września 2014 roku opisał potwierdzenia zakupu biletów, które PKP Intercity w nocy z 24 na 25 września rozesłało do klientów, choć ci niczego nie kupowali ^[7]. Przewoźnik tłumaczył wysyłkę testami nowych funkcjonalności systemu sprzedaży ^[7]. Autorzy wpisu uznali, że najprawdopodobniej były one wynikiem niedokładnego przetestowania nowej wersji systemu albo prac na produkcji lub na stagingu podpiętym do produkcyjnej bazy ^[7]. Przykład pokazuje, że środowisko testowe chroni produkcję tylko wtedy, gdy jest od niej naprawdę oddzielone.