Bezpieczeństwo

Dowiedz się więcej o bezpieczeństwie podstawowego oprogramowania WordPress w tej bezpłatnej białej księdze. Możesz go również pobrać w formacie PDF.

Przegląd

Niniejszy dokument jest analizą i wyjaśnieniem rozwoju podstawowego oprogramowania WordPress i związanych z nim procesów bezpieczeństwa, a także badaniem nieodłącznych zabezpieczeń wbudowanych bezpośrednio w oprogramowanie. Decydenci oceniający WordPress jako system zarządzania treścią lub framework aplikacji internetowych powinni wykorzystać ten dokument w swojej analizie i podejmowaniu decyzji, a programiści powinni się do niego odnieść, aby zapoznać się z komponentami bezpieczeństwa i najlepszymi praktykami oprogramowania.

Informacje zawarte w tym dokumencie są aktualne dla najnowszej stabilnej wersji oprogramowania, WordPress 4.7 w momencie publikacji, ale powinny być uważane za istotne również dla najnowszych wersji oprogramowania, ponieważ kompatybilność wsteczna jest silnym celem zespołu programistów WordPress. Szczególne środki bezpieczeństwa i zmiany zostaną odnotowane, ponieważ zostały dodane do podstawowego oprogramowania w określonych wersjach. Zdecydowanie zaleca się, aby zawsze korzystać z najnowszej stabilnej wersji WordPressa, aby zapewnić możliwie najbezpieczniejsze korzystanie z niego.

Streszczenie

WordPress to dynamiczny system zarządzania treścią o otwartym kodzie źródłowym, który jest używany do zasilania milionów stron internetowych, aplikacji internetowych i blogów. Obecnie obsługuje ponad 43% z 10 milionów najpopularniejszych witryn w Internecie. Użyteczność, rozszerzalność i dojrzała społeczność programistów sprawiają, że WordPress jest popularnym i bezpiecznym wyborem dla stron internetowych każdej wielkości.

Od momentu powstania w 2003 r. WordPress był stale ulepszany, aby jego podstawowe oprogramowanie mogło reagować i łagodzić typowe zagrożenia bezpieczeństwa, w tym listę Top 10 zidentyfikowaną przez The Open Web Application Security Project (OWASP) jako typowe luki w zabezpieczeniach, które zostały omówione w tym dokumencie.

Zespół ds. bezpieczeństwa WordPress, we współpracy z zespołem WordPress Core Leadership Team i wspierany przez globalną społeczność WordPress, pracuje nad identyfikacją i rozwiązywaniem problemów związanych z bezpieczeństwem w podstawowym oprogramowaniu dostępnym do dystrybucji i instalacji na WordPress.org, a także zalecaniem i dokumentowaniem najlepszych praktyk bezpieczeństwa dla zewnętrznych autorów wtyczek i motywów.

Deweloperzy i administratorzy witryn powinni zwrócić szczególną uwagę na prawidłowe korzystanie z podstawowych interfejsów API i podstawowej konfiguracji serwera, które były źródłem powszechnych luk w zabezpieczeniach, a także upewnić się, że wszyscy użytkownicy używają silnych haseł dostępu do WordPressa.

Przegląd WordPress

WordPress to darmowy i otwarty system zarządzania treścią (CMS). Jest to najczęściej używane oprogramowanie CMS na świecie i obsługuje ponad 43% z 10 milionów najlepszych stron internetowych1, co daje mu szacunkowy 62% udział w rynku wszystkich witryn korzystających z CMS.

WordPress jest licencjonowany na podstawie Powszechnej Licencji Publicznej (GPLv2 lub nowszej), która zapewnia cztery podstawowe wolności i może być uważana za &#8220 "bill of rights&#8221 WordPressa:

  1. Swoboda uruchamiania programu w dowolnym celu.
  2. Swoboda studiowania sposobu działania programu i zmieniania go tak, aby robił to, co chcesz.
  3. Wolność do redystrybucji.
  4. Wolność rozpowszechniania kopii twoich zmodyfikowanych wersji innym.

Główny zespół kierowniczy WordPress

