Bilet WordPress nr 30465 został otwarty 10 lat temu – czy rok 2025 będzie rokiem, w którym w końcu zostanie rozwiązany?

W listopadzie 2014 r. programista WordPressa, Sergej Mueller, zgłosił uzasadnione obawy: użytkownicy nie mieli możliwości dowiedzenia się, czy wtyczka, której używali, została usunięta z oficjalnego repozytorium – nawet jeśli została usunięta ze względów bezpieczeństwa. Jego bilet – oficjalnie nr 30465 – został zamknięty stosunkowo niedługo potem, ale bez rozstrzygnięcia. Siergiej nie wiedział, że zostanie ponownie otwarty prawie dziesięć lat później .

I oto jesteśmy na początku 2025 roku, kiedy piszę aktualizację na ten temat.

Dlaczego?

Z kilku powodów.

Po pierwsze, jest to bardzo istotne dla niektórych wydarzeń związanych z bezpieczeństwem wtyczek, które miały miejsce niedawno – a dokładnie w październiku ubiegłego roku. Opowiem o nich wkrótce. Po drugie, wola i dynamika rozwiązania problemu nabrały poważnego tempa – ostatnia aktywność na zgłoszeniu miała miejsce niecały miesiąc temu:

Wygląda więc na to, że cierpliwość Siergieja może wkrótce wreszcie się opłacić…

Zacznijmy od odtworzenia rozwoju biletu. Następnie możemy przejść do tego, co działo się z nim w ostatnich tygodniach:

Od „nie naprawię” do wyjścia na scenę na WCEU 2023 🙅‍♂️

Kiedy zgłoszenie zostało otwarte po raz pierwszy, otrzymało kilka odpowiedzi, ale zostało dość szybko zamknięte przez głównego programistę WordPressa, Andrew Nacina. Zamknął go i oznaczył jako „nie zostanie naprawiony”, wyjaśniając, że usunięcie wtyczek nastąpiło z różnych powodów, nie tylko ze względów bezpieczeństwa:

Potem nastąpiła lawina komentarzy, które jednak ucichły i zamieniły się w publikowany raz do roku (czasami nawet rzadziej) komentarz kogoś próbującego ożywić tę kwestię.

Potem, w marcu 2023 r ., wydarzyło się coś interesującego. Joost de Valk, dobrze znana postać w społeczności WordPress, oficjalnie ponownie otworzył bilet . Argumentował, że WordPress ma obowiązek informować użytkowników, czy wtyczka jest utrzymywana, czy nie.

Zwrócił także uwagę, że WordPress.org pokazywał już tę informację na samej platformie, ale dopiero po 60-dniowym okresie oczekiwania. Jego sugestia polegała na zapewnieniu tej samej przejrzystości backendowi WordPressa, gdzie użytkownicy faktycznie zarządzają swoimi wtyczkami.

To wywołało nową falę entuzjazmu w całym wątku. Bilet stał się tak popularny , że Oliver Sild, dyrektor generalny i współzałożyciel Patchstack, wspomniał nawet o nim w swoim przemówieniu na WCEU 2023 :

Nie tylko o tym wspomniał, ale zachęcał uczestników WCEU do pozostawiania komentarzy w wątku za pomocą niestandardowego kodu QR, który dodał do swojej prezentacji. Użył tej wtyczki także jako opóźnionego występu w konkursie, który Patchstack miał zorganizować w następnym roku.

Wydarzenie Patchstack w październiku 2024 r. 🪲

W październiku 2024 r. firma Patchstack zorganizowała wydarzenie Bug Bounty w ramach Miesiąca Bezpieczeństwa Cybernetycznego. Jeśli wzmianka Olivera o bilecie nr 30465 w jego przemówieniu na WCEU była strzałem w dziesiątkę, wówczas rezultatem tego wydarzenia byłby wsad.

Badacze bezpieczeństwa, którzy wzięli udział w tym wydarzeniu, odkryli w ciągu jednego miesiąca oszałamiającą liczbę 1571 prawidłowych raportów o lukach w zabezpieczeniach. To nie były tylko drobne problemy – mówimy o:

• 73 przypadki, w których napastnicy mogli przesłać złośliwe pliki.
• 67 luk w zabezpieczeniach związanych z iniekcją SQL, które mogą zagrozić całym bazom danych.
• 58 sposobów, w jakie atakujący mogą eskalować swoje uprawnienia.
• 17 luk w zabezpieczeniach umożliwiających zdalne wykonanie kodu (yikes!)

