Krótko: Strona statyczna składa się z gotowych plików HTML, CSS i obrazów, które serwer WWW tylko serwuje. Ponieważ na serwerze nie działają PHP ani baza danych, luki takie jak PHP2Shell, SQL injection czy wprowadzone webshelle w dużej mierze odpadają jako ryzyko. Dla bezpieczeństwa strony statycznej liczą się za to inne rzeczy: chronione dostępy do hostingu, domeny i narzędzi budowania, utrzymywane zależności i starannie wybrane usługi obce. Nadaje się przede wszystkim dla stron, które rzadko się zmienia i które nie potrzebują kont klientów.
Dlaczego pytanie pada właśnie teraz
PHP2Shell pokazało wielu firmom, jak wiele zależy od jednego komponentu. Strona firmowa z dziesięcioma podstronami, aktualizowana raz na kwartał, działała na tym samym PHP co duży sklep internetowy i była przez to narażona na tę samą krytyczną lukę. Według doniesień medialnych nawet urzędy i gminy prewencyjnie wyłączyły strony.
Nasuwa się pytanie: czy w ogóle potrzebujemy PHP na serwerze dla naszej strony? W wielu małych i średnich firmach uczciwa odpowiedź brzmi: do serwowania często nie. PHP generuje stronę od nowa przy każdym wywołaniu, choć treść nie zmieniła się od tygodni. Jak to przebiega technicznie, opisuje artykuł Jak PHP generuje stronę internetową. Co oznacza sama luka, wyjaśnia artykuł Czym jest PHP2Shell?.
Jak działa strona statyczna
W przypadku strony statycznej strona nie jest generowana podczas wizyty, lecz wcześniej. Generator stron statycznych, na przykład Hugo, Jekyll lub Eleventy, bierze teksty, obrazy i szablony i buduje z nich gotowe pliki. Pliki te są ładowane na prosty serwer WWW lub do sieci dostarczania treści (content delivery network), czyli rozproszonej sieci serwowania.
Dla redaktorów przed tym może stać narzędzie do edycji, które przyjmuje zmiany i uruchamia przebudowę. Czasem stosuje się do tego tak zwane headless CMS, które tylko zarządza treściami i samo nie musi być publicznie dostępne. Odwiedzający nic z tego nie widzi; otrzymuje tylko gotowe pliki.
Strona statyczna a bezpieczeństwo w porównaniu
| Kryterium | Dynamiczne CMS z PHP | Strona statyczna |
|---|---|---|
| Logika programu na serwerze publicznym | Tak, przy każdym wywołaniu | Nie |
| Ryzyko wynikające z luk w interpreterze PHP | Tak, jak przy PHP2Shell | Odpada na serwerze serwującym |
| Baza danych publicznie podłączona | Tak | Nie |
| Typowe wejścia | Wtyczki, logowanie administratora, uploady, serwer | Dostępy do hostingu, domeny, systemu budowania, usługi obce |
| Formularze, wyszukiwarka, konto klienta | Wbudowane | Tylko przez usługi zewnętrzne lub osobne funkcje |
| Nakład pracy redaktorów | Niski, znany interfejs | Zależny od narzędzia redakcyjnego |
| Serwis | Regularne aktualizacje CMS, wtyczek i PHP | Aktualizacje narzędzi budowania i zależności |
| Przydatność | Sklepy, portale, wielu redaktorów, częste zmiany | Strony firmowe, landing page, dokumentacja |
Tabela pokazuje: powierzchnia ataku się przesuwa, nie znika. Zamiast publicznie dostępnego serwera PHP muszą Państwo chronić konto u firmy hostingowej, domenę, potok budowania i ewentualnie narzędzie redakcyjne.
Jakie ryzyka przy stronach statycznych pozostają
Po pierwsze dostępy. Kto przejmie konto hostingowe, dostęp do domeny lub repozytorium kodu, może zmienić stronę, zupełnie bez PHP. Logowanie dwuskładnikowe i osobiste konta są więc obowiązkowe.
Po drugie zależności. Generatory i szablony często przynoszą wiele pakietów, na przykład z npm. Muszą być utrzymywane w aktualnym stanie, ponieważ skompromitowana zależność może przy budowaniu wpisać złośliwy kod do gotowych plików. Jak to zorganizować, opisuje artykuł Utrzymywanie zależności w aktualnym stanie.
Po trzecie usługi obce. Usługi formularzy, funkcje wyszukiwania, narzędzia analityczne i włączone skrypty działają w przeglądarce odwiedzających lub na obcych serwerach. Każda z tych usług to relacja zaufania, także pod względem ochrony danych.
Po czwarte strona przeglądarki. Także strona statyczna powinna ustawiać nagłówki bezpieczeństwa, na przykład Content-Security-Policy, który określa, jakie skrypty wolno ładować. Podstawy znajdują się w artykule Nagłówki bezpieczeństwa dla stron internetowych.
Przed przejściem proszę sprawdzić, z jakich funkcji Państwa strona faktycznie korzysta. Często jest ich mniej, niż się myśli: strony, obrazy, formularz kontaktowy. Wtedy droga do strony statycznej jest krótsza, niż się początkowo wydaje.
Dla kogo przejście się opłaca, a dla kogo nie
Strona statyczna dobrze nadaje się dla stron firmowych o niewielkim zakresie, landing page do kampanii, dokumentacji produktów i stron kariery. Przejście opłaca się szczególnie wtedy, gdy dotychczasowa strona działa na starej wersji PHP, a aktualizacja i tak byłaby na horyzoncie.
Mniej nadaje się dla sklepów internetowych, portali klientów, systemów rezerwacji i stron z wieloma redaktorami publikującymi codziennie. Tutaj sensowny pozostaje system dynamiczny. Pomocna może być forma mieszana: sklep pozostaje dynamiczny i jest dobrze utwardzony, poradniki i strony firmowe są serwowane statycznie.
Często niedoceniana zaleta ujawnia się w razie awarii. Ponieważ gotowe pliki można w każdej chwili zbudować od nowa z szablonów i treści, zmanipulowaną stronę można szybko przywrócić do znanego, czystego stanu. Warunkiem jest, aby treści i szablony leżały w chronionym repozytorium, zmiany były czytelnie protokołowane i nikt nie edytował plików bezpośrednio na serwerze.
Usługodawcy bezpieczeństwa nie potrzebują Państwo do przejścia koniecznie; może go przejąć agencja lub programista. Jeśli dotychczasowa strona była jednak skompromitowana, treści należy przed przejęciem sprawdzić. Porusza to artykuł Zmienić CMS po włamaniu?.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy, jakich funkcji Państwa strona faktycznie potrzebuje, i mówimy otwarcie, czy rozwiązanie statyczne się nadaje.
- Przy przejściu zabezpieczamy dostępy do hostingu, domeny i systemu budowania logowaniem dwuskładnikowym i osobistymi kontami.
- Sprawdzamy usługi obce i ustawiamy nagłówki bezpieczeństwa, aby nowa strona była dobrze chroniona także w przeglądarce.
- Dla pozostających systemów PHP przejmujemy aktualizacje i nadzór w ramach umowy serwisowej w zakresie bezpieczeństwa.
Podsumowanie
Strona statyczna nie jest lekiem na wszystko, ale dla wielu stron firmowych to najprostszy sposób na pozbycie się całej klasy ryzyk. Tam, gdzie nie działa PHP, PHP2Shell nic nie wskóra. Zyskane bezpieczeństwo utrzyma się jednak tylko wtedy, gdy dostępy, zależności i usługi obce będą traktowane równie poważnie jak dawniej serwer.
Częste pytania
Czy stronę statyczną można mimo to zhakować?
Tak. Odpada logika programu po stronie serwera, a wraz z nią duża klasa ataków. Podatne na atak pozostają jednak dostępy do hostingu, domeny i systemu budowania, włączone usługi obce i narzędzia, którymi strona jest generowana.
Czy strona statyczna może mieć formularze kontaktowe?
Tak, przez zewnętrzną usługę formularzy lub niewielką, osobno prowadzoną funkcję. Wtedy przetwarzanie danych leży po stronie tej usługi. Proszę wyjaśnić ochronę danych i powierzenie przetwarzania, zanim ją Państwo włączą.
Czy redaktorzy mogą samodzielnie prowadzić stronę statyczną?
Z odpowiednim narzędziem redakcyjnym tak. Wiele rozwiązań oferuje interfejs do edycji, z którego strona jest następnie generowana na nowo. Dla zespołów zmieniających codziennie wiele treści klasyczne CMS jest jednak często wygodniejsze.
Czy przejście opłaca się w przypadku sklepu internetowego?
Zwykle nie w całości. Koszyk, konto klienta i płatność wymagają logiki po stronie serwera. Możliwe jest serwowanie części, takich jak poradniki czy strony firmowe, statycznie i prowadzenie sklepu osobno.