Kolejny tydzień, kolejne informacje o podatnościach w WordPressie. Elementor, TranslatePress, inne pluginy, poważne poprawki bezpieczeństwa. Patrząc wyłącznie na nagłówki można dojść do prostego wniosku: matko jedyna, ten WordPress to musi być jakiś dramat, skoro ciągle trzeba coś w nim łatać.

Tylko że to jest dokładnie odwrotny wniosek od tego, który powinniśmy wyciągnąć.

Oprogramowanie trzeba utrzymywać. Każde. WordPress nie jest tu wyjątkiem. Jest po prostu systemem, w którym właściciel strony wyjątkowo dobrze widzi, że to utrzymanie się odbywa. Pojawia się aktualizacja, WordPress pokazuje ją w panelu i w ogromnej części zwykłych przypadków cała operacja sprowadza się do backupu, kliknięcia „Aktualizuj” i sprawdzenia, czy strona działa prawidłowo.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

Zmiana WordPressa na inny CMS, framework albo aplikację napisaną od zera nie powoduje magicznego zniknięcia tego obowiązku.

To trochę jak stwierdzenie, że skoro w silniku trzeba wymieniać olej, to kupimy inny samochód albo silnik i tam oleju już wymieniać nie będziemy. Będziemy. Tylko być może nie będzie już kontrolki przypominającej, że właśnie nadszedł czas.

TranslatePress: groźna luka, ale spójrzmy na całą historię

25 sierpnia Wordfence publicznie opisał krytyczną podatność w TranslatePress, popularnym dodatku do tworzenia wielojęzycznych stron. W określonych warunkach atakujący bez zalogowania mógł zdobyć link pozwalający zresetować hasło administratora, a następnie przejąć konto.

Brzmi źle, bo było źle.

Znacznie ciekawsza jest jednak chronologia. Badacz zgłosił problem 11 sierpnia. Wordfence zweryfikował go i przekazał producentowi 12 sierpnia. Dzień później producent wypuścił poprawioną wersję 3.3.2. Publiczny opis podatności pojawił się dopiero 25 sierpnia, kiedy poprawka była już dostępna.

I na tym historia się nie kończy. Oficjalne repozytorium WordPressa pokazuje obecnie TranslatePress 3.3.4. Ta wersja usuwa kolejną podatność, tym razem pozwalającą w pewnych warunkach wstrzyknąć złośliwy kod do strony. Plugin ma ponad 400 tysięcy aktywnych instalacji, więc dosyć sporo.

Czy właściciel strony powinien teraz studiować identyfikatory CVE, analizować kod PHP i zastanawiać się nad szczegółami ataku?

Nie.

Jeśli korzystasz z TranslatePress, sprawdź aktualizacje i zainstaluj najnowszą dostępną wersję. Jeśli stroną zajmuje się ktoś inny, upewnij się, że aktualizacja została wykonana.

To wszystko.

Co więcej, w samym WordPressie nie wydarzyła się w tym tygodniu żadna nowa katastrofa bezpieczeństwa. Oficjalna lista wydań pokazuje WordPress 7.1 z 19 sierpnia, a ostatnie wydanie oznaczone jako security release, WordPress 7.0.4, pochodzi z 12 sierpnia. Przy nim WordPress sam instruował użytkowników, żeby wejść do Dashboard > Updates i kliknąć Update Now.

Warto więc odróżniać „WordPress ma kolejną lukę” od „znaleziono lukę w jednym z tysięcy rozszerzeń dostępnych dla WordPressa”. To nie jest to samo.

A teraz wyrzućmy WordPressa. Czy aktualizacje zniknęły?

Nie.

25 sierpnia OpenSSL opublikował nowe wersje kilku wspieranych gałęzi wraz z advisory dotyczącym bezpieczeństwa. OpenSSL to jeden z podstawowych elementów infrastruktury internetowej odpowiedzialnych między innymi za operacje kryptograficzne. Nie jest pluginem WordPressa i nie ma nic wspólnego z tym, jaki CMS wybierzesz.

Tego samego dnia Debian wydał własną aktualizację bezpieczeństwa pakietu OpenSSL i zalecił użytkownikom aktualizację. W tym samym tygodniu na liście Debiana pojawiły się także poprawki bezpieczeństwa, między innymi dla kernela Linux i innych komponentów systemu.