Projekt WordPress jest merytokracją, prowadzoną przez główny zespół kierowniczy i kierowaną przez współtwórcę i głównego programistę, Matta Mullenwega. Zespół zarządza wszystkimi aspektami projektu, w tym rozwojem rdzenia, WordPress.org i inicjatywami społeczności.

Core Leadership Team składa się z Matta Mullenwega, pięciu głównych deweloperów i kilkunastu głównych deweloperów ze stałym dostępem do commitów. Deweloperzy ci mają ostateczną władzę nad decyzjami technicznymi i prowadzą dyskusje na temat architektury i wysiłków wdrożeniowych.

WordPress ma wielu współpracujących programistów. Niektórzy z nich to byli lub obecni committerzy, a niektórzy to prawdopodobnie przyszli committerzy. Ci współpracujący deweloperzy są zaufanymi i doświadczonymi współpracownikami WordPressa, którzy zdobyli duży szacunek wśród swoich rówieśników. W razie potrzeby WordPress ma również gościnnych committerów, osoby, którym przyznano dostęp do commitów, czasami dla określonego komponentu, na zasadzie tymczasowej lub próbnej.

Rdzeń i współpracujący programiści przede wszystkim kierują rozwojem WordPress. W każdej wersji setki programistów współtworzą kod WordPress. Ci główni współpracownicy to wolontariusze, którzy w jakiś sposób przyczyniają się do rozwoju głównej bazy kodu.

Cykl wydawniczy WordPressa

Każdy cykl wydawniczy WordPress jest prowadzony przez jednego lub więcej głównych programistów WordPress. Cykl wydawniczy trwa zwykle około 4 miesięcy od początkowego spotkania dotyczącego zakresu do uruchomienia wersji.

Cykl wydawniczy przebiega według następującego schematu2:

  • Faza 1: Planowanie i pozyskiwanie liderów zespołów. Odbywa się to na czacie #core na Slacku. Lider wydania omawia funkcje dla następnej wersji WordPress. Współtwórcy WordPressa angażują się w tę dyskusję. Lider wydania zidentyfikuje liderów zespołów dla każdej z funkcji.
  • Faza 2: Rozpoczynają się prace rozwojowe. Liderzy zespołów zbierają zespoły i pracują nad przypisanymi im funkcjami. Zaplanowane są regularne czaty, aby zapewnić dalszy rozwój.
  • Faza 3: Beta. Wersje beta są wydawane, a beta-testerzy są proszeni o zgłaszanie błędów. Od tej fazy nie są już zatwierdzane żadne nowe ulepszenia ani prośby o funkcje. Zewnętrzni autorzy wtyczek i motywów są zachęcani do testowania swojego kodu pod kątem nadchodzących zmian.
  • Faza 4: Kandydat do wydania. Od tego momentu następuje zamrożenie ciągów znaków do tłumaczenia. Prace są ukierunkowane wyłącznie na regresje i blokady.
  • Faza 5: Uruchomienie. Wersja WordPress zostaje uruchomiona i udostępniona w panelu administracyjnym WordPress do aktualizacji.

Numerowanie wersji i wydania poprawiające bezpieczeństwo

Główna wersja WordPressa jest dyktowana przez dwie pierwsze sekwencje. Na przykład 3.5 jest głównym wydaniem, podobnie jak 3.6, 3.7 lub 4.0. Nie ma “WordPress 3&#8221 lub “WordPress 4&#8221, a każde główne wydanie jest określane przez jego numerację, np. “WordPress 3.9.”

Główne wersje mogą dodawać nowe funkcje użytkownika i interfejsy API dla programistów. Chociaż zazwyczaj w świecie oprogramowania wersja “major&#8221 oznacza, że możesz złamać kompatybilność wsteczną, WordPress stara się nigdy nie łamać kompatybilności wstecznej. Kompatybilność wsteczna jest jedną z najważniejszych filozofii projektu, której celem jest ułatwienie aktualizacji zarówno użytkownikom, jak i programistom.

