Strona internetowa cena – czy tylko to się liczy podczas jej realizacji?
Dziś ogłoszono nowe wydanie bezpieczeństwa WordPressa. 17 października 2022 roku WordPress Core wydał wersję 6.0.3 a security only release. To wydanie zawiera znaczną liczbę poprawek błędów bezpieczeństwa, więc będę je przeglądać i dzielić się szczegółami z Tobą w tym poście.
Wszystkie wydania bezpieczeństwa są ważne. Możesz chcieć zaplanować aktualizację swoich instalacji WordPress wkrótce, ale dobrą wiadomością jest to, że nie ma żadnych błędów bezpieczeństwa wysokiego lub krytycznego ryzyka łatanych w tym wydaniu. Nie ma potrzeby, aby rzucić wszystko, aby zastosować tę łatę dzisiaj, ale najlepiej byłoby odłożyć trochę czasu w swoim kalendarzu wkrótce.
Najwyższe ryzyko, jakie stwarzają te błędy, to „średnie”. Wiele z załatanych błędów ma „niską” dotkliwość, ponieważ wymagają uwierzytelnienia do przeprowadzenia ataku i mają ograniczony wpływ.
Błędy o najwyższym ryzyku są związane z otwartym przekierowaniem, wyciekiem wartości tagów lub terminów w nieopublikowanych postach lub uwierzytelnionym XSS. Więcej szczegółów na temat każdego z nich napisałem poniżej w sekcji „podział załatanych błędów”.
To wydanie bezpieczeństwa powstało z pomocą 11+ badaczy bezpieczeństwa oraz 28+ wolontariuszy i deweloperów WordPress.org. Teraz do ponad 450+ milionów właścicieli witryn WordPress należy wykonanie swojej części i zastosowanie poprawki.
Łaty zostały przeniesione z powrotem. Każde większe wydanie WordPressa z powrotem do 3.7 otrzymało dzisiaj nową mniejszą wersję, która zawiera łaty do rozwiązania tych błędów bezpieczeństwa. Jest to zadziwiające 9 lat wsparcia dla gałęzi 3.7. Które, właśnie dobiega końca. Za nieco ponad miesiąc, 1 grudnia 2022 roku, wsteczne łatki bezpieczeństwa będą cofać się tylko do wersji 4.1 WordPressa. Jeśli używasz WordPressa 3.7 do 4.0, będziesz musiał zaktualizować swoje witryny do wspierającego wydania Major (4.1 lub wyższego), aby nadal otrzymywać poprawki bezpieczeństwa.
Te dwa błędy bezpieczeństwa wydają się mieć najwyższe ryzyko. Nie wymagają one żadnej autoryzacji i mogą być uzbrojone jako ataki na domyślne konfiguracje WordPressa.
Dobra wiadomość jest taka, że udany atak miałby bardzo ograniczony wpływ. Otwarte przekierowania wymagają oszukania użytkownika, a wartości tagów i terminów postu mogą być nieistotne, jeśli wyciekną przed opublikowaniem.
Otwarte przekierowanie w wp_nonce_ays
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — 4.3 (Medium)
Zabezpiecza przed ryzykiem otwartego przekierowania, które mogłoby pozwolić atakującemu na dostarczenie linku do nazwy domeny witryny WordPress, ale mogłoby przekierować na inny adres URL wybrany przez atakującego. Mogłoby to zostać wykorzystane w tandemie z atakami phishingowymi.
Punkt końcowy REST mógł zwracać terminy lub tagi w niepublicznych postach
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N — 5.3 (Medium)
Zatrzymuje punkty końcowe WordPress REST przed zwracaniem wartości nieopublikowanych terminów lub tagów postów. Mogło to spowodować, że nieuwierzytelnieni użytkownicy otrzymywali wartości warunków lub tagów nieopublikowanego postu, ale nie jego treść.
Błędy związane z wysyłaniem postów pocztą elektroniczną.
Dwa z załatanych błędów bezpieczeństwa są związane z wp-mail.php. Mają one wpływ tylko na witryny WordPress z włączonym i skonfigurowanym ustawieniem „Post via email”. Domyślne instalacje WordPress nie mają skonfigurowanego „Post via email”.
Możesz sprawdzić, czy „Post via email” jest włączony poprzez stronę „Ustawienia > Pisanie” w wp-admin i szukać pod sekcją „Post via email.
Jeśli masz skonfigurowany „Post via email”, wtedy będziesz chciał zaktualizować do wydania bezpieczeństwa 6.0.3 ASAP. Ryzyko związane z tym może obejmować wyciek adresów e-mail i prawdopodobnie umożliwienie autorom umieszczania dowolnego HTML (XSS payloads) w swoich postach opartych na e-mailu.
Stored XSS przez wp-mail.php
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N — 3.7 (Low)
Poprawia bezpieczeństwo funkcji pisania skrzynek pocztowych w WordPressie, aby zapobiec umieszczaniu dowolnego kodu HTML (np. XSS) przez użytkowników o niższych uprawnieniach, którzy normalnie nie mogliby tego robić.
Adres e-mail nadawcy może być ujawniony poprzez wp-mail.php
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N — 3.1 (Low)
Poprawia prywatność i zapobiega wyciekowi danych o adresie e-mail nadawcy, ponieważ adres e-mail autora nie jest już wyświetlany w pliku wp-mail.php, który może być publicznie dostępny dla każdego odwiedzającego, jeśli witryna ma włączoną i skonfigurowaną opcję „Publikuj przez e-mail” w Ustawieniach > Pisanie.
Cross-site scripting (XSS.)
Reflected XSS via SQLi w Media Library
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N — 2.6 (Low)
Ta poprawka bezpieczeństwa rozwiązuje problem, w którym w bibliotece mediów mógł istnieć SQL injection, a odpowiedź mogła zawierać ładunek XSS. Atak wymaga wystarczająco wysokiego poziomu autoryzacji, aby móc pracować z biblioteką mediów w WordPressie.
Stored XSS poprzez Customizer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — 4.3 (Medium)
WordPress poprawił swoją obsługę danych wprowadzanych przez użytkownika, co mogło doprowadzić do XSS przez uwierzytelnionego użytkownika, który ma dostęp do dostosowywania motywu.
Stored XSS w RSS Widget
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — 4.3 (Medium)
Dodaje zabezpieczenia do widgetu RSS, ta poprawka jest prawdopodobnie związana lub wspiera poniższą poprawkę do widgetu RSS Gutenberg.
Stored XSS w edycji komentarzy
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N — 2.6 (niski)
Ta poprawka rozwiązuje problem z zapisanym XSS, gdzie użytkownik zostawiający komentarz mógł zostawić ładunek, który jest łagodny. Jednak jeśli administrator lub użytkownik z niefiltrowanymi uprawnieniami do HTML-a później edytuje komentarz z łagodnym ładunkiem XSS, zostanie on uruchomiony, prowadząc do pełnoprawnego XSS.
Więcej…
CSRF w wp-trackback.php
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — 4.3 (Medium)
Ten błąd rozwiązuje problem związany z CSRF, który wymaga od zalogowanego użytkownika kliknięcia złośliwego linku do wp-trackback.php.
Odwrócenie współdzielonych instancji użytkowników
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N 2.6 (Low)
Odwraca to wcześniejszy commit w WordPress core, który mógł prowadzić do niedokładnych odpowiedzi w funkcjonalności związanej z użytkownikami.
Wieloczęściowe e-maile wyciekają z treści, gdy używany jest HTML/plaintext
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N — 3.7 (Low)
Rozwiązuje problem mało prawdopodobnego scenariusza spowodowanego przez wysyłanie wieloczęściowych wiadomości e-mail, co prowadzi do wycieku treści wiadomości w kolejnych wychodzących wiadomościach.
SQL Injection w WP_Date_Query poprawiona sanityzacja zapytania
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N — 3.7 (Low)
Ochrona przed komponentem (wtyczką lub motywem) wysyłającym niebezpieczne dane do WP_Date_Query.
Błędy bezpieczeństwa specyficzne dla Gutenberga.
Wszystkie poprawki do błędów bezpieczeństwa Gutenberga można podsumować jako ulepszone wzmocnienie bezpieczeństwa edytora. Każdy z nich wymaga uwierzytelnienia jako użytkownik z uprawnieniami do edycji lub dodawania postów w WordPressie (np. Poziom dostępu wystarczająco wysoki, aby korzystać z edytora Gutenberg), te poprawki błędów poprawiły sanityzację danych dla każdego typu bloku dla każdego błędu.
XSS w bloku „Szukaj
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — 4.3 (Medium)
Wymaga konta z dostępem do edycji lub dodawania postów. Zapobiega XSS poprzez blok Search.
XSS w bloku RSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — 4.3 (Medium)
Wymaga konta z dostępem do edycji lub dodawania postów. Zapobiega XSS poprzez blok RSS.
XSS w bloku Feature Image
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — 4.3 (Medium)
Wymaga konta z dostępem do edycji lub dodawania postów. Zapobiega XSS poprzez blok Feature Image.
XSS w bloku Widget
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N — 4.3 (Medium)
Wymaga konta z dostępem do edycji lub dodawania postów. Zapobiega XSS poprzez blok Widget.
Wnioski
Wydanie 6.0.3 Security Release dla WordPressa adresuje dużą liczbę błędów bezpieczeństwa, ale powaga jest tylko tak wysoka, jak łatany błąd z najwyższym ryzykiem. Który, to tylko „Medium”. Ważne jest, aby łatać, ale żaden z tych błędów nie stanowi zagrożenia na poziomie awaryjnym.
Podziękowania należą się zespołowi WordPress.org i badaczom bezpieczeństwa, którzy przyczynili się do ich odkrycia. Załatanie kilkunastu błędów w jednym wydaniu pokazuje nam, jak wiele pracy włożono w zabezpieczenie open-source’owego projektu WordPress.
Właściciele stron powinni załatać je w najbliższym czasie, ale nie muszą się spieszyć. Można poczekać, kiedy czas będzie dogodny, ponieważ prawdopodobnie nie ma nagłych wypadków dla przeciętnego właściciela witryny WordPress. Jest jeden błąd bezpieczeństwa łatane, które mogą być bronią szybko jednak ryzyko, które stanowi jest prawdopodobnie nieistotne, chyba że Twój nieopublikowany post warunki i tagi są (z jakiegoś powodu) bardzo wrażliwe.
Rzeczy niemożliwe załatwiam od ręki, na cuda trzeba poczekać ;))