27 sierpnia PHP wydało wersje 8.5.10 i 8.4.25. W przypadku 8.5.10 była to wersja poprawkowa, a zespół PHP zalecił użytkownikom gałęzi 8.5 aktualizację.

I teraz dochodzimy do sedna.

Możesz zbudować stronę bez WordPressa. Możesz użyć własnej aplikacji, nowoczesnego frameworka, statycznego generatora, headless CMS albo czego tylko zapragniesz. Nadal masz system operacyjny, serwer, biblioteki, runtime, pakiety i zależności. One również dostają aktualizacje, poprawki błędów i poprawki bezpieczeństwa.

Różnica jest taka, że właściciel strony zwykle tego nie widzi.

Nie ma czerwonego kółeczka z cyfrą 6 w panelu WordPressa.

Ktoś musi wiedzieć, że poprawka się pojawiła. Ktoś musi ustalić, czy dotyczy projektu. Ktoś musi ją wdrożyć. Czasem wcześniej sprawdzić zgodność innych komponentów. Potem przetestować aplikację i wdrożyć zmianę na produkcję.

Jeżeli nikt tego nie robi, aplikacja nie staje się dzięki temu stabilna i bezpieczna.

Po prostu nikt jej nie serwisuje.

Cloudflare właśnie pokazał, jak naprawdę wygląda „zróbmy to inaczej”

Najlepszy przykład tego tygodnia dostarczył przypadkiem Cloudflare.

24 sierpnia firma opisała migrację swojego bloga na EmDash, CMS działający z Astro i infrastrukturą Cloudflare. Sama migracja odbyła się wcześniej, 12 sierpnia, ale właśnie teraz Cloudflare opublikował szczegółowy opis całego procesu.

I jest to bardzo ciekawa lektura dla każdego, kto uważa, że rezygnacja z dojrzałego CMS-a automatycznie upraszcza życie.

Podczas testów Cloudflare znalazł problemy związane między innymi z lokalizacją treści, SEO, Content Security Policy i działaniem panelu redakcyjnego. Największym przeoczeniem okazały się zaplanowane publikacje. Po prostu nie działały, dopóki problem nie został poprawiony w EmDash 0.19.0.

Potem przyszło pytanie, czy nowa platforma wytrzyma ruch. Cloudflare przygotował osobne scenariusze testowe, w tym nagły skok do 7000 żądań na sekundę.

A kiedy system był gotowy do produkcji, nie zrobiono „deploy i zobaczymy”. Powstał mechanizm pozwalający kierować ruch pomiędzy starą i nową wersją oraz wrócić do starej platformy w przypadku błędów serwera. W dniu uruchomienia najpierw skierowano na nową wersję 1 procent ruchu, potem 5 procent, 15 procent i dopiero po kolejnych kontrolach 100 procent.

Efekt jest bardzo dobry. Nowy blog jest szybki, platforma daje Cloudflare większą kontrolę i odpowiada ich potrzebom.

Ale właśnie o to chodzi.

To nie jest historia pod tytułem „WordPress jest prosty, więc custom jest zły”. Custom może być świetnym rozwiązaniem. EmDash również może być świetnym rozwiązaniem.

To jest historia pod tytułem: każde rozwiązanie trzeba utrzymywać, testować i rozwijać.

Cloudflare może sobie na taki model pozwolić, bo ma ludzi, infrastrukturę i kompetencje, żeby to wszystko zrobić.

Przeciętna piekarnia, kancelaria, hotel czy sklep internetowy nie potrzebują zespołu, który będzie budował system stopniowego przekierowywania ruchu między dwiema wersjami strony. Potrzebują działającej strony.

I tu nagle ten nudny przycisk „Aktualizuj” zaczyna wyglądać całkiem atrakcyjnie.

AI też zaczyna wymagać ustawień, a nie magicznego pliku robots.txt

W tygodniowym radarze warto też wrócić do informacji ogłoszonej przez Cloudflare 21 sierpnia, bo Bot Preference Sync został zapowiedziany jako funkcja dostępna dla wszystkich planów w kolejnym tygodniu.