Mniejsza wersja WordPressa jest podyktowana trzecią sekwencją. Wersja 3.5.1 jest wydaniem minor, podobnie jak 3.4.23. Minor release jest zarezerwowany wyłącznie do naprawiania luk w zabezpieczeniach i usuwania krytycznych błędów. Ponieważ nowe wersje WordPressa są wydawane tak często — celem jest co 4-5 miesięcy w przypadku głównego wydania, a pomniejsze wydania pojawiają się w razie potrzeby — istnieje tylko potrzeba głównych i pomniejszych wydań.

Wsteczna kompatybilność wersji

Projekt WordPress jest silnie zaangażowany w kompatybilność wsteczną. To zobowiązanie oznacza, że motywy, wtyczki i niestandardowy kod nadal działają po aktualizacji podstawowego oprogramowania WordPress, zachęcając właścicieli witryn do aktualizowania wersji WordPress do najnowszej bezpiecznej wersji.

WordPress i bezpieczeństwo

Zespół bezpieczeństwa WordPressa

Zespół ds. bezpieczeństwa WordPress składa się z około 50 ekspertów, w tym głównych programistów i badaczy bezpieczeństwa — około połowa z nich to pracownicy Automattic (twórcy WordPress.com, najwcześniejszej i największej platformy hostingowej WordPress w sieci), a wielu pracuje w dziedzinie bezpieczeństwa sieci. Zespół konsultuje się ze znanymi i zaufanymi badaczami bezpieczeństwa i firmami hostingowymi 3.

Zespół ds. bezpieczeństwa WordPress często współpracuje z innymi zespołami ds. bezpieczeństwa w celu rozwiązania problemów we wspólnych zależnościach, takich jak usunięcie luki w parserze PHP XML, używanym przez interfejs API XML-RPC dostarczany z WordPress, w WordPress 3.9.24. Usunięcie tej luki było wynikiem wspólnych wysiłków zespołów ds. bezpieczeństwa WordPress i Drupal.

Zagrożenia dla bezpieczeństwa WordPress, proces i historia

Zespół ds. bezpieczeństwa WordPress wierzy w odpowiedzialne ujawnianie informacji poprzez natychmiastowe powiadamianie zespołu ds. bezpieczeństwa o wszelkich potencjalnych lukach w zabezpieczeniach. Potencjalne luki w zabezpieczeniach mogą być sygnalizowane zespołowi ds. bezpieczeństwa za pośrednictwem WordPress HackerOne5. Zespół ds. bezpieczeństwa komunikuje się między sobą za pośrednictwem prywatnego kanału Slack i pracuje na zamkniętym, prywatnym Trac w celu śledzenia, testowania i naprawiania błędów i problemów związanych z bezpieczeństwem.

Każdy raport bezpieczeństwa jest potwierdzany po jego otrzymaniu, a zespół pracuje nad weryfikacją luki i określeniem jej wagi. Jeśli zostanie to potwierdzone, zespół ds. bezpieczeństwa planuje następnie łatkę naprawiającą problem, która może zostać dodana do nadchodzącej wersji oprogramowania WordPress lub może zostać wydana jako natychmiastowa wersja bezpieczeństwa, w zależności od powagi problemu.

W przypadku natychmiastowego wydania zabezpieczeń zespół ds. bezpieczeństwa publikuje na stronie WordPress.org News6 poradnik ogłaszający wydanie i szczegółowo opisujący zmiany. Uznanie za odpowiedzialne ujawnienie luki jest podane w poradniku, aby zachęcić i wzmocnić dalsze odpowiedzialne zgłaszanie w przyszłości.

Administratorzy oprogramowania WordPress widzą powiadomienie na pulpicie nawigacyjnym witryny, aby dokonać aktualizacji, gdy dostępna jest nowa wersja, a po ręcznej aktualizacji użytkownicy są przekierowywani do ekranu O WordPressie, który zawiera szczegółowe informacje o zmianach. Jeśli administratorzy mają włączone automatyczne aktualizacje w tle, otrzymają wiadomość e-mail po zakończeniu aktualizacji.

Automatyczne aktualizacje w tle dla wydań zabezpieczeń

