Czy wtyczki WordPress są bezpieczne w użyciu?

Na przestrzeni lat badania wykazały, że ponad 20% z 50 najpopularniejszych wtyczek do WordPressa jest podatnych na typowe ataki internetowe. Co więcej, ukierunkowane badanie wtyczek e-commerce wykazało, że 7 na 10 najpopularniejszych wtyczek e-commerce zawiera luki. Niestety, hakerzy zazwyczaj wykorzystują te wrażliwe aplikacje do uzyskiwania dostępu do poufnych informacji, takich jak dane medyczne i dane finansowe. W innych przypadkach luki w zabezpieczeniach umożliwiają hakerom niszczenie witryn lub przekierowywanie ich do innych witryn kontrolowanych przez atakujących.

W nowszych przypadkach widzieliśmy, że złośliwe wtyczki WordPress są wykorzystywane nie tylko do utrzymywania dostępu na zaatakowanych serwerach, ale także do wydobywania kryptowaluty. Nasuwa się więc pytanie, na ile bezpieczne są wtyczki WordPress.

W tym blogu skupimy się na wtyczkach WordPress jako potencjalnych źródłach naruszeń bezpieczeństwa.

Tworzenie stron internetowych w oparciu o wtyczki.

Ogólnie rzecz biorąc, WordPress jest najpopularniejszym systemem zarządzania treścią (CMS) na świecie, ponieważ obsługuje ponad 30% sieci.

To powiedziawszy, główna siła WordPressa polega na jego zdolności do dostosowywania witryn dzięki szerokiej ofercie dziesiątek tysięcy wtyczek i motywów. Wtyczki te różnią się rodzajem i funkcjonalnością – od dodania formularza kontaktowego do witryny po optymalizację bloga pod kątem SEO, a nawet automatyczne publikowanie nowych postów na Facebooku.

Rozwój strony trzeciej.

Główną ideą rozwoju opartego na wtyczkach jest oferowanie dodatkowych funkcji rozszerzających podstawowe możliwości systemu. Zasadniczo rdzeń aplikacji jest zwykle utrzymywany przez zespół długoletnich programistów, podczas gdy strony trzecie tworzą szereg wtyczek wokół rdzenia aplikacji

Proces ten jest korzystny zarówno dla dostawcy aplikacji, jak i dostawcy wtyczek, ponieważ dostawca aplikacji może bardziej skoncentrować się na podstawowej funkcjonalności, podczas gdy dostawca wtyczek nie musi martwić się o infrastrukturę wtyczki, która jest zapewniana przez podstawową funkcjonalność aplikacji. Ogólnie rzecz biorąc, WordPress jest również wspierany przez globalną społeczność tysięcy twórców i entuzjastów oprogramowania komercyjnego i open-source.

Brak wytycznych dotyczących bezpieczeństwa

Ogólnie rzecz biorąc, chociaż istnieje pewien zestaw standardów i zaleceń dotyczących kodowania, technicznie nie ma wytycznych dotyczących bezpieczeństwa ani standardowych wymagań, których twórca wtyczek musi ściśle przestrzegać. Oznacza to, że luka w jednej wtyczce może rozprzestrzeniać się na miliony stron internetowych.

A ponieważ WordPress jest szeroko stosowany, w konsekwencji jest popularnym celem ataków. Zasadniczo haker wykorzystujący lukę w zabezpieczeniach wtyczki może zainfekować tysiące witryn. Scenariusz, którego świadkami było już wielu blogerów.

Niestety, luki związane z wtyczkami również bywają powtarzalne, możliwe do wykorzystania i trudne do wykrycia. Dlatego istnieje potrzeba dalszego zrozumienia takich podatności, aby złagodzić wszelkie istotne zagrożenia bezpieczeństwa. Zagłębmy się głębiej, dobrze?

Czy WordPress jest naprawdę bezpieczny?

