Wprowadzenie do XML-RPC. Konkursy programistyczne Co widać w logach serwera
Jego post pokazuje również, jak przeprowadzić uwierzytelnianie przeglądarki, jak poniżej:
$request = xmlrpc_encode_request („nazwa metody” , tablica („pararam metody” ));
$auth = base64_encode ($nazwa użytkownika ":" . $hasło);
$nagłówek = (wersja_porównania(phpversion(), "5.2.8"))
? array("Typ zawartości: tekst/xml" , "Autoryzacja: podstawowa $auth ")
: „Typ zawartości: tekst/xml\r\nAutoryzacja: podstawowa$autoryzacja" ; //
$context = stream_context_create (tablica("http" => tablica(
"metoda" => "POST" ,
"nagłówek" => $nagłówek ,
"treść" => $żądanie
)));
$usługa internetowa = „http://www.example.com/rpc”;
$plik = file_get_contents($webservice, false, $context);
$odpowiedź = xmlrpc_decode ($plik);
if (xmlrpc_is_fault($odpowiedź)) (
zwróć "xmlrpc: $odpowiedź [fałdString] ($odpowiedź [kod błędu])";
) w przeciwnym razie (
zwróć $odpowiedź;
}
?>
1 - UWAGA REDAKCJI: TO JEST POPRAWKA Z „SandersWang dt php w Gmailu dot com”
16 lat temu
Ciągi binarne (ustawione za pomocą xmlrpc_set_type) idą do pliku a
Choć może to być głupie, powoduje prawdziwe problemy dla niektórych serwerów XML-RPC, takich jak http://jakarta.apache.org/xmlrpc/ (z domu Helma). Usunięcie tych bytów za pomocą czegoś takiego
$req = preg_replace("/ /", "", xmlrpc_encode_request("my.method", $args));
działa wokół problemu.
11 lat temu
Należy zauważyć, że kodowanie nie wydaje się kodować niczego, wystarczy określić, co trafia do nagłówka XML.
Wystąpiły problemy z zapisywaniem w bazie danych podwójnie zakodowanych ciągów UTF podczas korzystania z tej funkcji, wysyłaniem ich do serwletu Apache xml-rpc i przechowywaniem w bazie danych mysql. Zostało to rozwiązane poprzez ustawienie „ucieczki” na „znacznik” i „kodowanie” na „UTF-8” (nie zapomnij także ustawić „utf-8” w xmlrpc_decode).
Wygląda na to, że ciągi zakodowane w UTF-8 są ucieczki z bajtami jako jednostkami, a nie ze znakami jako jednostkami.
9 lat temu
Czy kiedykolwiek próbowałeś przesłać tablicę podobną do poniższej za pomocą xmlrpc?
$var1=tablica(7=>14,9=>18);
Tablica wyjściowa wygląda zupełnie inaczej! Będzie to wyglądać tak:
$zmienna2=tablica(14,18);
Jedynym rozwiązaniem, jakie znalazłem, jest dodanie spacji do indeksu:
$var3=tablica(" 7"=>14", 9"=>18);
Używając tej metody, uzyskasz właściwy wynik. ($var1)
16 lat temu
Ta funkcja powinna być używana przez klienta XML-RPC do tworzenia ładunku XML dla żądania XML-RPC;
$params = "system.methodSignature" ;
$method = "system.methodHelp" ;
$żądanie = xmlrpc_encode_request (metoda $, $params);
echo ($żądanie);
?>
Produkuje;
Drugi argument rozpoznaje typ zmiennej i generuje poprawną strukturę XML-RPC. Więcej szczegółów znajdziesz w xmlrpc_encode().
12 lat temu
Prosty klient OO z funkcją Przeciążenie:
metoda php test_helloworld jest tłumaczona na metodę xmlrpc test.helloworld.
klasa RpcClient(
prywatne metody $_;
prywatny $_context;
prywatny $_url;
Funkcja __construct ($url, $użytkownik, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $użytkownik,$passwd));
$this->_context = stream_context_create(array(
"http" => tablica(
"metoda" => "POST",
"header" => "Typ zawartości: tekst/xml\r\n".
"Autoryzacja: Podstawowa $auth" ,
)
));
$this->_url = $url;
$this->registerMethod("Test_HelloWorld");
Funkcja __call($nazwametody, $paramy) (
if (array_key_exists($nazwametody,$this->_methods)) (
// w aplikacji RPC
$m = str_replace("_", ".", $nazwametody);
$r = xmlrpc_encode_request($m, $params,array("gadatliwość"=>"newlines_only"));
$c = $this->_context;
stream_context_set_option($c,”http”,”treść”,$r);
$f = file_get_contents($this->_url,false,$c);
$resp = xmlrpc_decode($f);
zwróć $odpowiednio;
) w przeciwnym razie (
// na appelle la fonction de l"objet
call_user_method_array($nazwametody, $to,$params);
}
}
Funkcja prywatna RegisterMethod ($method) (
$this->_methods[$method] = true;
}
Wprowadzenie do XML-RPC
W Internecie istnieje wiele różnych zasobów, które dostarczają użytkownikom określonych informacji. Nie chodzi tu o zwykłe strony statyczne, ale np. dane pobrane z bazy danych lub archiwów. Może to być archiwum danych finansowych (kursy walut, dane o notowaniach papierów wartościowych), dane pogodowe lub informacje bardziej obszerne - aktualności, artykuły, wiadomości z forów. Informacje takie mogą być prezentowane osobie odwiedzającej stronę np. poprzez formularz, w odpowiedzi na zapytanie lub mogą być każdorazowo generowane dynamicznie. Trudność polega jednak na tym, że często takie informacje są potrzebne nie tyle użytkownikowi końcowemu - osobie, ale innym systemom i programom, które będą wykorzystywać te dane do swoich obliczeń lub innych potrzeb.
Prawdziwy przykład: strona witryny bankowej wyświetlająca notowania walut. Jeśli uzyskasz dostęp do strony jako zwykły użytkownik za pośrednictwem przeglądarki, zobaczysz cały projekt strony, banery, menu i inne informacje, które „ramują” prawdziwy cel wyszukiwania – notowania walut. Jeśli potrzebujesz wprowadzić te wyceny do swojego sklepu internetowego, nie pozostaje Ci nic innego jak ręcznie wybrać niezbędne dane i przenieść je na swoją stronę internetową poprzez schowek. I będziesz musiał to robić codziennie. Czy naprawdę nie ma wyjścia?
Jeśli rozwiążesz problem od razu, natychmiast pojawi się rozwiązanie: program (skrypt na stronie internetowej), który potrzebuje danych, otrzymuje stronę z serwera jako „zwykły użytkownik”, analizuje (parsuje) powstały kod HTML i wyodrębnia z niego niezbędne informacje. Można to zrobić za pomocą wyrażenia regularnego lub dowolnego parsera HTML. Trudność tego podejścia polega na jego nieskuteczności. Po pierwsze, aby otrzymać niewielką porcję danych (dane o walutach to dosłownie kilkanaście, dwa znaki), trzeba otrzymać całą stronę, która ma co najmniej kilkadziesiąt kilobajtów. Po drugie, w przypadku jakiejkolwiek zmiany w kodzie strony, na przykład zmiany projektu lub czegoś innego, nasz algorytm analizy będzie musiał zostać przerobiony. A to zajmie sporo zasobów.
Dlatego twórcy podjęli decyzję - należy opracować jakiś uniwersalny mechanizm, który umożliwiłby przejrzystą (na poziomie protokołu i medium transmisyjnego) i łatwą wymianę danych pomiędzy programami, które można zlokalizować w dowolnym miejscu, napisać w dowolnym języku i działać pod dowolnym systemem operacyjnym, systemami i dowolną platformą sprzętową. Taki mechanizm nazywany jest obecnie głośnymi określeniami „usługi sieciowe”, „SOAP”, „architektura zorientowana na usługi”. Do wymiany danych stosowane są otwarte i sprawdzone standardy - do przesyłania wiadomości używany jest protokół HTTP (choć można stosować inne protokoły - na przykład SMTP). Same dane (w naszym przykładzie kursy walut) przesyłane są w formacie wieloplatformowym – w postaci dokumentów XML. W tym celu wymyślono specjalny standard – SOAP.
Tak, teraz usługi sieciowe, SOAP i XML są na ustach wszystkich, zaczynają być aktywnie wdrażane, a duże korporacje, takie jak IBM i Microsoft, wypuszczają nowe produkty zaprojektowane, aby pomóc w całkowitym wdrożeniu usług sieciowych.
Ale! Dla naszego przykładu z kursami walut, które trzeba przesłać ze strony banku do silnika sklepu internetowego, takie rozwiązanie będzie bardzo trudne. Przecież sam opis standardu SOAP zajmuje nieprzyzwoite półtora tysiąca stron, a to nie wszystko. Do praktycznego zastosowania będziesz musiał także nauczyć się pracować z bibliotekami i rozszerzeniami innych firm (dopiero począwszy od PHP 5.0 zawiera bibliotekę do pracy z SOAP) i napisać setki i tysiące linii własnego kodu. A wszystko to, aby zdobyć kilka liter i cyfr, jest oczywiście bardzo kłopotliwe i irracjonalne.
Dlatego istnieje inny, można powiedzieć, alternatywny standard wymiany informacji - XML-RPC. Został opracowany przy udziale Microsoftu przez firmę UserLand Software Inc i przeznaczony jest do ujednoliconego przesyłania danych pomiędzy aplikacjami przez Internet. Może zastąpić SOAP przy budowaniu prostych usług, gdzie nie są potrzebne wszystkie możliwości „korporacyjne” prawdziwych usług sieciowych.
Co oznacza skrót XML-RPC? RPC oznacza zdalne wywołanie procedury. Oznacza to, że aplikacja (skrypt na serwerze lub zwykła aplikacja na komputerze klienckim) może w przejrzysty sposób korzystać z metody, która jest fizycznie zaimplementowana i wykonywana na innym komputerze. XML służy tutaj do zapewnienia uniwersalnego formatu opisu przesyłanych danych. Jako transport do przesyłania wiadomości wykorzystywany jest protokół HTTP, który umożliwia płynną wymianę danych za pośrednictwem dowolnych urządzeń sieciowych - routerów, zapór sieciowych, serwerów proxy.
I tak, aby skorzystać trzeba mieć: serwer XML-RPC udostępniający jedną lub więcej metod, klienta XML-RPC, który potrafi wygenerować poprawne żądanie i przetworzyć odpowiedź serwera, a także znać parametry serwera niezbędne do pomyślnego działania - adres, nazwę metody i przekazane parametry.
Cała praca z XML-RPC odbywa się w trybie „żądanie-odpowiedź”, jest to jedna z różnic między technologią a standardem SOAP, gdzie istnieją zarówno koncepcje transakcji, jak i możliwość wykonywania opóźnionych wywołań (kiedy serwer zapisuje żądanie i odpowiada na nie w określonym momencie w przyszłości). Te dodatkowe funkcje są bardziej przydatne w przypadku potężnych usług korporacyjnych, znacznie komplikują rozwój i obsługę serwerów oraz nakładają dodatkowe wymagania na twórców rozwiązań klienckich.
Procedura pracy z XML-RPC rozpoczyna się od utworzenia żądania. Typowe żądanie wygląda następująco:
POST/RPC2 HTTP/1.0
Agent użytkownika: eshop-test/1.1.1 (FreeBSD)
Host: serwer.localnet.com
Typ zawartości: tekst/xml
Długość treści: 172
Pierwsze wiersze tworzą standardowy nagłówek żądania HTTP POST. Wymagane parametry obejmują hosta, typ danych (typ MIME), który musi być tekstem/xml, oraz długość wiadomości. Norma określa również, że pole User-Agent musi być wypełnione, ale może zawierać dowolną wartość.
Następnie pojawia się zwykły nagłówek dokumentu XML. Podstawowym elementem żądania jest
Linia
Następnie ustawiane są przesyłane parametry. Do tego służy ta sekcja.
Po opisie wszystkich parametrów znajdują się znaczniki zamykające. Żądanie i odpowiedź w XML-RPC są zwykłymi dokumentami XML, więc wszystkie znaczniki muszą być zamknięte. Ale w XML-RPC nie ma pojedynczych tagów, chociaż są one obecne w standardzie XML.
Przyjrzyjmy się teraz odpowiedzi serwera. Nagłówek odpowiedzi HTTP jest normalny; jeśli żądanie zostanie pomyślnie przetworzone, serwer zwróci odpowiedź HTTP/1.1 200 OK. Podobnie jak w żądaniu należy poprawnie określić typ MIME, długość wiadomości oraz datę wygenerowania odpowiedzi.
Sama treść odpowiedzi jest następująca:
Teraz zamiast tagu głównego
Jeśli podczas przetwarzania Twojego żądania wystąpił błąd, zamiast Odpowiedź będzie zawierać element
Przyjrzyjmy się teraz krótko typom danych w XML-RPC. W sumie istnieje 9 typów danych – siedem prostych i 2 złożone. Każdy typ jest opisany własnym znacznikiem lub zestawem znaczników (w przypadku typów złożonych).
Proste typy:
Wszystkie liczby- etykieta
Typ logiczny- etykieta
Ciąg ASCII- opisane tagiem
Liczb zmiennoprzecinkowych- etykieta
Data i godzina- opisane tagiem
Ostatnim prostym typem jest Ciąg zakodowany w base64, który jest opisany tagiem
Typy złożone są reprezentowane przez struktury i tablice. Struktura jest określana przez element główny
Tablice nie mają nazw i są opisane znacznikiem
Oczywiście ktoś powie, że taka lista typów danych jest bardzo uboga i „nie pozwala na rozbudowę”. Tak, jeśli trzeba przesyłać złożone obiekty lub duże ilości danych, to lepiej skorzystać z protokołu SOAP. A dla małych, niewymagających aplikacji XML-RPC jest całkiem odpowiedni, co więcej, bardzo często nawet jego możliwości okazują się zbyt duże! Biorąc pod uwagę łatwość wdrożenia, bardzo dużą liczbę bibliotek dla niemal każdego języka i platformy oraz szerokie wsparcie w PHP, XML-RPC często po prostu nie ma konkurencji. Choć nie można od razu polecić go jako rozwiązania uniwersalnego – w każdym konkretnym przypadku należy o nim decydować w zależności od okoliczności.
Technologia XML-RPC jest wykorzystywana w systemie WordPress do różnych ciekawych funkcji, takich jak pingbacki, trackbacki, zdalne zarządzanie witryną bez logowania do panelu administracyjnego itp. Niestety, atakujący mogą go wykorzystać do przeprowadzenia ataków DDoS na strony internetowe. Oznacza to, że tworzysz dla siebie lub na zamówienie piękne, ciekawe projekty WP, a jednocześnie niczego nie podejrzewając, możesz być częścią botnetu DDoS. Łącząc ze sobą dziesiątki i setki tysięcy witryn, źli ludzie przeprowadzają potężny atak na swoją ofiarę. Chociaż w tym samym czasie Twoja witryna również cierpi, ponieważ... ładunek trafia do hostingu, na którym się znajduje.
Dowodem takiej złej aktywności mogą być dzienniki serwera (access.log w nginx), zawierające następujące linie:
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
Wróćmy jednak do luki w zabezpieczeniach XML-RPC. Wizualnie objawia się to powolnym otwieraniem stron na Twoim serwerze lub całkowitym brakiem możliwości ich załadowania (błąd 502 Bad Gateway). Wsparcie techniczne mojego hosta FASTVPS potwierdziło moje przypuszczenia i doradziło:
- Zaktualizuj WordPressa do najnowszej wersji wraz z wtyczkami. Ogólnie rzecz biorąc, jeśli śledzisz, mogłeś przeczytać o konieczności zainstalowania najnowszej wersji 4.2.3. ze względu na uwagi krytyczne dotyczące bezpieczeństwa (podobnie jak poprzednie wersje). Krótko mówiąc, warto zaktualizować.
- Zainstaluj wtyczkę Disable XML-RPC Pingback.
Wyłączanie XML-RPC w WordPress
Wcześniej wydawało mi się, że opcja włączenia/wyłączenia XML-RPC była gdzieś w ustawieniach systemu, ale teraz nie mogę jej tam znaleźć. Dlatego najłatwiejszym sposobem na pozbycie się go jest użycie odpowiedniej wtyczki.
Znajdź i pobierz Disable XML-RPC Pingback lub zainstaluj bezpośrednio z panelu administracyjnego systemu. Nie musisz nic dodatkowo konfigurować, moduł zaczyna działać natychmiast. Usuwa metody pingback.ping i pingback.extensions.getPingbacks z interfejsu XML-RPC. Dodatkowo usuwa X-Pingback z nagłówków HTTP.
Na jednym z blogów znalazłem jeszcze kilka opcji usunięcia wyłączenia XML-RPC.
1. Wyłącz XML-RPC w szablonie.
Aby to zrobić, dodaj następującą linię do plikufunctions.php motywu:
Ja osobiście nie korzystałem z dwóch ostatnich metod, bo... Podłączyłem wtyczkę Disable XML-RPC Pingback - myślę, że wystarczy. Tylko dla tych, którzy nie lubią niepotrzebnych instalacji, zaproponowałem alternatywne opcje.
Począwszy od południa w sobotę, mój serwer, na którym hostowanych jest około 25 witryn Wordpress, zaczął doświadczać poważnych spowolnień. Ponieważ udało mi się przetrwać poprzednie ataki ( , ) niezauważony, nie od razu zrozumiałem, co się dzieje.
Kiedy się zorientowałem, okazało się, że hasła były wymuszane metodą brute-force + wiele żądań do XMLRPC.
W rezultacie udało nam się to wszystko zerwać, choć nie od razu. Oto trzy proste triki, jak tego uniknąć.
Techniki te są najprawdopodobniej znane każdemu, ale nadepnąłem na kilka błędów, których nie znalazłem w opisach - może zaoszczędzi to komuś czas.
1. Zatrzymaj wyszukiwanie, zainstaluj wtyczkę Limit Login Attempts - zainstaluj ją, ponieważ inne zabezpieczenia znacznie spowalniają serwer, np. podczas korzystania z wtyczki Login Security Solution serwer umarł po pół godzinie, wtyczka mocno obciąża bazę danych .
W ustawieniach pamiętaj o zaznaczeniu pola wyboru „Dla proxy” - w przeciwnym razie określi adres IP Twojego serwera dla wszystkich i automatycznie zablokuje wszystkich.
AKTUALIZACJA, dziękuję, szczegóły poniżej w komentarzach - zaznacz pole wyboru „Dla proxy” tylko w przypadku, gdy definicja nie działa, gdy włączone jest „Połączenie bezpośrednie”
2. Wyłącz XML-RPC - wtyczka Wyłącz XML-RPC (aktywacja jest łatwa i to wszystko).
3. Zamknij wp-login.php – jeśli uzyskujesz dostęp do witryny przez IP, wtyczka nie działa, a selektory w dalszym ciągu powodują awarię witryny. Aby tego uniknąć, dodaj do .htaccess:
Kopiujemy plik wp-login, zmieniamy jego nazwę na dowolną dziwną nazwę, na przykład poletnormalny.php, a wewnątrz pliku za pomocą autokorekty zmieniamy wszystkie napisy wp-login.php na poletnormalny.php.
To wszystko, teraz możesz uzyskać dostęp do panelu administracyjnego tylko przy użyciu swojego pliku.
Po tych 3 prostych krokach strony znów zaczęły latać i nastał pokój.
Cóż, nagle zrobiło się interesująco
Jedną z opcji jest sprawdzenie, czy jesteś atakowany. Można to zobaczyć w logach nginx (na przykład tutaj jest ścieżka do pliku Debiana /var/log/nginx access.log).WordPress zawsze miał wbudowane narzędzie umożliwiające zdalny dostęp do Twojej witryny. Rzeczywiście, czasami musisz dostać się na swoją stronę, ale twój komputer jest daleko od ciebie. Przez długi czas rozwiązaniem był plik o nazwie xmlrpc.php. Jednak w ostatnich latach plik ten stał się bardziej problemem niż rozwiązaniem.
Poniżej przyjrzymy się bliżej plikowi xmlrpc.php i powodowi jego powstania. Przyjrzymy się również typowym problemom związanym z bezpieczeństwem, jakie może powodować, i sposobom ich naprawienia w witrynie WordPress.
XML-RPC to funkcja WordPress, która umożliwia przesyłanie danych, przy czym HTTP służy jako transport, a XML do kodowania. Ponieważ WordPress nie jest systemem zamkniętym i często komunikuje się z innymi systemami, znaleziono rozwiązania tego problemu.
Załóżmy na przykład, że chcesz opublikować posty w swojej witrynie internetowej ze swojego telefonu komórkowego. Musisz skorzystać ze zdalnego dostępu zapewnianego przez xmlrpc.php.
Główną funkcjonalnością xmlrpc.php jest możliwość połączenia się z witryną ze smartfona, implementacja trackbacków i linków zwrotnych z innych stron oraz niektóre funkcje związane z wtyczką Jetpack.
Dlaczego utworzono plik Xmlrpc.php i jak go wykorzystano?
Wdrożenie XML-RPC sięga początków WordPressa, a nawet jeszcze zanim WordPress stał się WordPressem.
W początkach Internetu połączenia były bardzo wolne, a proces nagrywania i publikowania w Internecie był znacznie trudniejszy i bardziej czasochłonny. Zamiast wprowadzać zmiany bezpośrednio w przeglądarce, większość przełączała je w tryb offline, a następnie kopiowała i wklejała ich zawartość online. A proces ten był daleki od ideału.
Rozwiązaniem (wówczas) było stworzenie klienta blogowania offline, w którym można komponować treści, a następnie łączyć się ze swoim blogiem i go publikować. To połączenie zostało nawiązane poprzez XML-RPC. Dzięki podstawowej funkcjonalności XML-RPC wczesne aplikacje korzystające z tych połączeń umożliwiły użytkownikom dostęp do witryn WordPress z innych urządzeń.
XML-RPC dzisiaj
W 2008 roku w wersji 2.6 WordPressa wprowadzono opcję włączania lub wyłączania XML-RPC. Jednak wraz z wydaniem aplikacji WordPress na iPhone'a obsługa XML-RPC została domyślnie włączona i nie było możliwości jej wyłączenia. Tak pozostaje dzisiaj.
Oczywiście funkcjonalność tego pliku z biegiem czasu znacznie się zmniejszyła, a rozmiar pliku zmniejszył się z 83kb do 3kb, nie odgrywa już on takiej roli jak wcześniej.
Właściwości XML-RPC
Dzięki nowemu interfejsowi programowania aplikacji WordPress (API) możemy spodziewać się całkowitego wyłączenia XML-RPC. Dziś ten nowy interfejs API jest nadal w fazie testów i można go włączyć jedynie za pomocą specjalnej wtyczki.
Chociaż można się spodziewać, że w przyszłości interfejs API zostanie włączony bezpośrednio do rdzenia WordPressa, co całkowicie wyeliminuje potrzebę xmlrpc.php.
Nowe API nie jest idealne, ale zapewnia dobre i niezawodne bezpieczeństwo, w przeciwieństwie do xmlrpc.php.
Po co wyłączać Xmlrpc.php
Największym problemem związanym z XML-RPC jest bezpieczeństwo. Problem nie jest bezpośrednio związany z XML-RPC, ale można go wykorzystać do umożliwienia ataku na Twoją witrynę.
Oczywiście możesz zabezpieczyć się bardzo silnym hasłem i wtyczkami zabezpieczającymi WordPress. Ale najlepszym trybem ochrony jest po prostu jego wyłączenie.
Istnieją dwie główne słabości XML-RPC, które były wykorzystywane w przeszłości.
Pierwszy z nich wykorzystuje ataki brute-force w celu uzyskania dostępu do Twojej witryny. Osoba atakująca będzie próbowała uzyskać dostęp do Twojej witryny za pomocą pliku xmlrpc.php, wypróbowując różne kombinacje nazw użytkowników i haseł. Potrafią efektywnie wykorzystać jedno polecenie do przetestowania setek różnych haseł. Pozwala im to ominąć narzędzia bezpieczeństwa, które normalnie wykrywają i blokują ataki typu brute-force.
Drugim jest przełączenie witryny w tryb offline poprzez atak DDoS. Hakerzy wykorzystają powiadomienie zwrotne w WordPressie, aby wysłać je jednocześnie do tysięcy witryn. Ta funkcjonalność xmlrpc.php daje hakerom niemal nieskończoną liczbę adresów IP do propagowania ataku DDoS.
Aby sprawdzić, czy XML-RPC działa w Twojej witrynie, możesz uruchomić go za pomocą narzędzia o nazwie XML-RPC Validator. Uruchom swoją witrynę za pomocą narzędzia, a jeśli pojawi się błąd, oznacza to, że nie masz obsługi XML-RPC.
Jeśli otrzymasz wiadomość o powodzeniu, możesz zatrzymać plik xmlrpc.php, korzystając z jednego z dwóch poniższych sposobów.
Metoda 1: Wyłącz Xmlrpc.php za pomocą wtyczki
Wyłączenie XML-RPC w witrynie WordPress jest niezwykle łatwe.
Przejdź do sekcji Wtyczki › Dodaj nowe w konsoli administracyjnej WordPress. Znajdź wtyczkę Wyłącz XML-RPC i zainstaluj, wygląda to jak na obrazku poniżej:
Aktywuj wtyczkę i gotowe. Ta wtyczka automatycznie wstawi niezbędny kod, aby wyłączyć XML-RPC.
Pamiętaj jednak, że zainstalowane wtyczki mogą korzystać z części XML-RPC, a następnie wyłączenie tego może spowodować konflikt pomiędzy wtyczkami lub ich poszczególnymi częściami i wyprowadzić je z trybu pracy.
Jeśli chcesz wyłączyć tylko poszczególne elementy XML-RPC, ale pozwolić na działanie innych wtyczek i funkcji, spójrz na wtyczki takie jak te:
- Zatrzymaj atak XML-RPC. Ta wtyczka zatrzyma wszystkie ataki XML-RPC, ale pozwoli wtyczkom takim jak Jetpack i innym zautomatyzowanym narzędziom i wtyczkom na dalsze działanie, dając im dostęp do plików xmlrpc.php.
- Kontroluj publikację XML-RPC. Dzięki temu możesz zachować kontrolę i publikować zdalnie.
Metoda 2: Wyłącz ręcznie Xmlrpc.php
Jeśli nie chcesz używać wtyczki i wolisz robić to ręcznie, zastosuj to podejście. Zatrzyma wszystkie przychodzące żądania xmlrpc.php, zanim zostaną przekazane do WordPress.
Otwórz plik .htaccess. Aby znaleźć ten plik, konieczne może być włączenie opcji „pokaż ukryte pliki” w menedżerze plików lub kliencie FTP.
Wklej ten kod do pliku .htaccess:
# Blokuj żądania WordPress xmlrpc.php
Końcowe przemyślenia
Ogólnie rzecz biorąc, XML-RPC był solidnym rozwiązaniem niektórych problemów związanych ze zdalnym publikowaniem w witrynie WordPress. Jednak jednocześnie pojawiły się pewne luki w zabezpieczeniach, które okazały się dość niebezpieczne dla niektórych właścicieli witryn WordPress.
Aby zapewnić bezpieczeństwo witryny, zaleca się całkowite wyłączenie xmlrpc.php, chyba że potrzebujesz niektórych funkcji wymaganych przez zdalne publikowanie i wtyczkę Jetpack. Następnie możesz użyć wtyczek obejściowych, które pozwolą ci korzystać z tych funkcji podczas łatania luk w zabezpieczeniach.
Z biegiem czasu możemy spodziewać się, że funkcjonalność XML-RPC zostanie zintegrowana z nowym interfejsem API WordPress, który będzie obsługiwał zdalny dostęp bez poświęcania bezpieczeństwa.
Czy zablokowałeś dostęp do XML-RPC poprzez wtyczkę lub ręcznie? A może wystąpiły jakieś problemy z bezpieczeństwem, ponieważ był wcześniej aktywny? Podziel się swoimi doświadczeniami w komentarzach poniżej.