Począwszy od wersji 3.7, WordPress wprowadził automatyczne aktualizacje w tle dla wszystkich mniejszych wydań7, takich jak 3.7.1 i 3.7.2. Zespół ds. bezpieczeństwa WordPress może zidentyfikować, naprawić i wypchnąć automatyczne ulepszenia zabezpieczeń dla WordPress bez konieczności wykonywania jakichkolwiek czynności przez właściciela witryny, a aktualizacja zabezpieczeń zostanie zainstalowana automatycznie.

Gdy aktualizacja zabezpieczeń jest wypychana dla bieżącej stabilnej wersji WordPressa, główny zespół będzie również wypychał aktualizacje zabezpieczeń dla wszystkich wydań, które są zdolne do aktualizacji w tle (od WordPress 3.7), więc te starsze, ale wciąż najnowsze wersje WordPressa otrzymają ulepszenia bezpieczeństwa.

Poszczególni właściciele witryn mogą zdecydować się na usunięcie automatycznych aktualizacji w tle poprzez prostą zmianę w pliku konfiguracyjnym, ale zachowanie tej funkcji jest zdecydowanie zalecane przez główny zespół, a także uruchomienie najnowszej stabilnej wersji WordPress.

2013 OWASP Top 10

Open Web Application Security Project (OWASP) to społeczność internetowa poświęcona bezpieczeństwu aplikacji internetowych. Lista OWASP Top 10 koncentruje się na identyfikacji najpoważniejszych zagrożeń bezpieczeństwa aplikacji dla szerokiego zakresu organizacji. Pozycje Top 108 są wybierane i priorytetyzowane w połączeniu z konsensusowymi szacunkami możliwości wykorzystania, wykrywalności i szacunkami wpływu.

W poniższych sekcjach omówiono interfejsy API, zasoby i zasady, których WordPress używa do wzmocnienia podstawowego oprogramowania oraz wtyczek i motywów innych firm przed tymi potencjalnymi zagrożeniami.

A1 - Wstrzyknięcie

W WordPressie dostępny jest zestaw funkcji i interfejsów API, które pomagają programistom upewnić się, że nieautoryzowany kod nie może zostać wstrzyknięty, a także pomagają im w walidacji i oczyszczaniu danych. Dostępne są najlepsze praktyki i dokumentacja dotycząca korzystania z tych interfejsów API9 w celu ochrony, sprawdzania poprawności lub oczyszczania danych wejściowych i wyjściowych w HTML, adresach URL, nagłówkach HTTP oraz podczas interakcji z bazą danych i systemem plików. Administratorzy mogą również dodatkowo ograniczyć typy plików, które mogą być przesyłane za pomocą filtrów.

A2 - Uszkodzone uwierzytelnianie i zarządzanie sesjami

Podstawowe oprogramowanie WordPress zarządza kontami użytkowników i uwierzytelnianiem, a szczegóły takie jak identyfikator użytkownika, nazwa i hasło są zarządzane po stronie serwera, podobnie jak uwierzytelniające pliki cookie. Hasła są chronione w bazie danych przy użyciu standardowych technik solenia i rozciągania. Istniejące sesje są niszczone po wylogowaniu w przypadku wersji WordPress po 4.0.

A3 - Cross Site Scripting (XSS)

WordPress zapewnia szereg funkcji, które mogą pomóc w zapewnieniu bezpieczeństwa danych dostarczanych przez użytkowników10. Zaufani użytkownicy, czyli administratorzy i redaktorzy w pojedynczej instalacji WordPress oraz administratorzy sieci tylko w WordPress Multisite, mogą publikować niefiltrowany kod HTML lub JavaScript, gdy tego potrzebują, na przykład wewnątrz postu lub strony. Niezaufani użytkownicy i treści przesłane przez użytkowników są domyślnie filtrowane w celu usunięcia niebezpiecznych jednostek przy użyciu biblioteki KSES za pomocą funkcji wp_kses.

Na przykład, główny zespół WordPress zauważył przed wydaniem WordPress 2.3, że funkcja the_search_query() była nadużywana przez większość autorów motywów, którzy nie uciekali z wyjścia funkcji do użycia w HTML. W bardzo rzadkim przypadku nieznacznego złamania kompatybilności wstecznej, dane wyjściowe funkcji zostały zmienione w WordPress 2.3 na wstępnie uciekające.

