Einführung in XML-RPC. Programmierwettbewerbe Was in den Serverprotokollen sichtbar ist
Sein Beitrag zeigt auch, wie man die Browser-Authentifizierung durchführt, wie folgt:
$request = xmlrpc_encode_request ("methodName" , array("methodParam" ));
$auth = base64_encode ($username . :: . $password );
$header = (version_compare(phpversion(), "5.2.8"))
? array("Content-Type: text/xml" , "Autorisierung: Basic $auth " )
: "Content-Type: text/xml\r\nAutorisierung: Basic$auth " ; //
$context = stream_context_create (array("http" => array(
"Methode" => "POST" ,
"header" => $header ,
"content" => $request
)));
$webservice = „http://www.example.com/rpc“;
$file = file_get_contents($webservice, false, $context);
$response = xmlrpc_decode ($file);
if (xmlrpc_is_fault($response)) (
return „xmlrpc: $response [ FaultString ] ($response [ FaultCode ] )“;
) anders (
return $response ;
}
?>
1 – ANMERKUNG DES HERAUSGEBERS: DIES IST EIN FIX VON „SandersWang dt php at gmail dot com“
Vor 16 Jahren
Binäre Zeichenfolgen (festgelegt mit xmlrpc_set_type) gehen in a
So albern es auch sein mag, es verursacht echte Probleme für einige XML-RPC-Server, wie zum Beispiel http://jakarta.apache.org/xmlrpc/ (geb. Helma). Diese Entitäten mit so etwas wie entfernen
$req = preg_replace("/ /", "", xmlrpc_encode_request("my.method", $args));
umgeht das Problem.
Vor 11 Jahren
Es ist zu beachten, dass die Codierung scheinbar nichts codiert, sondern lediglich angibt, was in den XML-Header geht.
Wir hatten Probleme damit, dass doppelt codierte UTF-Strings in der Datenbank gespeichert wurden, als wir diese Funktion verwendeten, sie an ein Apache-XML-RPC-Servlet sendeten und in der MySQL-Datenbank speicherten. Es wurde gelöst, indem „escaping“ nur auf „markup“ und „encoding“ auf „UTF-8“ gesetzt wurde (vergessen Sie nicht, auch „utf-8“ in xmlrpc_decode festzulegen).
Es scheint, dass UTF-8-codierte Zeichenfolgen mit ihren Bytes als Entitäten und nicht mit ihren Zeichen als Entitäten maskiert werden.
Vor 9 Jahren
Haben Sie schon einmal versucht, ein Array wie das folgende mit xmlrpc zu übertragen?
$var1=array(7=>14,9=>18);
Das Ausgabearray sieht ganz anders aus! Es wird so aussehen:
$var2=array(14,18);
Die einzige Lösung, die ich gefunden habe, besteht darin, dem Index ein Leerzeichen voranzustellen:
$var3=array(" 7"=>14," 9"=>18);
Mit dieser Methode erhalten Sie das richtige Ergebnis. ($var1)
Vor 16 Jahren
Diese Funktion sollte von einem XML-RPC-Client verwendet werden, um eine XML-Nutzlast für eine XML-RPC-Anfrage zu erstellen;
$params = "system.methodSignature" ;
$method = "system.methodHelp" ;
$request = xmlrpc_encode_request ($method, $params);
echo ($request);
?>
Produziert;
Das zweite Argument erkennt den Typ der Variablen und generiert die richtige XML-RPC-Struktur. Weitere Informationen finden Sie unter xmlrpc_encode().
vor 12 Jahren
Einfacher OO-Client mit Funktion Overload:
Die PHP-Methode test_helloworld wird in die xmlrpc-Methode test.helloworld übersetzt.
Klasse RpcClient(
private $_methods;
privater $_context;
privat $_url;
Funktion __construct ($url, $user, $passwd) (
$auth = base64_encode(sprintf("%s:%s", $user,$passwd));
$this->_context = stream_context_create(array(
"http" => array(
„Methode“ => „POST“,
"header" => "Content-Type: text/xml\r\n".
„Autorisierung: Basic $auth“,
)
));
$this->_url = $url;
$this->registerMethod("Test_HelloWorld");
Funktion __call($methodName, $params) (
if (array_key_exists($methodName,$this->_methods)) (
// auf Berufung auf RPC
$m = str_replace("_", ".", $methodName);
$r = xmlrpc_encode_request($m, $params,array("verbosity"=>"newlines_only"));
$c = $this->_context;
stream_context_set_option($c,"http","content",$r);
$f = file_get_contents($this->_url,false,$c);
$resp = xmlrpc_decode($f);
return $resp;
) anders (
// on appelle la fonction de l"objet
call_user_method_array($methodName, $this,$params);
}
}
Private Funktion registerMethod ($method) (
$this->_methods[$method] = true;
}
Einführung in XML-RPC
Im Internet gibt es viele verschiedene Ressourcen, die Benutzern bestimmte Informationen bereitstellen. Dabei handelt es sich nicht um gewöhnliche statische Seiten, sondern beispielsweise um aus einer Datenbank oder Archiven abgerufene Daten. Dabei kann es sich um ein Archiv mit Finanzdaten (Wechselkurse, Wertpapierkursdaten), Wetterdaten oder umfangreicheren Informationen – Nachrichten, Artikeln, Nachrichten aus Foren – handeln. Solche Informationen können dem Seitenbesucher beispielsweise über ein Formular als Antwort auf eine Anfrage präsentiert werden oder sie können jedes Mal dynamisch generiert werden. Die Schwierigkeit besteht jedoch darin, dass solche Informationen häufig nicht so sehr vom Endbenutzer – einer Person – benötigt werden, sondern von anderen Systemen und Programmen, die diese Daten für ihre Berechnungen oder andere Zwecke verwenden.
Reales Beispiel: eine Seite einer Bank-Website, auf der Währungskurse angezeigt werden. Wenn Sie als normaler Benutzer über einen Browser auf die Seite zugreifen, sehen Sie das gesamte Seitendesign, Banner, Menüs und andere Informationen, die den wahren Zweck der Suche „umrahmen“ – Währungskurse. Wenn Sie diese Angebote in Ihren Online-Shop eingeben müssen, bleibt Ihnen nichts anderes übrig, als die erforderlichen Daten manuell auszuwählen und über die Zwischenablage auf Ihre Website zu übertragen. Und Sie müssen dies jeden Tag tun. Gibt es wirklich keinen Ausweg?
Wenn Sie das Problem direkt lösen, ergibt sich sofort eine Lösung: Ein Programm (Skript auf einer Website), das Daten benötigt, empfängt als „normaler Benutzer“ eine Seite vom Server, analysiert (parst) den resultierenden HTML-Code und extrahiert den notwendige Informationen daraus. Dies kann entweder mit einem regulären regulären Ausdruck oder mit einem beliebigen HTML-Parser erfolgen. Die Schwierigkeit des Ansatzes liegt in seiner Ineffektivität. Um zunächst einen kleinen Teil der Daten zu erhalten (Daten zu Währungen umfassen buchstäblich ein Dutzend oder zwei Zeichen), müssen Sie die gesamte Seite empfangen, die mindestens mehrere zehn Kilobyte groß ist. Zweitens muss unser Parsing-Algorithmus bei jeder Änderung des Seitencodes, beispielsweise einer Änderung des Designs oder etwas anderem, überarbeitet werden. Und das wird einiges an Ressourcen erfordern.
Daher kamen die Entwickler zu einer Entscheidung: Es ist notwendig, eine Art universellen Mechanismus zu entwickeln, der einen transparenten (auf der Ebene des Protokolls und des Übertragungsmediums) und einfachen Datenaustausch zwischen Programmen ermöglicht, die sich überall befinden und in jeder Sprache geschrieben werden können und läuft unter jedem Betriebssystem. Systeme und auf jeder Hardwareplattform. Ein solcher Mechanismus wird heute mit den lauten Begriffen „Webservices“, „SOAP“ und „serviceorientierte Architektur“ bezeichnet. Für den Datenaustausch werden offene und bewährte Standards verwendet – für die Nachrichtenübermittlung wird das HTTP-Protokoll verwendet (obwohl auch andere Protokolle verwendet werden können – zum Beispiel SMTP). Die Daten selbst (in unserem Beispiel Wechselkurse) werden plattformübergreifend verpackt – in Form von XML-Dokumenten – übertragen. Zu diesem Zweck wurde ein spezieller Standard erfunden – SOAP.
Ja, jetzt sind Webdienste, SOAP und XML in aller Munde, sie beginnen aktiv implementiert zu werden und große Unternehmen wie IBM und Microsoft bringen neue Produkte auf den Markt, die die vollständige Implementierung von Webdiensten unterstützen sollen.
Aber! Für unser Beispiel mit Wechselkursen, die von der Website der Bank an die Online-Shop-Engine übermittelt werden müssen, wird eine solche Lösung sehr schwierig sein. Schließlich umfasst allein die Beschreibung des SOAP-Standards obszöne anderthalbtausend Seiten, und das ist noch nicht alles. Für den praktischen Einsatz müssen Sie außerdem lernen, mit Bibliotheken und Erweiterungen von Drittanbietern zu arbeiten (erst ab PHP 5.0 ist eine Bibliothek für die Arbeit mit SOAP enthalten) und Hunderte und Tausende Zeilen eigenen Codes zu schreiben. Und das alles, um ein paar Buchstaben und Zahlen zu bekommen, ist natürlich sehr umständlich und irrational.
Daher gibt es einen weiteren, man könnte sagen, alternativen Standard für den Informationsaustausch – XML-RPC. Es wurde unter Beteiligung von Microsoft von UserLand Software Inc. entwickelt und ist für die einheitliche Datenübertragung zwischen Anwendungen über das Internet konzipiert. Es kann SOAP ersetzen, wenn einfache Dienste erstellt werden, bei denen nicht alle „Unternehmensfunktionen“ echter Webdienste benötigt werden.
Was bedeutet die Abkürzung XML-RPC? RPC steht für Remote Procedure Call. Dies bedeutet, dass eine Anwendung (sei es ein Skript auf dem Server oder eine reguläre Anwendung auf dem Client-Computer) transparent eine Methode verwenden kann, die physisch auf einem anderen Computer implementiert und ausgeführt wird. Dabei wird XML verwendet, um ein universelles Format zur Beschreibung der übertragenen Daten bereitzustellen. Als Transportmittel wird das HTTP-Protokoll zur Übertragung von Nachrichten verwendet, das einen nahtlosen Datenaustausch über alle Netzwerkgeräte – Router, Firewalls, Proxyserver – ermöglicht.
Für die Nutzung benötigen Sie also: einen XML-RPC-Server, der eine oder mehrere Methoden bereitstellt, einen XML-RPC-Client, der eine korrekte Anfrage generieren und die Serverantwort verarbeiten kann und außerdem die für einen erfolgreichen Betrieb erforderlichen Serverparameter kennt – Adresse, Methodenname und übergebene Parameter.
Вся работа с XML-RPC происходит в режиме "запрос-ответ", в этом и есть одно из отличий технологии от стандарта SOAP, где есть и понятия транзакций, и возможность делать отложенные вызовы (когда сервер сохраняет запрос и отвечает на него в определенное время in der Zukunft). Diese zusätzlichen Funktionen sind für leistungsstarke Unternehmensdienste nützlicher, sie erschweren die Entwicklung und den Support von Servern erheblich und stellen zusätzliche Anforderungen an Entwickler von Client-Lösungen.
Das Verfahren zum Arbeiten mit XML-RPC beginnt mit der Erstellung einer Anfrage. Eine typische Anfrage sieht so aus:
POST /RPC2 HTTP/1.0
Benutzeragent: eshop-test/1.1.1 (FreeBSD)
Host: server.localnet.com
Inhaltstyp: Text/XML
Inhaltslänge: 172
Die ersten Zeilen bilden den Standard-HTTP-POST-Anfrageheader. Zu den erforderlichen Parametern gehören Host, Datentyp (MIME-Typ), der Text/XML sein muss, und Nachrichtenlänge. Der Standard legt außerdem fest, dass das Feld „User-Agent“ ausgefüllt werden muss, aber einen beliebigen Wert enthalten kann.
Als nächstes kommt der übliche Header des XML-Dokuments. Das Wurzelelement der Anfrage ist
Linie
Als nächstes werden die übertragenen Parameter eingestellt. Hierzu dient dieser Abschnitt.
Der Beschreibung aller Parameter folgen abschließende Tags. Die Anfrage und Antwort in XML-RPC sind reguläre XML-Dokumente, daher müssen alle Tags geschlossen sein. Allerdings gibt es in XML-RPC keine einzelnen Tags, obwohl sie im XML-Standard vorhanden sind.
Schauen wir uns nun die Antwort des Servers an. Der HTTP-Antwortheader ist normal; wenn die Anfrage erfolgreich verarbeitet wurde, gibt der Server eine HTTP/1.1 200 OK-Antwort zurück. Genau wie bei der Anfrage müssen Sie den MIME-Typ, die Nachrichtenlänge und das Antwortgenerierungsdatum korrekt angeben.
Der Antworttext selbst lautet wie folgt:
Jetzt anstelle des Root-Tags
Wenn bei der Bearbeitung Ihrer Anfrage ein Fehler aufgetreten ist, statt Die Antwort enthält das Element
Werfen wir nun einen kurzen Blick auf die Datentypen in XML-RPC. Insgesamt gibt es 9 Datentypen – sieben einfache Typen und 2 komplexe. Jeder Typ wird durch ein eigenes Tag oder einen Satz von Tags (bei komplexen Typen) beschrieben.
Einfache Typen:
Ganze Zahlen- Etikett
Boolescher Typ- Etikett
ASCII-Zeichenfolge- beschrieben durch Tag
Gleitkommazahlen- Etikett
Datum (und Uhrzeit- beschrieben durch Tag
Der letzte einfache Typ ist Base64-codierte Zeichenfolge, was durch das Tag beschrieben wird
Komplexe Typen werden durch Strukturen und Arrays dargestellt. Die Struktur wird durch das Wurzelelement bestimmt
Arrays haben keinen Namen und werden durch das Tag beschrieben
Natürlich wird jemand sagen, dass eine solche Liste von Datentypen sehr dürftig ist und „keine Erweiterung zulässt“. Ja, wenn Sie komplexe Objekte oder große Datenmengen übertragen müssen, ist es besser, SOAP zu verwenden. Und für kleine, anspruchslose Anwendungen ist XML-RPC durchaus geeignet; außerdem erweisen sich seine Fähigkeiten sehr oft als zu groß! Angesichts der einfachen Bereitstellung, einer sehr großen Anzahl von Bibliotheken für nahezu jede Sprache und Plattform sowie der breiten Unterstützung in PHP hat XML-RPC oft einfach keine Konkurrenz. Obwohl es nicht sofort als Universallösung empfohlen werden kann, muss es im Einzelfall entsprechend den Umständen entschieden werden.
Die XML-RPC-Technologie wird im WordPress-System für verschiedene nette Funktionen wie Pingbacks, Trackbacks, Remote-Site-Verwaltung ohne Anmeldung im Admin-Panel usw. verwendet. Leider können Angreifer damit DDoS-Angriffe auf Websites durchführen. Das heißt, Sie erstellen schöne, interessante WP-Projekte für sich selbst oder auf Bestellung und können gleichzeitig, ohne etwas zu ahnen, Teil eines DDoS-Botnetzes sein. Indem sie Zehntausende und Hunderttausende Websites miteinander verbinden, starten Kriminelle einen mächtigen Angriff auf ihr Opfer. Allerdings leidet gleichzeitig auch Ihre Website, weil... Die Last geht an das Hosting, wo sie sich befindet.
Hinweise auf eine solche fehlerhafte Aktivität können in den Serverprotokollen (access.log in nginx) enthalten sein, die die folgenden Zeilen enthalten:
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
Doch zurück zur XML-RPC-Schwachstelle. Optisch macht es sich dadurch bemerkbar, dass Websites auf Ihrem Server langsam geöffnet werden oder diese überhaupt nicht geladen werden können (Fehler 502 Bad Gateway). Der technische Support meines FASTVPS-Hosts bestätigte meine Vermutungen und empfahl:
- Aktualisieren Sie WordPress zusammen mit den Plugins auf die neueste Version. Wenn Sie dem folgen, haben Sie im Allgemeinen möglicherweise gelesen, dass die neueste Version 4.2.3 installiert werden muss. aufgrund von Sicherheitskritik (genau wie bei früheren Versionen). Kurz gesagt, es ist gut, ein Update durchzuführen.
- Installieren Sie das Plugin „Disable XML-RPC Pingback“.
Deaktivieren von XML-RPC in WordPress
Früher schien es mir, dass die Option zum Aktivieren/Deaktivieren von XML-RPC irgendwo in den Systemeinstellungen war, aber jetzt kann ich sie dort nicht finden. Der einfachste Weg, es loszuwerden, ist daher die Verwendung des entsprechenden Plugins.
Suchen Sie nach Disable XML-RPC Pingback und laden Sie es herunter oder installieren Sie es direkt über das Systemadministrationsfenster. Sie müssen nichts weiter konfigurieren, das Modul beginnt sofort zu arbeiten. Es entfernt die Methoden pingback.ping und pingback.extensions.getPingbacks aus der XML-RPC-Schnittstelle. Darüber hinaus wird X-Pingback aus HTTP-Headern entfernt.
In einem der Blogs habe ich ein paar weitere Optionen zum Entfernen der XML-RPC-Deaktivierung gefunden.
1. Deaktivieren Sie XML-RPC in der Vorlage.
Fügen Sie dazu die folgende Zeile zur Datei „functions.php“ des Themes hinzu:
Ich persönlich habe die letzten beiden Methoden nicht verwendet, weil... Ich habe das Plugin „Disable XML-RPC Pingback“ angeschlossen – ich denke, das wird ausreichen. Nur für diejenigen, die unnötige Installationen nicht mögen, habe ich alternative Optionen vorgeschlagen.
Ab Samstagmittag kam es auf meinem Server, auf dem etwa 25 Wordpress-Seiten gehostet werden, zu starken Verlangsamungen. Da es mir gelang, die vorherigen Angriffe ( , ) unbemerkt zu überstehen, verstand ich nicht sofort, was geschah.
Als ich es herausfand, stellte sich heraus, dass Passwörter brutal erzwungen wurden + viele Anfragen an XMLRPC.
Infolgedessen gelang es uns, alles abzuschneiden, wenn auch nicht sofort. Hier sind drei einfache Tricks, wie Sie dies vermeiden können.
Diese Techniken sind höchstwahrscheinlich jedem bekannt, aber ich bin auf ein paar Fehler gestoßen, die ich in den Beschreibungen nicht gefunden habe – vielleicht spart das jemandem Zeit.
1. Stoppen Sie die Suche, installieren Sie das Plugin „Limit Login Attempts“ – installieren Sie es, da andere Schutzmaßnahmen den Server stark verlangsamen. Wenn Sie beispielsweise das Plugin „Login Security Solution“ verwenden, ist der Server nach einer halben Stunde ausgefallen, das Plugin belastet die Datenbank stark .
Stellen Sie sicher, dass in den Einstellungen das Kontrollkästchen „Für Proxy“ aktiviert ist. Andernfalls wird die IP Ihres Servers für alle ermittelt und alle automatisch blockiert.
UPDATE, danke, Details finden Sie unten in den Kommentaren – aktivieren Sie das Kontrollkästchen „Für Proxy“ nur, wenn die Definition nicht funktioniert, wenn „Direkte Verbindung“ aktiviert ist
2. Disable XML-RPC – das Disable XML-RPC-Plugin (es ist einfach zu aktivieren und das war’s).
3. Schließen Sie wp-login.php – wenn Sie über IP auf die Site zugreifen, funktioniert das Plugin nicht und die Picker stürzen die Site weiterhin ab. Um dies zu vermeiden, fügen Sie zu .htaccess Folgendes hinzu:
Wir kopieren die wp-login-Datei, benennen sie in einen beliebigen seltsamen Namen um, zum Beispiel poletnormalny.php, und verwenden innerhalb der Datei die Autokorrektur, um alle wp-login.php-Inschriften in poletnormalny.php zu ändern.
Jetzt können Sie nur noch mit Ihrer Datei auf das Admin-Panel zugreifen.
Nach diesen drei einfachen Schritten begannen die Standorte wieder zu fliegen und es kam Frieden.
Nun, plötzlich ist es interessant
Eine der Möglichkeiten besteht darin, festzustellen, ob Sie angegriffen werden. Dies ist in den Nginx-Protokollen zu sehen (hier ist beispielsweise der Pfad für die Debian-Datei /var/log/nginx access.log).WordPress verfügt seit jeher über ein integriertes Tool für den Fernzugriff auf Ihre Website. Tatsächlich müssen Sie manchmal auf Ihre Website zugreifen, Ihr Computer ist jedoch weit von Ihnen entfernt. Die Lösung war lange Zeit eine Datei namens xmlrpc.php. In den letzten Jahren ist diese Datei jedoch eher zu einem Problem als zu einer Lösung geworden.
Im Folgenden werfen wir einen genaueren Blick auf xmlrpc.php und warum es erstellt wurde. Wir befassen uns auch mit den häufigsten Sicherheitsproblemen, die dadurch verursacht werden können, und wie Sie diese für Ihre WordPress-Site beheben können.
XML-RPC ist eine WordPress-Funktion, die die Datenübertragung ermöglicht, wobei HTTP als Transport und XML für die Kodierung dient. Da WordPress kein geschlossenes System ist und häufig mit anderen Systemen kommuniziert, wurden für dieses Problem Lösungen gefunden.
Angenommen, Sie möchten von Ihrem Mobiltelefon aus auf Ihrer Website posten. Sie müssen den von xmlrpc.php bereitgestellten Fernzugriff verwenden.
Die Hauptfunktionalität von xmlrpc.php ist die Möglichkeit, von einem Smartphone aus eine Verbindung zur Site herzustellen, die Implementierung von Trackbacks und Linkbacks von anderen Sites sowie einige Funktionen im Zusammenhang mit dem Jetpack-Plugin.
Warum wurde Xmlrpc.php erstellt und wie wurde es verwendet?
Die Implementierung von XML-RPC reicht bis in die Anfänge von WordPress zurück und sogar noch bevor WordPress zu WordPress wurde.
In den Anfängen des Internets waren die Verbindungen sehr langsam und der Prozess der Aufzeichnung und Veröffentlichung im Internet war viel schwieriger und zeitaufwändiger. Anstatt Änderungen direkt über den Browser vorzunehmen, machten die meisten sie offline und kopierten und fügten ihre Inhalte dann online ein. Und dieser Prozess war alles andere als ideal.
Die damalige Lösung bestand darin, einen Offline-Blogging-Client zu erstellen, mit dem Sie Ihre Inhalte verfassen, sich dann mit Ihrem Blog verbinden und ihn veröffentlichen konnten. Diese Verbindung wurde über XML-RPC hergestellt. Mit der XML-RPC-Kernfunktionalität ermöglichten frühe Anwendungen, die diese Verbindungen nutzten, Benutzern den Zugriff auf ihre WordPress-Sites von anderen Geräten aus.
XML-RPC heute
Im Jahr 2008 wurde mit Version 2.6 von WordPress eine Option zum Aktivieren oder Deaktivieren von XML-RPC eingeführt. Mit der Veröffentlichung der WordPress iPhone-App war die XML-RPC-Unterstützung jedoch standardmäßig aktiviert und es gab keine Möglichkeit, sie zu deaktivieren. Das ist bis heute so geblieben.
Natürlich hat die Funktionalität, die diese Datei bietet, im Laufe der Zeit erheblich abgenommen und die Dateigröße ist von 83 KB auf 3 KB gesunken, sie spielt nicht mehr die gleiche Rolle wie zuvor.
XML-RPC-Eigenschaften
Mit der neuen WordPress Application Programming Interface (API) können wir davon ausgehen, dass XML-RPC vollständig deaktiviert wird. Heute befindet sich diese neue API noch in der Testphase und kann nur über ein spezielles Plugin aktiviert werden.
Obwohl Sie davon ausgehen können, dass die API in Zukunft direkt in den WordPress-Kern integriert wird, wird xmlrpc.php vollständig überflüssig.
Die neue API ist nicht perfekt, bietet aber im Gegensatz zu xmlrpc.php gute und zuverlässige Sicherheit.
Warum Xmlrpc.php deaktivieren?
Das größte Problem bei XML-RPC ist die Sicherheit. Das Problem hängt nicht direkt mit XML-RPC zusammen, kann aber genutzt werden, um einen Angriff auf Ihre Website zu ermöglichen.
Natürlich können Sie sich mit einem sehr starken Passwort und WordPress-Sicherheits-Plugins schützen. Der beste Schutzmodus besteht jedoch darin, ihn einfach auszuschalten.
Es gibt zwei Hauptschwächen von XML-RPC, die in der Vergangenheit ausgenutzt wurden.
Die erste Variante nutzt Brute-Force-Angriffe, um Zugriff auf Ihre Website zu erhalten. Der Angreifer wird versuchen, sich über xmlrpc.php Zugriff auf Ihre Website zu verschaffen, indem er verschiedene Kombinationen von Benutzernamen und Passwörtern ausprobiert. Sie können mit einem Befehl effektiv Hunderte verschiedener Passwörter testen. Dadurch können sie Sicherheitstools umgehen, die normalerweise Brute-Force-Angriffe erkennen und blockieren würden.
Die zweite besteht darin, die Website durch einen DDoS-Angriff offline zu schalten. Hacker nutzen die umgekehrte Benachrichtigung in WordPress, um sie gleichzeitig an Tausende von Websites zu senden. Diese xmlrpc.php-Funktionalität stellt Hackern eine nahezu unbegrenzte Anzahl von IP-Adressen zur Verfügung, um einen DDoS-Angriff zu verbreiten.
Um zu überprüfen, ob XML-RPC auf Ihrer Site funktioniert, können Sie es mit einem Tool namens XML-RPC Validator ausführen. Führen Sie Ihre Site mit dem Tool aus. Wenn Sie eine Fehlermeldung erhalten, bedeutet dies, dass Sie keine XML-RPC-Unterstützung haben.
Wenn Sie eine Erfolgsmeldung erhalten, können Sie xmlrpc.php mit einem der beiden folgenden Ansätze stoppen.
Methode 1: Deaktivieren Sie Xmlrpc.php mithilfe eines Plugins
Das Deaktivieren von XML-RPC auf Ihrer WordPress-Site ist unglaublich einfach.
Gehen Sie zum Abschnitt Plugins › Neu hinzufügen in Ihrer WordPress-Administratorkonsole. Finden Sie ein Plugin Deaktivieren Sie XML-RPC und installieren Sie es, es sieht wie im Bild unten aus:
Aktivieren Sie das Plugin und fertig. Dieses Plugin fügt automatisch den notwendigen Code zum Deaktivieren von XML-RPC ein.
Bedenken Sie jedoch, dass installierte Plugins möglicherweise Teile von XML-RPC verwenden und die anschließende Deaktivierung zu einem Konflikt zwischen den Plugins oder ihren einzelnen Teilen führen und sie aus dem Arbeitsmodus bringen kann.
Wenn Sie nur einzelne XML-RPC-Elemente deaktivieren möchten, aber die Funktion anderer Plugins und Funktionen zulassen möchten, dann suchen Sie nach Plugins wie diesen:
- Stoppen Sie den XML-RPC-Angriff. Dieses Plugin stoppt alle XML-RPC-Angriffe, ermöglicht aber die weitere Ausführung von Plugins wie Jetpack und anderen automatisierten Tools und Plugins, indem es ihnen Zugriff auf xmlrpc.php-Dateien gewährt.
- Steuern Sie die XML-RPC-Veröffentlichung. Dadurch behalten Sie die Kontrolle und können aus der Ferne veröffentlichen.
Methode 2: Deaktivieren Sie Xmlrpc.php manuell
Wenn Sie kein Plugin verwenden möchten und dies lieber manuell tun möchten, folgen Sie diesem Ansatz. Es stoppt alle eingehenden xmlrpc.php-Anfragen, bevor sie an WordPress weitergeleitet werden.
Öffnen Sie die .htaccess-Datei. Möglicherweise müssen Sie in Ihrem Dateimanager oder FTP-Client die Option „Versteckte Dateien anzeigen“ aktivieren, um diese Datei zu finden.
Fügen Sie diesen Code in die Datei ein .htaccess:
# WordPress xmlrpc.php-Anfragen blockieren
Abschließende Gedanken
Insgesamt war XML-RPC eine solide Lösung für einige der Probleme, die mit der Remote-Veröffentlichung auf Ihrer WordPress-Site einhergingen. Allerdings traten gleichzeitig einige Sicherheitslücken auf, die sich für einige WordPress-Seitenbesitzer als ziemlich gefährlich herausstellten.
Um die Sicherheit Ihrer Website zu gewährleisten, wird empfohlen, xmlrpc.php vollständig zu deaktivieren, es sei denn, Sie benötigen einige der für Remote Publishing und das Jetpack-Plugin erforderlichen Funktionen. Sie können dann Workaround-Plugins verwenden, mit denen Sie diese Funktionen nutzen und gleichzeitig die Sicherheitslücken schließen können.
Mit der Zeit können wir davon ausgehen, dass die XML-RPC-Funktionalität in eine neue WordPress-API integriert wird, die den Fernzugriff ohne Einbußen bei der Sicherheit unterstützt.
Haben Sie den Zugriff auf XML-RPC über ein Plugin oder manuell blockiert? Oder gab es Sicherheitsprobleme, weil es zuvor aktiv war? Teilen Sie Ihre Erfahrungen in den Kommentaren unten.