Cloudflare rozdziela ruch botów AI na trzy zastosowania: Search, Agent i Training. Właściciel strony może więc podejmować inne decyzje dla botów pomagających znaleźć jego treści, inne dla agentów wykonujących zadania i inne dla crawlerów zbierających dane do trenowania modeli.

Bot Preference Sync ma synchronizować te ustawienia z robots.txt, dzięki czemu deklaracja publikowana dla crawlerów odpowiada regułom faktycznie egzekwowanym przez Cloudflare. Funkcja została zapowiedziana dla wszystkich planów od Free do Enterprise.

To jest ważna zmiana przede wszystkim dlatego, że kończy się epoka odpowiedzi „bot AI? blokować wszystkie”.

Cloudflare sam podaje dwa przeciwstawne przykłady. Sklep internetowy może chcieć, żeby produkty były dobrze widoczne również dla systemów AI. Wydawca zarabiający na odsłonach może chcieć pozostać widoczny w wyszukiwaniu, ale nie zgadzać się na wykorzystanie artykułów do treningu modeli.

Nie istnieje więc jedna dobra konfiguracja dla każdej firmy. Najpierw trzeba odpowiedzieć na pytanie, czego oczekujemy od obecności strony w świecie AI, a dopiero potem ustawiać boty.

Hasła też powoli przestają być jedyną opcją

25 sierpnia W3C opublikowało Web Authentication Level 3 jako oficjalną rekomendację. WebAuthn jest standardem stojącym za nowoczesnymi metodami logowania wykorzystującymi klucze kryptograficzne, w tym passkeys.

Dla właściciela zwykłej strony nie oznacza to żadnej akcji na dziś rano. Jest jednak kolejnym sygnałem, że logowanie bez opierania całego bezpieczeństwa na haśle staje się normalnym elementem współczesnego WWW.

Jeżeli strona ma konta klientów, rozbudowany panel albo szczególnie cenne konta administracyjne, przy kolejnej modernizacji systemu logowania warto już pytać nie tylko o silne hasła i 2FA, ale również o obsługę passkeys.

Co z tego tygodnia dotyczy Ciebie najbardziej?

Jeżeli masz WordPressa, nie potrzebujesz doktoratu z bezpieczeństwa. Potrzebujesz aktualnej strony, sprawnych backupów i kogoś, kto reaguje, kiedy aktualizacja nie jest zwykłym kliknięciem jednego przycisku. Wejdź do aktualizacji albo zapytaj osobę opiekującą się stroną, czy wszystko jest aktualne. Jeżeli używasz TranslatePress, szczególnie sprawdź, czy masz najnowszą wersję.

Jeżeli masz stronę customową, zadaj dokładnie to samo pytanie, tylko trochę szerzej: kto aktualizuje jej zależności, PHP lub inny runtime, serwer i system operacyjny? Kto dostaje informację o podatnościach? Jak wygląda proces wdrożenia poprawki?

A jeśli odpowiedź brzmi „nie wiem, ale strona działa”, to właśnie znaleźliśmy problem.

Komentarz WebsiteGarage

W WordPressie informacje o lukach są bardzo widoczne. To jedna z konsekwencji tego, że jest ogromnym ekosystemem, jest intensywnie badany i istnieje cały rynek ludzi, firm oraz narzędzi, które szukają w nim problemów.

I dobrze.

Znaleziona luka, zgłoszona producentowi i załatana luka jest znacznie mniej interesująca niż luka, o której nikt nie wie.

Najgorszą możliwą interpretacją tych informacji jest więc: „WordPress ciągle ma aktualizacje, dlatego zrobię custom i będę miał spokój”.

Nie będziesz.

Jeżeli do samochodu wsadzisz inny silnik, nadal trzeba będzie wymieniać olej. Nadal trzeba będzie go serwisować. Nadal coś kiedyś się zużyje albo zepsuje.

Różnica jest taka, że WordPress bardzo często sam zapala kontrolkę i pokazuje Ci przycisk „Aktualizuj”.

W rozwiązaniu customowym kontrolkę musi najpierw zaprojektować ktoś, kto pamiętał, że będzie potrzebna.

A prawdziwym problemem nie jest WordPress, custom, PHP czy jakikolwiek inny stos technologiczny.

Problemem jest oprogramowanie, którym po uruchomieniu nikt już się nie zajmuje.

Źródła