A4 - Niezabezpieczone bezpośrednie odniesienie do obiektu

WordPress często udostępnia bezpośrednie odniesienia do obiektów, takie jak unikalne numeryczne identyfikatory kont użytkowników lub treści dostępne w adresach URL lub polach formularzy. Podczas gdy te identyfikatory ujawniają bezpośrednie informacje o systemie, bogate uprawnienia i system kontroli dostępu WordPress zapobiegają nieautoryzowanym żądaniom.

A5 - Błędna konfiguracja zabezpieczeń

Większość operacji konfiguracji zabezpieczeń WordPress jest ograniczona do jednego autoryzowanego administratora. Domyślne ustawienia WordPressa są stale oceniane na poziomie zespołu rdzenia, a zespół rdzenia WordPressa zapewnia dokumentację i najlepsze praktyki w celu zaostrzenia bezpieczeństwa konfiguracji serwera do uruchamiania witryny WordPress11.

A6 - Narażenie danych wrażliwych

Hasła do kont użytkowników WordPress są solone i hashowane w oparciu o Portable PHP Password Hashing Framework12. System uprawnień WordPress służy do kontrolowania dostępu do prywatnych informacji, takich jak dane osobowe zarejestrowanych użytkowników, adresy e-mail komentatorów, prywatnie publikowane treści itp. W WordPress 3.7 miernik siły hasła został włączony do podstawowego oprogramowania, zapewniając dodatkowe informacje użytkownikom ustawiającym swoje hasła i wskazówki dotyczące zwiększania siły. WordPress ma również opcjonalne ustawienie konfiguracji wymagające HTTPS.

A7 - Brak kontroli dostępu na poziomie funkcji

WordPress sprawdza poprawność autoryzacji i uprawnień dla wszelkich żądań dostępu na poziomie funkcji przed wykonaniem akcji. Dostęp lub wizualizacja administracyjnych adresów URL, menu i stron bez odpowiedniego uwierzytelnienia jest ściśle zintegrowana z systemem uwierzytelniania, aby uniemożliwić dostęp nieautoryzowanym użytkownikom.

A8 - Cross Site Request Forgery (CSRF)

WordPress używa tokenów kryptograficznych, zwanych nonces13, do weryfikacji intencji żądań akcji od autoryzowanych użytkowników w celu ochrony przed potencjalnymi zagrożeniami CSRF. WordPress zapewnia interfejs API do generowania tych tokenów w celu tworzenia i weryfikowania unikalnych i tymczasowych tokenów, a token jest ograniczony do określonego użytkownika, określonej akcji, określonego obiektu i określonego okresu czasu, który można dodać do formularzy i adresów URL w razie potrzeby. Dodatkowo, wszystkie nonces są unieważniane po wylogowaniu.

A9 - Korzystanie z komponentów ze znanymi lukami w zabezpieczeniach

Główny zespół WordPress ściśle monitoruje kilka dołączonych bibliotek i frameworków, z którymi WordPress integruje się w celu zapewnienia podstawowej funkcjonalności. W przeszłości główny zespół wniósł wkład w kilka komponentów stron trzecich, aby uczynić je bardziej bezpiecznymi, takimi jak aktualizacja naprawiająca lukę cross-site w TinyMCE w WordPress 3.5.214.

W razie potrzeby, główny zespół może podjąć decyzję o rozwidleniu lub zastąpieniu krytycznych komponentów zewnętrznych, tak jak wtedy, gdy biblioteka SWFUpload została oficjalnie zastąpiona przez bibliotekę Plupload w wersji 3.5.2, a bezpieczny fork SWFUpload został udostępniony przez zespół bezpieczeństwa<15 dla tych wtyczek, które nadal korzystały z SWFUpload w krótkim okresie.

A10 - Niezatwierdzone przekierowania i przekazywanie dalej

Wewnętrzny system kontroli dostępu i uwierzytelniania WordPress chroni przed próbami kierowania użytkowników do niechcianych miejsc docelowych lub automatycznych przekierowań. Ta funkcjonalność jest również dostępna dla twórców wtyczek za pośrednictwem interfejsu API, wp_safe_redirect()16.

