Bevezetés az XML-RPC-be. Programozási versenyek Mi látható a szervernaplókban
A bejegyzése azt is bemutatja, hogyan kell a böngésző hitelesítését elvégezni, az alábbiak szerint:
$request = xmlrpc_encode_request ("methodName" , array("methodParam" ));
$auth = base64_encode ($felhasználónév . ":" . $jelszó );
$header = (verzió_összehasonlítás(phpversion(), "5.2.8"))
? array("Content-Type: text/xml" , "Engedélyezés: Basic $auth " )
: "Tartalomtípus: szöveg/xml\r\nJogosultság: Alapvető$auth " ; //
$context = stream_context_create (array("http" => array(
"method" => "POST" ,
"header" => $header ,
"tartalom" => $kérelem
)));
$webszolgáltatás = "http://www.example.com/rpc";
$file = file_get_contents($webservice, false, $kontextus);
$válasz = xmlrpc_decode ($fájl);
if (xmlrpc_is_fault($response)) (
return "xmlrpc: $response [ faultString ] ($response [ faultCode ] )" ;
) más (
return $válasz ;
}
?>
1 – SZERKESZTŐ MEGJEGYZÉS: EZ A „SandersWang dt php at gmail dot com” OLDALÁNAK JAVÍTÁSA
16 évvel ezelőtt
A bináris karakterláncok (az xmlrpc_set_type paraméterrel beállítva) az a
Bármennyire butaság is, ez valódi problémákat okoz egyes XML-RPC szervereknél, mint például a http://jakarta.apache.org/xmlrpc/ (nee Helma). Az ilyen entitások eltávolítása valami hasonlóval
$req = preg_replace("/ /", "", xmlrpc_encode_request("my.method", $args));
működik a probléma körül.
11 évvel ezelőtt
Megjegyzendő, hogy a kódolás nem kódol semmit, csak adja meg, hogy mi kerüljön az XML-fejlécbe.
Problémánk volt a kettős kódolású UTF-karakterláncok adatbázisba mentésével, amikor ezt a funkciót használták, majd elküldték egy apache xml-rpc szervletnek, és tárolták a mysql adatbázisban. Úgy oldották meg, hogy az "escaping"-t csak "markup"-ra, az "encoding"-t pedig "UTF-8"-ra állítottuk (ne felejtsd el beállítani az "utf-8"-t az xmlrpc_decode-ban sem).
Úgy tűnik, hogy az UTF-8 kódolású karakterláncok a bájtjaikkal mint entitásokkal kerülnek kikerülésre, nem pedig a karaktereikre mint entitásokra.
9 évvel ezelőtt
Próbálkozott már az alábbihoz hasonló tömb továbbításával xmlrpc-vel?
$var1=tömb(7=>14,9=>18);
A kimeneti tömb egészen másképp néz ki! Így fog kinézni:
$var2=tömb(14,18);
Az egyetlen megoldás, amit találtam, hogy szóközt fűzök az index elé:
$var3=array(" 7"=>14," 9"=>18);
Ezzel a módszerrel a megfelelő eredményt kapja. ($var1)
16 évvel ezelőtt
Ezt a funkciót egy XML-RPC kliensnek kell használnia XML hasznos adat létrehozásához egy XML-RPC kéréshez;
$params = "system.methodSignature" ;
$method = "system.methodHelp" ;
$request = xmlrpc_encode_request ($method, $params);
visszhang ($kérés);
?>
termel;
A második argumentum felismeri a változó típusát, és létrehozza a megfelelő XML-RPC struktúrát. További részletekért lásd: xmlrpc_encode().
12 évvel ezelőtt
Egyszerű OO kliens túlterhelés funkcióval:
a test_helloworld php metódus lefordítva xmlrpc metódusra test.helloworld.
osztály RpcClient(
privát $_methods;
privát $_context;
privát $_url;
__construct függvény ($url, $user, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $user,$passwd));
$this->_context = stream_context_create(array(
"http" => array(
"method" => "POST",
"header" => "Tartalom típusa: text/xml\r\n".
"Authorization: Basic $auth" ,
)
));
$this->_url = $url;
$this->registerMethod("Test_HelloWorld");
Függvény __call($methodName, $params) (
if (array_key_exists($methodName,$this->_methods)) (
// on appelle la fonction RPC
$m = str_replace("_", ".", $methodName);
$r = xmlrpc_encode_request($m, $params,array("verbosity"=>"csak újsorok_"));
$c = $this->_context;
stream_context_set_option($c,"http","tartalom",$r);
$f = file_get_contents($this->_url,false,$c);
$resp = xmlrpc_decode($f);
return $resp;
) más (
// on appelle la fonction de l"objet
call_user_method_array($methodName, $this,$params);
}
}
Privát függvény registerMethod ($method) (
$this->_methods[$method] = igaz;
}
Bevezetés az XML-RPC-be
Az interneten számos különféle forrás található, amelyek bizonyos információkat szolgáltatnak a felhasználóknak. Ez nem közönséges statikus oldalakat jelent, hanem például adatbázisból vagy archívumból visszakeresett adatokat. Ez lehet pénzügyi adatok (árfolyamok, értékpapír-jegyzési adatok), időjárási adatok vagy terjedelmesebb információk – hírek, cikkek, fórumok üzenetei – archívuma. Az ilyen információk az oldal látogatójának bemutathatók például űrlapon keresztül, kérésre válaszként, vagy minden alkalommal dinamikusan generálhatók. De a nehézség az, hogy gyakran az ilyen információkra nem annyira a végfelhasználónak - egy személynek -, hanem más rendszereknek és programoknak van szüksége, amelyek ezeket az adatokat számításaikhoz vagy egyéb szükségleteikhez használják fel.
Valódi példa: egy banki webhely oldala, amelyen devizaárfolyamok jelennek meg. Ha normál felhasználóként, egy böngészőn keresztül lép fel az oldalra, akkor minden oldalterv, bannerek, menük és egyéb információk láthatók, amelyek „bekeretik” a keresés valódi célját – devizajegyzéseket. Ha ezeket az árajánlatokat be kell írnia webáruházába, akkor nincs más hátra, mint manuálisan kiválasztani a szükséges adatokat, és a vágólapon keresztül átvinni a weboldalára. És ezt minden nap meg kell tennie. Tényleg nincs kiút?
Ha azonnal megoldja a problémát, akkor azonnal felmerül a megoldás: egy adatot igénylő program (weboldalon lévő szkript) „rendes felhasználóként” kap egy oldalt a szervertől, elemzi (elemzi) a kapott html kódot, és kibontja a szükséges információkat belőle. Ez megtehető reguláris reguláris kifejezéssel vagy bármilyen html elemzővel. A megközelítés nehézsége a hatástalanságban rejlik. Először is, egy kis adatrész fogadásához (a pénznemekre vonatkozó adatok szó szerint egy tucat vagy két karakterből állnak), meg kell kapnia a teljes oldalt, amely legalább több tíz kilobájt. Másodszor, ha megváltozik az oldal kódja, például megváltozott a design vagy valami más, az elemzési algoritmusunkat újra kell készíteni. Ez pedig megfelelő mennyiségű erőforrást igényel.
Ezért a fejlesztők arra a döntésre jutottak, hogy ki kell dolgozni valami univerzális mechanizmust, amely lehetővé teszi az átlátható (protokoll és átviteli közeg szintjén) és könnyű adatcserét a bárhol elhelyezhető, bármilyen nyelven írható programok között. és bármilyen operációs rendszer alatt futtatható.rendszereken és bármilyen hardverplatformon. Egy ilyen mechanizmust ma „webszolgáltatások”, „SOAP”, „szolgáltatás-orientált architektúra” kifejezéseknek neveznek. Az adatcseréhez nyílt és időben tesztelt szabványokat használnak - a HTTP protokollt használják az üzenetek továbbítására (bár más protokollok is használhatók - például SMTP). Maguk az adatok (példánkban az árfolyamok) többplatformos formátumban csomagolva kerülnek továbbításra - XML dokumentumok formájában. Erre a célra egy speciális szabványt találtak ki - SOAP.
Igen, a webszolgáltatások, a SOAP és az XML már mindenki ajkán szerepel, kezdik aktív bevezetésüket, és az olyan nagyvállalatok, mint az IBM és a Microsoft új termékeket adnak ki, amelyek a webszolgáltatások teljes megvalósítását segítik elő.
De! Példánkban, ahol az árfolyamokat a bank weboldaláról kell továbbítani az online áruház motorjába, egy ilyen megoldás nagyon nehéz lesz. Hiszen a SOAP szabvány leírása önmagában obszcén másfélezer oldalt foglal el, és ez még nem minden. A gyakorlati használathoz meg kell tanulnia dolgozni harmadik féltől származó könyvtárakkal és bővítményekkel (csak a PHP 5.0-tól kezdődően tartalmaz könyvtárat a SOAP-pal való munkához), és meg kell írnia több száz és ezer soros saját kódot. És mindez azért, hogy néhány betűt és számot kapjunk, nyilvánvalóan nagyon körülményes és irracionális.
Ezért van egy másik, mondhatni alternatív szabvány az információcserére - XML-RPC. A Microsoft részvételével fejlesztette ki a UserLand Software Inc., és az alkalmazások közötti egységes adatátvitelre szolgál az interneten keresztül. Leválthatja a SOAP-ot egyszerű szolgáltatások felépítésénél, ahol nincs szükség a valódi webszolgáltatások összes „vállalati” képességére.
Mit jelent az XML-RPC rövidítés? Az RPC a Remote Procedure Call rövidítése. Ez azt jelenti, hogy egy alkalmazás (akár egy parancsfájl a kiszolgálón, akár egy szokásos alkalmazás az ügyfélszámítógépen) transzparens módon használhat egy másik számítógépen fizikailag megvalósított és végrehajtott metódust. Az XML itt egy univerzális formátumot biztosít a továbbított adatok leírásához. Szállításként a HTTP protokollt használják üzenetek továbbítására, amely lehetővé teszi az adatok zökkenőmentes cseréjét bármilyen hálózati eszközön - útválasztókon, tűzfalakon, proxyszervereken - keresztül.
Tehát a használathoz rendelkeznie kell: egy XML-RPC szerverrel, amely egy vagy több metódust biztosít, egy XML-RPC klienssel, amely képes megfelelő kérést generálni és feldolgozni a szerver választ, valamint ismeri a sikeres működéshez szükséges szerver paramétereket - cím, metódusnév és átadott paraméterek.
Minden XML-RPC-vel végzett munka a „kérés-válasz” módban történik, ez az egyik különbség a technológia és a SOAP szabvány között, ahol mind a tranzakciók fogalma, mind a késleltetett hívások kezdeményezése (amikor a szerver ment a kérést, és a jövőben egy bizonyos időpontban válaszol rá). Ezek a kiegészítő szolgáltatások hasznosabbak az erőteljes vállalati szolgáltatásoknál, jelentősen megnehezítik a szerverek fejlesztését és támogatását, és további követelményeket támasztanak a kliensmegoldások fejlesztőivel szemben.
Az XML-RPC-vel való munkafolyamat a kérés létrehozásával kezdődik. Egy tipikus kérés így néz ki:
POST /RPC2 HTTP/1.0
User-Agent: eshop-test/1.1.1 (FreeBSD)
Gazda: server.localnet.com
Tartalom típusa: szöveg/xml
Tartalom hossza: 172
Az első sorok a szabványos HTTP POST kérés fejlécet alkotják. A kötelező paraméterek közé tartozik a gazdagép, az adattípus (MIME-típus), amelynek szöveg/xml-nek kell lennie, és az üzenet hossza. A szabvány azt is előírja, hogy a User-Agent mezőt ki kell tölteni, de tetszőleges értéket tartalmazhat.
Ezután következik az XML dokumentum szokásos fejléce. A kérés gyökéreleme az
Vonal
Ezután be kell állítani a továbbított paramétereket. Ez a szakasz erre szolgál.
Az összes paraméter leírását záró tagek követik. Az XML-RPC kérése és válasza normál XML dokumentumok, ezért minden címkét be kell zárni. Az XML-RPC-ben azonban nincsenek egyetlen címkék, bár az XML szabványban megtalálhatók.
Most nézzük a szerver válaszát. A HTTP válaszfejléc normális; ha a kérést sikeresen feldolgozták, a szerver HTTP/1.1 200 OK választ ad vissza. Csakúgy, mint a kérésben, helyesen kell megadnia a MIME típusát, az üzenet hosszát és a válasz generálásának dátumát.
Maga a választest a következő:
Most a gyökércímke helyett
Ha hiba történt kérésének feldolgozása közben, ahelyett A válasz tartalmazza az elemet
Most vessünk egy rövid pillantást az XML-RPC adattípusaira. Összesen 9 adattípus létezik - hét egyszerű és 2 összetett. Minden típust saját címkével vagy címkekészlettel írnak le (összetett típusok esetén).
Egyszerű típusok:
Egész számok- címke
Logikai típus- címke
ASCII karakterlánc- címke írja le
Lebegőpontos számok- címke
dátum és idő- címke írja le
Az utolsó egyszerű típus az base64 kódolású karakterlánc, amelyet a címke ír le
Az összetett típusokat struktúrák és tömbök képviselik. A szerkezetet a gyökérelem határozza meg
A tömböknek nincs neve, és a címke írja le őket
Természetesen valaki azt mondja, hogy az adattípusok ilyen listája nagyon szegényes, és „nem teszi lehetővé a bővítést”. Igen, ha összetett objektumokat vagy nagy mennyiségű adatot kell átvinnie, akkor jobb a SOAP használata. Kisebb, igénytelen alkalmazásokhoz pedig az XML-RPC eléggé megfelelő, sőt gyakran még a képességei is túl soknak bizonyulnak! Figyelembe véve az egyszerű telepítést, a szinte bármilyen nyelvhez és platformhoz használható könyvtárak nagy számát, valamint a PHP széles körű támogatását, az XML-RPC-nek gyakran egyszerűen nincs versenytársa. Bár nem ajánlható azonnal univerzális megoldásként - minden konkrét esetben a körülményeknek megfelelően kell dönteni.
Az XML-RPC technológiát a WordPress rendszerben különféle szép funkciókhoz használják, mint például a pingback, trackback, távoli webhelykezelés az adminisztrációs panelbe való bejelentkezés nélkül stb. Sajnos a támadók DDoS-támadásokat hajthatnak végre webhelyeken. Vagyis gyönyörű, érdekes WP projekteket készítesz magadnak vagy rendelésre, és egyúttal anélkül, hogy sejtenéd, részese lehetsz egy DDoS botnetnek. Webhelyek tíz- és százezrei összekapcsolásával a rossz emberek erőteljes támadást indítanak áldozataik ellen. Bár ugyanakkor az Ön webhelye is szenved, mert... a terhelés a tárhelyre kerül, ahol található.
Az ilyen rossz tevékenység bizonyítéka lehet a szervernaplókban (access.log in nginx), amelyek a következő sorokat tartalmazzák:
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
De térjünk vissza az XML-RPC sebezhetőségéhez. Vizuálisan ez abban nyilvánul meg, hogy lassan nyitják meg a webhelyeket a szerveren, vagy egyáltalán nem tudják betölteni őket (502-es Bad Gateway hiba). A FASTVPS házigazdám technikai támogatása megerősítette sejtéseimet, és a következőket tanácsolta:
- Frissítse a WordPress-t a legújabb verzióra a bővítményekkel együtt. Általánosságban elmondható, hogy ha követi, akkor talán olvasott arról, hogy telepítenie kell a legújabb 4.2.3-at. biztonsági kritikák miatt (a korábbi verziókhoz hasonlóan). Egyszóval jó frissíteni.
- Telepítse az XML-RPC Pingback letiltása bővítményt.
Az XML-RPC letiltása a WordPressben
Korábban úgy tűnt, hogy az XML-RPC engedélyezése/letiltása valahol a rendszerbeállításokban volt, de most nem találom ott. Ezért a legegyszerűbb módja annak, hogy megszabaduljon tőle, ha használja a megfelelő bővítményt.
Keresse meg és töltse le az XML-RPC Pingback letiltását, vagy telepítse közvetlenül a rendszergazdai panelről. Nincs szükség további konfigurálásra, a modul azonnal működésbe lép. Eltávolítja a pingback.ping és pingback.extensions.getPingbacks metódusokat az XML-RPC felületről. Ezenkívül eltávolítja az X-Pingbacket a HTTP-fejlécekből.
Az egyik blogban találtam még néhány lehetőséget az XML-RPC letiltásának megszüntetésére.
1. Tiltsa le az XML-RPC-t a sablonban.
Ehhez adja hozzá a következő sort a téma functions.php fájljához:
Én személy szerint nem az utolsó két módszert használtam, mert... Bekapcsoltam a Disable XML-RPC Pingback plugint - szerintem elég lesz. Csak azoknak, akik nem szeretik a felesleges telepítéseket, alternatív lehetőségeket javasoltam.
Szombat déltől kezdődően a szerverem, ahol körülbelül 25 Wordpress-webhely található, súlyos lelassulásokat tapasztalt. Mivel sikerült észrevétlenül túlélnem a korábbi támadásokat ( , ), nem értettem azonnal, mi történik.
Amikor rájöttem, kiderült, hogy a jelszavakat brutálisan kényszerítették + sok kérés az XMLRPC-hez.
Ennek eredményeként sikerült az egészet megszakítani, bár nem azonnal. Íme három egyszerű trükk, hogyan kerüld el ezt.
Ezeket a technikákat valószínűleg mindenki ismeri, de ráléptem néhány olyan hibára, amelyeket nem találtam a leírásokban - talán ezzel időt takaríthat meg valaki.
1. Állítsa le a keresést, telepítse a Limit Login Attempts bővítményt - telepítse, mivel más védelmek nagyban lelassítják a szervert, például a Login Security Solution bővítmény használatakor a szerver fél óra után meghalt, a bővítmény erősen terheli az adatbázist .
A beállításokban feltétlenül kapcsolja be a „Proxyhoz” jelölőnégyzetet - különben mindenki számára meghatározza a szerver IP-jét, és automatikusan blokkol mindenkit.
FRISSÍTÉS, köszönjük, a részletek a megjegyzésekben találhatók - csak akkor engedélyezze a „Proxyhoz” jelölőnégyzetet, ha a definíció nem működik, ha a „Közvetlen kapcsolat” engedélyezve van
2. Az XML-RPC letiltása - az XML-RPC letiltása plugin (egyszerű aktiválni, és kész).
3. Zárja be a wp-login.php-t – ha IP-n keresztül éri el a webhelyet, a bővítmény nem működik, és a kiválasztók továbbra is összeomlik a webhelyet. Ennek elkerülése érdekében adja hozzá a .htaccess fájlhoz:
Kimásoljuk a wp-login fájlt, átnevezzük bármilyen furcsa névre, például poletnormalny.php, és a fájlon belül az automatikus javítással módosítjuk az összes wp-login.php feliratot poletnormalny.php-re.
Ez az, most már csak a fájl használatával érheti el az adminisztrációs panelt.
E 3 egyszerű lépés után az oldalak újra repülni kezdtek, és megérkezett a béke.
Nos, hirtelen érdekes
Az egyik lehetőség az, hogy megnézze, nem támadnak-e meg. Ez látható az nginx naplókban (például itt van a Debian /var/log/nginx access.log fájl elérési útja).A WordPress mindig is rendelkezett beépített eszközzel a webhely távoli elérésére. Valójában néha el kell jutnia a webhelyére, de a számítógépe messze van Öntől. A megoldást sokáig az xmlrpc.php nevű fájl jelentette. Az utóbbi években azonban ez a fájl inkább probléma, mint megoldás.
Az alábbiakban közelebbről megvizsgáljuk az xmlrpc.php-t és azt, hogy miért jött létre. Azt is megvizsgáljuk, hogy milyen gyakori biztonsági problémákat okozhat, és hogyan javíthatja ki őket WordPress-webhelyén.
Az XML-RPC a WordPress egy olyan funkciója, amely lehetővé teszi az adatátvitelt, a HTTP pedig átvitelként, az XML pedig kódolásként szolgál. Mivel a WordPress nem zárt rendszer, és gyakran kommunikál más rendszerekkel, megoldásokat találtak erre a problémára.
Tegyük fel például, hogy mobiltelefonjáról szeretne bejegyzéseket küldeni a webhelyére. Használnia kell az xmlrpc.php által biztosított távoli hozzáférést.
Az xmlrpc.php fő funkciója az, hogy okostelefonról csatlakozni lehet az oldalhoz, más webhelyekről visszakövetések és linkbackek megvalósítása, valamint néhány, a Jetpack bővítményhez kapcsolódó funkció.
Miért jött létre az Xmlrpc.php, és hogyan használták?
Az XML-RPC megvalósítása egészen a WordPress kezdeteiig nyúlik vissza, és még azelőtt, hogy a WordPress WordPress lett volna.
Az internet kezdeti idejében a kapcsolatok nagyon lassúak voltak, a felvételek és az interneten való közzététel folyamata pedig sokkal bonyolultabb és időigényesebb volt. Ahelyett, hogy közvetlenül a böngészőn keresztül hajtották volna végre a módosításokat, a legtöbben offline állapotba hozták őket, majd másolták és beillesztették a tartalmat az internetre. És ez a folyamat messze volt az ideálistól.
A megoldás (akkoriban) egy offline blogoló kliens létrehozása volt, ahol összeállíthatta a tartalmat, majd csatlakozhat a blogjához és közzéteheti. Ez a kapcsolat XML-RPC-n keresztül jött létre. Az alapvető XML-RPC funkciókkal az ezeket a kapcsolatokat használó korai alkalmazások lehetővé tették az emberek számára, hogy más eszközökről hozzáférjenek WordPress-webhelyeikhez.
XML-RPC ma
2008-ban a WordPress 2.6-os verziójában lehetőség nyílt az XML-RPC engedélyezésére vagy letiltására. A WordPress iPhone-alkalmazás kiadásával azonban az XML-RPC támogatás alapértelmezés szerint engedélyezve lett, és nem volt lehetőség letiltani. Ez ma is így maradt.
Természetesen ennek a fájlnak a funkcionalitása az idő múlásával jelentősen csökkent, a fájl mérete pedig 83kb-ról 3kb-ra csökkent, már nem tölt be olyan szerepet, mint korábban.
XML-RPC tulajdonságok
Az új WordPress alkalmazásprogramozási felülettel (API) arra számíthatunk, hogy az XML-RPC teljesen le lesz tiltva. Ez az új API ma még tesztelés alatt áll, és csak egy speciális beépülő modulon keresztül engedélyezhető.
Bár várható, hogy az API a jövőben közvetlenül a WordPress magjába kerül, így teljesen megszűnik az xmlrpc.php szükségessége.
Az új API nem tökéletes, de jó, megbízható biztonságot nyújt, ellentétben az xmlrpc.php-vel.
Miért tiltsa le az Xmlrpc.php fájlt
Az XML-RPC legnagyobb problémája a biztonság. A probléma nem kapcsolódik közvetlenül az XML-RPC-hez, de használható a webhely elleni támadások engedélyezésére.
Természetesen megvédheti magát egy nagyon erős jelszóval és a WordPress biztonsági bővítményeivel. De a legjobb védelmi mód az, ha egyszerűen kikapcsolja.
Az XML-RPC-nek két fő gyengesége van, amelyeket a múltban kihasználtak.
Az első brute force támadásokat használ a webhelyhez való hozzáféréshez. A támadó a felhasználónevek és jelszavak különböző kombinációival próbál hozzáférni az Ön webhelyéhez az xmlrpc.php használatával. Hatékonyan használhatnak egyetlen parancsot több száz különböző jelszó tesztelésére. Ez lehetővé teszi számukra, hogy megkerüljék azokat a biztonsági eszközöket, amelyek normál esetben észlelik és blokkolják a brute force támadásokat.
A második a webhely offline állapotba állítása DDoS-támadáson keresztül. A hackerek a WordPress fordított értesítését fogják használni, hogy egyszerre több ezer webhelyre küldjék el. Ez az xmlrpc.php funkció szinte végtelen számú IP-címet biztosít a hackereknek a DDoS támadások terjesztéséhez.
Ha ellenőrizni szeretné, hogy az XML-RPC működik-e a webhelyén, futtassa az XML-RPC Validator nevű eszközzel. Futtassa webhelyét az eszközzel, és ha hibaüzenetet kap, az azt jelenti, hogy nem támogatja az XML-RPC-t.
Ha sikerüzenetet kap, leállíthatja az xmlrpc.php fájlt az alábbi két módszer egyikével.
1. módszer: Tiltsa le az Xmlrpc.php fájlt egy bővítmény segítségével
Az XML-RPC letiltása a WordPress webhelyén hihetetlenül egyszerű.
Ugrás a szakaszra Bővítmények › Új hozzáadása a WordPress felügyeleti konzoljában. Keressen egy plugint Az XML-RPC letiltásaés telepítse, úgy néz ki, mint az alábbi képen:
Aktiválja a bővítményt, és kész. Ez a beépülő modul automatikusan beilleszti a szükséges kódot az XML-RPC letiltásához.
Ne feledje azonban, hogy a telepített beépülő modulok használhatják az XML-RPC egyes részeit, és ennek letiltása ütközést okozhat a beépülő modulok vagy azok egyes részei között, és kiveheti őket működési módból.
Ha csak az egyes XML-RPC elemeket szeretné letiltani, de engedélyezi más beépülő modulok és szolgáltatások működését, akkor nézze meg az alábbi bővítményeket:
- Állítsa le az XML-RPC támadást. Ez a beépülő modul leállít minden XML-RPC támadást, de lehetővé teszi az olyan beépülő modulok, mint a Jetpack és más automatizált eszközök és beépülő modulok futásának folytatását, hozzáférést biztosítva számukra az xmlrpc.php fájlokhoz.
- Az XML-RPC Publishing vezérlése. Ez lehetővé teszi az irányítás fenntartását és a távoli közzétételt.
2. módszer: Az Xmlrpc.php manuális letiltása
Ha nem szeretne bővítményt használni, és inkább manuálisan szeretné megtenni, kövesse ezt a megközelítést. Leállítja az összes bejövő xmlrpc.php kérést, mielőtt átadná a WordPressnek.
Nyissa meg a .htaccess fájlt. Előfordulhat, hogy a fájl megtalálásához engedélyeznie kell a „rejtett fájlok megjelenítése” funkciót a fájlkezelőben vagy az FTP-kliensben.
Illessze be ezt a kódot a fájlba .htaccess:
# Blokkolja a WordPress xmlrpc.php kéréseket
Végső gondolatok
Összességében az XML-RPC szilárd megoldást jelentett néhány olyan problémára, amely a WordPress-webhelyen történő távoli közzétételből fakadt. Ezzel egy időben azonban megjelentek néhány biztonsági rés, amelyek meglehetősen veszélyesnek bizonyultak egyes WordPress webhelytulajdonosok számára.
Webhelye biztonságának megőrzése érdekében ajánlatos teljesen letiltani az xmlrpc.php fájlt, hacsak nincs szüksége a távoli közzététel és a Jetpack beépülő modul által megkövetelt néhány szolgáltatásra. Ezután olyan megoldási beépülő modulokat használhat, amelyek lehetővé teszik ezen szolgáltatások használatát a biztonsági rések befoltozása közben.
Idővel arra számíthatunk, hogy az XML-RPC funkciók integrálódnak egy új WordPress API-ba, amely a biztonság feláldozása nélkül támogatja a távoli hozzáférést.
Letiltotta az XML-RPC-hez való hozzáférést bővítményen keresztül vagy manuálisan? Vagy azért voltak biztonsági problémák, mert korábban aktív volt? Ossza meg tapasztalatait az alábbi megjegyzésekben.