Po pierwsze, odpowiedzmy na to pytanie. W większości WordPress jako surowy ekosystem jest bardzo bezpieczny, o ile przestrzegane są najlepsze praktyki bezpieczeństwa WordPress. Średnio około 30 000 nowych stron internetowych jest codziennie hakowanych w sieci. Hakerzy ci mają tendencję do atakowania witryn WordPress z powodu luk w zabezpieczeniach wtyczek, słabych haseł i przestarzałego oprogramowania. Tak więc osiągnięcie najlepszego bezpieczeństwa wymaga pewnego poziomu celowości, co oznacza przestrzeganie kilku podstawowych najlepszych praktyk bezpieczeństwa WordPress, aby zmniejszyć podatność na ataki.

Przeczytaj więcej: 11 skutecznych sposobów na skalowanie witryny WordPress pod kątem dużego ruchu

Skąd pochodzą te luki?

Niedawny raport wpscan.org ujawnił, że WordPress ma prawie 4000 znanych luk w zabezpieczeniach. Zdecydowana większość tych luk została spowodowana przez wtyczki. I chociaż niektóre z tych luk związanych z wtyczkami mogą mieć poważne konsekwencje, wiele z nich pozostaje niezauważonych przez lata, zanim zostaną naprawione. W większości przypadków można je zwykle naprawić za pomocą niewielkich i zlokalizowanych zmian w ich kodzie źródłowym.

Zanim jednak wyprzedzimy siebie, cofnijmy się o krok.

Czym są wtyczki?

Zasadniczo wtyczki to rozszerzenia oprogramowania, które uzupełniają aplikacje o nową, dostosowaną do potrzeb klienta funkcjonalność i zachowanie. W szczególności WordPress oferuje tysiące wtyczek (ponad 52 000), które zostały wykorzystane do budowy tysięcy dostosowanych aplikacji internetowych.

Ponieważ aplikacje internetowe oparte na wtyczkach stały się bardziej powszechne, coraz więcej programistów zwróciło uwagę na odkrywanie ich potencjału do ponownego wyobrażenia aplikacji internetowych poprzez tworzenie, konfigurowanie i rozszerzanie różnych wtyczek o najnowocześniejszą funkcjonalność.

Implikacje rozwoju wtyczek

Biorąc to pod uwagę, możliwość wykorzystywania wtyczek do rozszerzania systemów internetowych o dodatkowe i niestandardowe funkcje ma zarówno pozytywne, jak i negatywne konsekwencje dla programistów. Po pierwsze, z pozytywnej strony, zwykle istnieje wiele opcji dostosowywania do wyboru, dając programistom możliwość szybkiego i łatwego tworzenia aplikacji internetowych, które są dostosowane do potrzeb użytkowników. W ten sposób ułatwiając szybkie prototypowanie i rozwój.

Jednak z drugiej strony aplikacja internetowa może być złożoną kompozycją wielu wtyczek z różnych źródeł. Co ostatecznie rodzi obawy związane z bezpieczeństwem wtyczek. Na przykład TimThumb, wtyczka wykorzystywana przez miliony aplikacji opartych na WordPressie, była podobno otwarta na exploit, dzięki któremu atakujący mogli celowo wykonać zdalny kod.

W rzeczywistości około 15% luk w systemach internetowych można uznać za krytyczne według amerykańskiej bazy danych National Vulnerability Database (NVD), przy czym prawie 35% z nich to luki, które można łatwo wykorzystać.

Jakie są konsekwencje skompromitowanych wtyczek?

Oprócz utraty informacji finansowych przez użytkowników lub nawet narażenia ich dokumentacji medycznej, im poważniejsza luka, tym większy wpływ finansowy na firmy produkujące oprogramowanie. Dodatkowo sytuacja się pogarsza, jeśli programiści nie udostępnią realnej ścieżki w momencie ujawnienia. Dlatego dostawcy wtyczek zazwyczaj dążą do tworzenia bezpieczniejszych aplikacji