Dalsze zagrożenia i obawy związane z bezpieczeństwem

Ataki związane z przetwarzaniem XXE (XML eXternal Entity)

Podczas przetwarzania XML WordPress wyłącza ładowanie niestandardowych encji XML, aby zapobiec zarówno atakom External Entity, jak i Entity Expansion. Poza podstawową funkcjonalnością PHP, WordPress nie zapewnia dodatkowego bezpiecznego API przetwarzania XML dla autorów wtyczek.

Ataki SSRF (Server Side Request Forgery)

Żądania HTTP wysyłane przez WordPress są filtrowane, aby uniemożliwić dostęp do pętli zwrotnej i prywatnych adresów IP. Ponadto dostęp jest dozwolony tylko do niektórych standardowych portów HTTP.

Bezpieczeństwo wtyczek i motywów WordPress

Domyślny motyw

WordPress wymaga włączenia motywu do renderowania treści widocznych na frontendzie. Domyślny motyw, który jest dostarczany z rdzeniem WordPressa (obecnie "Twenty Twenty-Four"), został dokładnie sprawdzony i przetestowany pod kątem bezpieczeństwa zarówno przez zespół programistów motywów, jak i zespół programistów rdzenia.

Domyślny motyw może służyć jako punkt wyjścia do tworzenia niestandardowych motywów, a twórcy witryn mogą tworzyć motywy potomne, które zawierają pewne dostosowania, ale opierają się na domyślnym motywie dla większości funkcji i bezpieczeństwa. Domyślny motyw może być łatwo usunięty przez administratora, jeśli nie jest potrzebny.

Repozytoria motywów i wtyczek WordPress.org

Na stronie WordPress.org znajduje się około 50 000+ wtyczek i 5 000+ motywów. Te motywy i wtyczki są zgłaszane do włączenia i są ręcznie sprawdzane przez wolontariuszy przed udostępnieniem ich w repozytorium.

Włączenie wtyczek i motywów do repozytorium nie gwarantuje, że są one wolne od luk w zabezpieczeniach. Autorzy wtyczek mogą zapoznać się z wytycznymi przed przesłaniem ich do repozytorium17, a obszerna dokumentacja dotycząca tworzenia motywów WordPress18 jest dostępna na stronie WordPress.org.

Każda wtyczka i motyw może być stale rozwijana przez właściciela wtyczki lub motywu, a wszelkie późniejsze poprawki lub rozwój funkcji mogą być przesyłane do repozytorium i udostępniane użytkownikom z zainstalowaną wtyczką lub motywem wraz z opisem tej zmiany. Administratorzy witryny są powiadamiani o wtyczkach, które wymagają aktualizacji za pośrednictwem panelu administracyjnego.

Gdy zespół ds. bezpieczeństwa WordPress odkryje lukę w zabezpieczeniach wtyczki, kontaktuje się z autorem wtyczki i wspólnie pracuje nad naprawieniem i wydaniem bezpiecznej wersji wtyczki. W przypadku braku odpowiedzi ze strony autora wtyczki lub gdy luka jest poważna, wtyczka/temat jest usuwana z katalogu publicznego, a w niektórych przypadkach naprawiana i aktualizowana bezpośrednio przez zespół ds. bezpieczeństwa.

Zespół oceniający motywy

Zespół ds. przeglądu motywów to grupa wolontariuszy, kierowana przez kluczowych i uznanych członków społeczności WordPress, którzy przeglądają i zatwierdzają motywy przesłane do włączenia do oficjalnego katalogu motywów WordPress. Theme Review Team utrzymuje oficjalne Theme Review Guidelines19, Theme Unit Test Datas20 i Theme Check Plugins21, a także stara się angażować i edukować społeczność twórców motywów WordPress w zakresie najlepszych praktyk programistycznych. Włączenie do grupy jest moderowane przez głównych commitów zespołu programistów WordPress.

Rola dostawcy hostingu w bezpieczeństwie WordPressa