Następstwa spowodowały tymczasowe zamknięcie blisko 1000 wtyczek. A kiedy Patchstack próbował skontaktować się z twórcami wtyczek w sprawie tych problemów, prawie 74% było całkowicie nieosiągalnych. Albo ich formularze kontaktowe zostały zepsute, ich e-maile zostały odesłane, albo ich domeny wygasły.

Najlepsze jest to, że wiele z tych podatnych na ataki wtyczek znajdowało się w repozytorium od 6 do 11 lat. Niektóre miały nawet 17 lat! I tak, nadal istnieją działające strony internetowe w zależności od tych wtyczek.

Nie trzeba dodawać, że wszystkie te dane dały Oliverowi przewagę w wątku, aby popchnąć zgłoszenie nr 30465 do przodu. Chętnie z tego skorzystał i zamieścił kilka szczegółów na dwa tygodnie przed publikacją oficjalnego wpisu na blogu Patchstack omawiającego wydarzenie:

Od dyskusji do działania 🛠️

Kiedy Oliver dodał swój komentarz, aktywność w tym wątku już wzrosła, więc ocena jego indywidualnego wpływu jest trudna. Nie jest jednak przesadą założenie, że dolał oliwy do rosnącego płomienia. Zwłaszcza, że ​​inni użytkownicy (z których przynajmniej jeden jest pracownikiem Patchstacka) otwarcie popierają jego komentarz.

W odpowiedzi główny programista WordPressa, Dion Hulse (@dd32), sprzeciwił się kilku punktom, ale także znacząco się postarał, tworząc eksperymentalną wtyczkę, która implementuje długo oczekiwaną funkcję:

Implementacja jest pięknie prosta – po zamknięciu wtyczki w repozytorium WordPress.org użytkownicy widzą wyraźne, ale wyważone powiadomienie. Żadnych wywołujących panikę czerwonych alertów, tylko proste informacje o statusie wtyczki.

Niech ktoś znajdzie Sergeja i powie mu: „Mamo, udało się!”

Cóż… prawie.

Nie jest to jeszcze część rdzenia WordPressa, ale czuję, że jesteśmy blisko mety!

Teraz, gdy wykazano, że jest to możliwe, kolejnym krokiem jest podjęcie decyzji o ostatecznym wdrożeniu. Następnie można go zintegrować z rdzeniem WordPress.

Co dalej? 🎯

W chwili pisania tego tekstu rozważa się włączenie tej funkcji do WordPress 6.8 (według Dion Hulse), choć nadal pozostaje kilka przeszkód do usunięcia. Należą do nich:

• Finalizowanie terminu powiadamiania (dyskusja na temat ewentualnego wydłużenia 60-dniowego okna).
• Standaryzacja dokumentacji powodu zamknięcia.
• Równoważenie świadomości użytkowników z obciążeniem wsparciem programistów.
• Określenie dokładnej lokalizacji (ekran stanu witryny vs bezpośrednio na wtyczce, jak pokazano na zrzucie ekranu przykładowej wtyczki).

Duży obraz 🌐

Ewolucja biletu WordPress nr 30465 mówi nam coś fascynującego o tym, jak zmieniły się zabezpieczenia WordPress w ciągu ostatniej dekady. To, co kiedyś odrzucano jako przypadek brzegowy, staje się coraz bardziej krytyczne w miarę rozwoju ekosystemu i mnożenia się wyzwań związanych z bezpieczeństwem.

Chociaż zajęło to dziesięć lat, eksperymentalna wtyczka sugeruje, że w końcu zbliżamy się do rozwiązania, które równoważy świadomość bezpieczeństwa z doświadczeniem użytkownika. Ponieważ miliony instalacji WordPressa mogą być dotknięte wrażliwymi wtyczkami, ta funkcja nie będzie dostępna wystarczająco szybko.

Jeśli chcesz śledzić rozwój, sprawdź eksperymentalną wtyczkę na GitHub lub zwróć uwagę na zgłoszenie nr 30465. To może być jeden z tych rzadkich momentów, w których jesteśmy świadkami przekształcenia trwającej dekadę rozmowy w namacalny wynik. 💡

Co sądzisz o tej funkcji? Czy uważasz, że jako użytkownik WordPressa przydatna byłaby informacja o zamknięciu wtyczki? Daj mi znać w komentarzach. Do zobaczenia.