Przyjrzyjmy się teraz niektórym lukom bezpieczeństwa, które zwykle występują we wtyczkach, aby lepiej zrozumieć ich konsekwencje i implikacje.

Luki w zabezpieczeniach

Jak już zebraliśmy, luki w zabezpieczeniach otwierają możliwości potencjalnego niewłaściwego wykorzystania systemów oprogramowania. Ostatecznie, ponieważ WordPress umożliwia milionom programistów na całym świecie tworzenie własnych wtyczek, nierealistyczne jest oczekiwanie, że we wtyczkach wystąpi pewien poziom kompromisu.

W rezultacie bezpieczeństwo może zostać naruszone przez nieoczekiwane interakcje wtyczek z systemem podstawowym, co prowadzi do luk, które mogą być potencjalnie wykorzystane przez atakujących. Oznacza to z kolei, że bezpieczeństwo systemów internetowych zależy od kontrolowania zarówno podatności systemu podstawowego, jak i wtyczek.

Złożoność WordPress

Ze względu na złożoność WordPressa czasami nękają go luki w zabezpieczeniach. Na przykład WordPress zapewnia intuicyjną infrastrukturę, do której wtyczki mogą wnosić nowe funkcje, modyfikując współdzielony stan globalny lub uruchamiając funkcję w określonym momencie wykonywania rdzenia systemu. W związku z tym luka w zabezpieczeniach wtyczki może pojawić się, gdy wtyczka wysyła złośliwe dane wejściowe do podstawowych komponentów bez odpowiedniego oczyszczenia lub walidacji danych wejściowych.

Przykłady luk w zabezpieczeniach wtyczek

Ostatecznie najczęstsze luki w zabezpieczeniach wtyczek to cross-site scripting, SQL Injection i Cross-site Request Forgery. Ogólnie rzecz biorąc, najbardziej niebezpiecznym typem luki, który może łatwo wykorzystać atakujący, jest SQL Injection. Istnieją jednak inne podatności, źródła naruszeń i kompromisów, a mianowicie:

• Błędy przetwarzania danych
• Nieprawidłowa weryfikacja danych wejściowych
• Ekspozycja informacji
• Przemierzanie ścieżki
• Funkcjonalność związana z bezpieczeństwem
• Kontrola dostępu
• Niewłaściwa kontrola dostępu
• Niewłaściwa autoryzacja
• Nieprawidłowe uwierzytelnianie
• Fałszerstwo żądań między witrynami
• Nieograniczone przesyłanie plików
• Pliki dostępne dla podmiotów zewnętrznych
• Obserwowanie linku
• Otwórz przekierowanie
• Wstrzykiwanie polecenia
• Wstrzykiwanie poleceń systemu operacyjnego
• Skrypty między witrynami
• Wstrzyknięcie SQL
• Wstrzyknięcie kodu

Aby uzyskać więcej kontekstu, przyjrzyjmy się najczęstszym atakom i lukom w zabezpieczeniach.

• · SQL Injection: SQL injection zwykle ma miejsce, gdy atakujący uzyskuje dostęp do bazy danych WordPress użytkownika i wszystkich danych jego witryny. Wstrzykiwania SQL mogą być również wykorzystywane do wstawiania nowych danych do bazy danych, w tym linków do złośliwych lub spamowych stron internetowych.

Wstrzyknięcia SQL umożliwiają wykonywanie poleceń na serwerze zaplecza, takich jak wyodrębnianie poufnych informacji. W środowisku hostowanym atak SQL Injection może być dalej wykorzystywany jako odskocznia do ataków na witryny, które nie są podatne na ataki.

• · Cross-Site Scripting: Atak ten umożliwia uruchomienie skryptu na kliencie w celu ominięcia kontroli dostępu. Zazwyczaj jest kierowany do wszystkich odwiedzających witrynę. W środowisku hostowanym taki atak może zostać wykorzystany do kradzieży sesyjnych plików cookie administratora witryny, umożliwiając atakującemu udawanie administratora.