WordPress może być zainstalowany na wielu platformach. Chociaż podstawowe oprogramowanie WordPress zapewnia wiele przepisów dotyczących obsługi bezpiecznej aplikacji internetowej, które zostały omówione w tym dokumencie, konfiguracja systemu operacyjnego i podstawowego serwera internetowego hostującego oprogramowanie jest równie ważna dla zapewnienia bezpieczeństwa aplikacji WordPress.

Notka o WordPress.com i bezpieczeństwie WordPressa

WordPress.com to największa instalacja WordPress na świecie, która jest własnością i jest zarządzana przez Automattic, Inc. założoną przez Matta Mullenwega, współtwórcę projektu WordPress. WordPress.com działa w oparciu o podstawowe oprogramowanie WordPress i ma własne procesy bezpieczeństwa, zagrożenia i rozwiązania 22. Niniejszy dokument odnosi się do bezpieczeństwa związanego z samodzielnie hostowanym, dostępnym do pobrania oprogramowaniem WordPress o otwartym kodzie źródłowym, dostępnym na stronie WordPress.org i możliwym do zainstalowania na dowolnym serwerze na świecie.

Apendix

Podstawowe interfejsy API WordPress

Interfejs programowania aplikacji (API23) WordPress Core składa się z kilku indywidualnych interfejsów API, z których każdy obejmuje funkcje związane z danym zestawem funkcji i ich wykorzystaniem. Razem tworzą one interfejs projektu, który umożliwia wtyczkom i motywom bezpieczną i bezpieczną interakcję z podstawową funkcjonalnością WordPress, jej zmianę i rozszerzenie.

Podczas gdy każdy interfejs API WordPress zapewnia najlepsze praktyki i znormalizowane sposoby interakcji i rozszerzania podstawowego oprogramowania WordPress, następujące interfejsy API WordPress są najbardziej istotne dla egzekwowania i wzmacniania bezpieczeństwa WordPress:

API bazy danych

Database API24, dodane w WordPress 0.71, zapewnia poprawną metodę dostępu do danych jako nazwanych wartości, które są przechowywane w warstwie bazy danych.

API Systemu plików

Interfejs API systemu plików25, dodany w WordPress 2.626, został pierwotnie stworzony dla funkcji automatycznych aktualizacji WordPress&#8217. Interfejs API systemu plików abstrahuje od funkcji potrzebnych do bezpiecznego odczytu i zapisu plików lokalnych w systemie plików na różnych typach hostów.

Odbywa się to za pomocą klasy WP_Filesystem_Base i kilku podklas, które implementują różne sposoby łączenia się z lokalnym systemem plików, w zależności od obsługi poszczególnych hostów. Każdy motyw lub wtyczka, która musi zapisywać pliki lokalnie, powinna to robić za pomocą rodziny klas WP_Filesystem.

HTTP API

HTTP API27, dodane w WordPress 2.728 i rozszerzone dalej w WordPress 2.8, standaryzuje żądania HTTP dla WordPress. API obsługuje pliki cookie, kodowanie i dekodowanie gzip, dekodowanie fragmentów (jeśli HTTP 1.1) i różne inne implementacje protokołu HTTP. API standaryzuje żądania, testuje każdą metodę przed wysłaniem i, w oparciu o konfigurację twojego serwera, używa odpowiedniej metody do wykonania żądania.

Pozwolenia i obecny użytkownik API

Uprawnienia i API29 bieżącego użytkownika to zestaw funkcji, które pomogą zweryfikować uprawnienia i upoważnienie bieżącego użytkownika do wykonywania dowolnego zadania lub żądanej operacji i mogą dodatkowo chronić przed nieautoryzowanymi użytkownikami uzyskującymi dostęp lub wykonującymi funkcje wykraczające poza ich dozwolone możliwości.

Licencja na zawartość białej księgi

Tekst w tym dokumencie (z wyłączeniem logo WordPress lub znaku towarowego) jest udostępniany na licencji CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Możesz kopiować, modyfikować, rozpowszechniać i wykonywać utwór, nawet w celach komercyjnych, bez pytania o zgodę.

Specjalne podziękowania dla Drupal’s security white paper, który dostarczył trochę inspiracji.

Dodatkowa lektura


Autorstwo Sara Rosso

Wkład od Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Wersja 1.0 March 2015


Przypisy