• · Cross-Site Request Forgery: Ta luka umożliwia hakerowi wykonanie transakcji na poziomie aplikacji w imieniu ofiary. W środowisku hostowanym osoba atakująca może zalogować się do witryny w imieniu administratora i wykonać złośliwe działania, takie jak przekierowywanie użytkowników lub wykonywanie transakcji administracyjnych.

Często występujące we wtyczkach WordPress luki w zabezpieczeniach cross-site scripting działają w taki sposób – atakujący znajduje sposób, aby ofiara ładowała strony internetowe z niezabezpieczonymi skryptami JavaScript.

Gdzie pojawia się większość luk?

Badanie techniczne wykazało, że większość luk (około 92%) pojawia się w kodzie wtyczki. Co więcej, zgodnie z wynikami, luki takie jak Cross-site Scripting i Cross-site Request Forgery były częstsze w kodzie wtyczki, podczas gdy inne luki były bardziej rozpowszechnione w kodzie podstawowym. W związku z tym badanie wykazało, że jakość wtyczek była zróżnicowana i nie było korelacji między ocenami wtyczek a liczbą znalezionych w nich luk w zabezpieczeniach.

Proces pisania kodu PHP

Proces pisania kodu może być genezą jakiejkolwiek luki lub kompromisu. Ogólnie rzecz biorąc, PHP jest dobrze znane z tego, że wspiera wykonywanie dowolnego kodu po stronie serwera bez bezpośredniego wywoływania systemu operacyjnego hosta. To powiedziawszy, za każdym razem, gdy programiści dokonują zaniedbań podczas procesu pisania kodu, pojawia się możliwość wprowadzenia luk Cross-site Scripting do kodu wtyczki.

Z drugiej strony, w odniesieniu do SQL Injection jest powszechną luką, ponieważ można ją łatwo wykryć i wykorzystać. Jak na ironię, nawet strona internetowa z niewielką bazą użytkowników może zostać poddana próbie ataku SQL Injection.

Część ekspozycji na luki wynika z użycia przez programistów niebezpiecznych zasobów. Podobnie, właściwa walidacja danych wejściowych jest nadal głównym wyzwaniem dla twórców wtyczek, ponieważ wiele z ostatnio opracowanych wtyczek zostało stworzonych przez niezbyt wykwalifikowanych programistów

Czy luki w zabezpieczeniach powodowane przez wtyczki WordPress są krytyczne?

Biorąc wszystko pod uwagę; podatność może negatywnie wpłynąć na system sieciowy na kilka sposobów. Na przykład pomyślne wykorzystanie luki w zabezpieczeniach może prowadzić do całkowitej utraty poufności, jednak bez utraty dostępności.

Jak zauważono, SQL Injection wydaje się być najniebezpieczniejszym typem podatności, chociaż tylko częściowo wpływa na integralność, dostępność i poufność systemu. Jednak taka luka może potencjalnie umożliwić atakującym nieograniczony dostęp do plików lub informacji.

Tak więc, nieumyślnie, większość luk może potencjalnie prowadzić do naruszenia bezpieczeństwa danych, podczas gdy kilka luk niekoniecznie naraża aplikacje internetowe na poważne zagrożenia bezpieczeństwa. Albo ważne jest, aby nie ryzykować przy takich szansach.

Jak długo luka może przetrwać w kodzie wtyczki WordPress?

Zazwyczaj luki w kodzie mają tendencję do przechodzenia przez różne stany, począwszy od wprowadzenia, poprzez ujawnienie, aż do wydania łaty naprawiającej zagrożenie bezpieczeństwa.

Zazwyczaj luka w zabezpieczeniach jest ujawniana, gdy odkrywca ujawnia szczegóły zagrożenia bezpieczeństwa szerszej publiczności. W końcu luka zostaje naprawiona, gdy programista wyda poprawkę, która koryguje podstawowe zagrożenie bezpieczeństwa. Czasami jednak luka pozostaje niezauważona w aplikacji internetowej przez lata, zanim zostanie zidentyfikowana, a następnie naprawiona.

Możliwe środki łagodzące i metody wykrywania

Lepiej zapobiegać niż leczyć, jak mówi większość ludzi. Tak więc, jeśli twórcy wtyczek mogą w pełni zrozumieć, wykryć i wyeliminować Cross-site Scripting, SQL Injection i Cross-site Request Forgery, możliwe, że będziemy mieli wtyczki z 75% mniejszą liczbą luk.

Warto jednak zauważyć, że te trzy luki nie są jedynymi lukami, które mogą zostać wykorzystane przez atakujących. Ale raczej są najczęstsze luki.

Tak więc, chociaż te proponowane strategie łagodzenia skutków nie gwarantują, że dana wtyczka będzie w pełni bezpieczna, ustanawiają jednak dobre zasady zapobiegania podatnościom na ataki. Na przykład:

1. Dowiedz się, w jaki sposób wykorzystywane są dane i jakie kodowanie jest oczekiwane przez główne części WordPressa. W takim przypadku programiści powinni zawsze zakładać, że wszystkie dane wejściowe są złośliwe i odrzucać wszelkie dane wejściowe, które nie są ściśle zgodne z wymaganym wzorcem kodowania, lub przekształcać je w prawidłowe dane wejściowe.
2. Aby chronić bazy danych przed wstrzyknięciem SQL, programiści powinni używać sparametryzowanych instrukcji SQL, oddzielając kod od manipulacji danymi. Ponadto zawsze sprawdzaj nagłówki, aby zweryfikować, czy żądanie pochodzi z tego samego źródła. Ponadto przydatne może być również unikanie ujawniania danych nieuwierzytelnionym napastnikom.
3. Dobrą praktyką jest unikanie metody GET dla każdego żądania, które wyzwala zmianę stanu.

Wykrywanie luk

Niestety nie ma spójnej metody wykrywania najczęstszych słabości kodu ze 100% dokładnością i pokryciem. Niestety, nawet nowoczesne techniki, które wykorzystują analizę przepływu danych do wykrywania Cross-site Scripting, czasami dają fałszywe alarmy.

W przeciwieństwie do tego, ręczne metody analizy, takie jak przeglądy kodu, wydają się być bardziej skuteczne niż metody w pełni zautomatyzowane, szczególnie w przypadku luk związanych z projektowaniem. Na przykład fałszowanie żądań między witrynami jest szczególnie trudne do wykrycia przy użyciu zautomatyzowanych metod, ponieważ każda aplikacja ma własną politykę bezpieczeństwa i sposób wskazywania, które żądania wymagają silnej pewności, że użytkownik zamierza wykonać żądanie.

Jednak z drugiej strony analiza ręczna może być przydatna do znalezienia wstrzyknięcia SQL, chociaż może nie osiągnąć pożądanego pokrycia kodu w ograniczonych ramach czasowych. Może to być trudne w przypadku słabych punktów, które należy wziąć pod uwagę dla wszystkich danych wejściowych, ponieważ powierzchnia ataku może być zbyt duża.

W związku z tym niektóre organizacje podkreślają znaczenie zrównoważonego podejścia, które obejmuje zarówno ręczne przeglądy, jak i automatyczną analizę, która obejmuje wszystkie fazy procesu tworzenia systemu internetowego.

Najlepsze praktyki ochrony aplikacji WordPress

• Pobieraj wtyczki tylko z renomowanych źródeł, takich jak WordPress.org: ponieważ każdy może stworzyć wtyczkę do WordPressa, hakerzy notorycznie wykorzystują tę lukę, aby ukryć własne złośliwe wtyczki. Renomowany rynek może nie gwarantować w pełni dostępu do nieszkodliwych wtyczek, ale jest zalecany jako praktyka łagodząca.
• Zawsze upewnij się, że wszystkie wtyczki są aktualne: użytkownicy WordPressa zazwyczaj otrzymują powiadomienia e-mail, które często ignorują. Pamiętaj, aby ustawić automatyczne aktualizacje wtyczek lub przynajmniej ręcznie je zaktualizować.
• Sprawdź stan bezpieczeństwa wtyczki, skanując ją pod kątem problemów z bezpieczeństwem: Większość wtyczek jest typu open source, co oznacza, że ​​dostępny jest ich kod źródłowy. Dlatego upewnij się, że korzystasz ze statycznego narzędzia do analizy kodu źródłowego, które zapewni Ci „rachunek zdrowia” wtyczki. Niektóre zaawansowane skanery mogą nawet wskazać Ci optymalne i najszybsze zalecenia dotyczące naprawy.
• Usuń wszystkie nieużywane wtyczki: Niestety kod starych, nieużywanych wtyczek zazwyczaj pozostaje na serwerze – nawet jeśli wtyczki są nieaktywne. Dlatego pamiętaj, aby zawsze usuwać nieużywane wtyczki w ramach konserwacji witryny WordPress

Zalecenia dla programistów wtyczek

• Zawsze uwzględniaj zabezpieczenia podczas opracowywania wtyczek: luki w zabezpieczeniach wiążą się z wyższymi kosztami, aby naprawić je później, dlatego zawsze integruj zabezpieczenia z opracowywaniem wtyczek w ramach bezpiecznego procesu cyklu życia oprogramowania (SDLC).
• Uruchom wtyczkę przez skaner kodu, aby upewnić się, że spełnia najnowsze standardy bezpieczeństwa. Upewnij się, że przeprowadzasz kompleksowy test analizy kodu źródłowego podczas tworzenia i przed wydaniem.

Tworzenie bezpiecznych wtyczek

Jak już wspomniano, twórcy wtyczek muszą dążyć do pisania bezpiecznego kodu. Niestety, wielu programistów wciąż nie wie, jak to zrobić, ponieważ nie mają zbyt wielu umiejętności. W szczególności, biorąc pod uwagę charakter najczęściej cytowanych powyżej luk w zabezpieczeniach, jasne jest, że wielu programistów nie rozumie typowych ataków, funkcji bezpieczeństwa zapewnianych przez język i platformę, z której korzystają, oraz sposobów stosowania odpowiednich praktyk w celu złagodzenia problemów związanych z bezpieczeństwem.

Dlatego nasza rekomendacja w Creole Studios jest taka, że ​​być może należy opracować nowe metodologie dostosowane do twórców wtyczek. Takie metodologie powinny promować bezpieczeństwo w fazach wymagań i projektowania, ponieważ programiści są najważniejszymi podmiotami w bezpieczeństwie oprogramowania.

Końcowe przemyślenia

Podsumowując temat, wtyczki WordPress mogą być zagrożone, a najczęstsze luki to Cross-site Scripting, SQL Injection i Cross-site Request Forgery.

Niestety, badania wydają się sugerować, że częstotliwość występowania tych podatności nie wydaje się spadać z czasem. Można śmiało założyć, że głównym powodem tego jest to, że większość twórców wtyczek do WordPressa nie ma wystarczających umiejętności w zakresie bezpiecznego programowania.

Biorąc to pod uwagę, pierwszą linią obrony powinien być zespół programistów! Wierzymy, że po wdrożeniu najlepszych praktyk w zakresie bezpieczeństwa użytkownicy mogą lepiej spać w nocy, wiedząc, że są chronieni przed cyberprzestępcami.

Aby uzyskać więcej informacji na temat naszych praktyk bezpieczeństwa WordPress, uprzejmie prosimy o konsultację.