La meilleure façon d'éliminer xmlrpc.php?

25

Quelle est la meilleure façon d'éliminer le fichier xmlrpc.php de WordPress lorsque vous n'en avez pas besoin?

prosti
la source

Réponses:

26

Depuis WordPress 3.5, cette option ( XML-RPC) est activée par défaut et la possibilité de la désactiver à partir de WordPress a dashboarddisparu.

Ajoutez cet extrait de code à utiliser dans functions.php:

// Disable use XML-RPC
add_filter( 'xmlrpc_enabled', '__return_false' );

// Disable X-Pingback to header
add_filter( 'wp_headers', 'disable_x_pingback' );
function disable_x_pingback( $headers ) {
    unset( $headers['X-Pingback'] );

return $headers;
}

Bien qu'il fasse ce qu'il dit, il peut devenir intensif lorsqu'un site est attaqué en le frappant.
Vous pouvez mieux utiliser l'extrait de code suivant dans votre .htaccessfichier.

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

Ou utilisez-le pour désactiver l'accès au xmlrpc.phpfichier à partir du bloc serveur NGINX.

# nginx block xmlrpc.php requests
location /xmlrpc.php {
    deny all;
}

Sachez que la désactivation peut également avoir un impact sur les connexions via mobile. Si je suis correct, l'application mobile WordPress en a besoin.
Voir Codex pour plus d'informations sur l'utilisation de XML-RPC.

  • Veuillez toujours faire une sauvegarde du ou des fichiers avant de les modifier / ajouter.


Modifier / mettre à jour

@Prosti, -Tu as absolument raison- sur les options qui RESTful APIs'offriront pour WordPress!

J'ai oublié de mentionner ceci. Il aurait déjà dû être intégré au core ( WordPress version 4.1 ) ce qui n'était pas possible à l'époque. Mais comme il semble, sera au cœur de WordPress 4.5.

L'alternative pour le moment est ce plugin: WordPress REST API (Version 2)
Vous pouvez l'utiliser jusqu'à ce qu'il Restful APIsoit également au cœur de WordPress.
Date cible de sortie de WordPress 4.5. (12 avril 2016 (+ 3w))

Pour ceux qui sont intéressés RESTful, sur Stackoverflow est un très joli wiki communautaire.

Charles
la source
2
Si je suis correct, l'application mobile WordPress en a besoin - cela ne sera probablement plus nécessaire à l'avenir une fois que nous aurons effectué la transition vers l'API RESTful WordPress (WordPress 4.5)
prosti
2
Pour ceux qui obtiennent toujours un en- X-Pingbacktête pour une seule publication / page. Nous devons utiliser un autre filtre pour le supprimer complètement: add_filter('pings_open', '__return_false', PHP_INT_MAX);.
MinhTri
1
Ajouter des choses comme ça functions.phpperdra tout effet lors du changement de thème. function.phpest uniquement à des fins de conception, utilisez un plugin!
David
@David, bien sûr mais ppl alors mieux utiliser le dossier mu-plugins, au lieu de faire pour un tel plugin. Lorsque ppl a besoin / utilise une fonction comme celle-ci, il l'a pour une raison et ne veut pas que quiconque (pas même un administrateur) ait la possibilité de désactiver un plugin.
Charles
Il semble qu'il y ait un signe égal ( =) manquant dans la première ligne du code de conf nginx. Cela a fonctionné pour moi: location = /xmlrpc.php {
Dave
6

Lorsque vous avez la possibilité de le bloquer via la configuration de votre serveur Web, les suggestions de @Charles sont bonnes.

Si vous ne pouvez le désactiver qu'en utilisant php, le xmlrpc_enabledfiltre n'est pas la bonne façon. Comme documenté ici: https://developer.wordpress.org/reference/hooks/xmlrpc_enabled/ il désactive uniquement les méthodes xml rpc qui nécessitent une authentification.

Utilisez plutôt le xmlrpc_methodsfiltre pour désactiver toutes les méthodes:

<?php
// Disable all xml-rpc endpoints
add_filter('xmlrpc_methods', function () {
    return [];
}, PHP_INT_MAX);

Vous pouvez tester si cela fonctionne en envoyant une requête POST à ​​xmlrpc.php avec le contenu suivant:

<methodCall>
    <methodName>system.listMethods</methodName>
</methodCall>

Si le filtre fonctionne, il ne devrait rester que 3 méthodes:

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
    <params>
        <param>
            <value>
                <array>
                    <data>
                        <value>
                            <string>system.multicall</string>
                        </value>
                        <value>
                            <string>system.listMethods</string>
                        </value>
                        <value>
                            <string>system.getCapabilities</string>
                        </value>
                    </data>
                </array>
            </value>
        </param>
    </params>
</methodResponse>

vous pouvez le tester rapidement avec curl:

curl -X POST \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/xml' \
  -d '<methodCall><methodName>system.listMethods</methodName></methodCall>' \
  https://your-wordpress-site.com/xmlrpc.php
tweber
la source
5

Nous utilisons le fichier htaccess pour le protéger des pirates.

# BEGIN protect xmlrpc.php
<files xmlrpc.php>
order allow,deny
deny from all
</files>
# END protect xmlrpc.php
Jorin van Vilsteren
la source
4

La meilleure chose à faire est de désactiver les xmlrpc.phpfonctions avec un plugin plutôt que de supprimer ou de désactiver le fichier lui-même. Le fichier lui-même sera remplacé sur les mises à jour principales de WordPress, tandis qu'un plugin le gardera désactivé après les mises à jour principales et si vous changez de thème.

Voir https://wordpress.org/plugins/search.php?q=disable+xml-rpc pour différents plugins. Ils ont tous des différences mineures.

Ces plugins font la même chose qu'une fonction ajoutée au functions.phpfichier du thème ou en ajoutant une order,allow denyrègle à .htaccess (comme indiqué dans d'autres réponses), à la différence qu'un plugin ou une fonction désactive les appels à xmlrpc.phpvia PHP, et la règle dans .htaccess fonctionne en tirant parti de mod_rewrite dans le serveur Web (c'est-à-dire Apache ou Nginx). Il n'y a pas de différence de performance appréciable entre l'utilisation de PHP et de mod_rewrite sur un serveur moderne.

Markratledge
la source
3

Pour l'extrême minorité qui héberge WordPress dans IIS, vous pouvez utiliser le module IIS URL Rewrite pour effectuer des restrictions similaires à htaccess. L'exemple ci-dessous suppose que la véritable IP du client arrive dans l'en-tête X-Forwarded-For, l'IP de liste blanche connue est 55.55.555.555 et que vous souhaitez répondre avec un HTTP 404 aux adresses IP non-liste blanche.

<rule name="wordpress-restrictions" enabled="true" stopProcessing="true">
    <match url="(^xmlrpc.php)|(^wp-admin)|(^wp-login.php)" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{HTTP_X_FORWARDED_FOR}" pattern="(^55\.55\.555\.555$)" negate="true" />
    </conditions>
    <action type="CustomResponse" statusCode="404" subStatusCode="44" statusReason="File or directory not found" statusDescription="The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable." />
</rule>
Laiton
la source
0

Dans un premier temps, vous pouvez mettre le code add_filter('xmlrpc_enabled', '__return_false');dans le fichier functions.phpou le plugin spécifique au site. Il est clairement recommandé de le mettre dans un site spécifique plutôt que de modifier le fichier functions.php.

et d'autres moyens d'éliminer xmlrpc

yaser hamzeloy
la source
0

J'ai récemment installé Wordfence qui, à partir de la version 6.3.12, a la possibilité de bloquer l'accès direct à n'importe quel emplacement. Mettre /xmlrpc.php sur la page Options dans la liste des adresses IP interdites "Bloquer immédiatement les adresses IP qui accèdent à ces URL" affiche désormais une tentative de blocage toutes les 15 minutes environ.

Cela a également l'avantage de pouvoir bloquer une URL pour échapper à ces bots embêtants qui reviennent avec une adresse IP différente à maintes reprises.

Je ne sais pas s'il permet l'utilisation de xmlrpc.php par les applications pour des opérations valides.

J'ai eu quelques problèmes avec lui produisant des erreurs 504 Timeout et 502 Bad Gateway sur le serveur au début, mais il semble s'être résolu.

Très impressionné par le résultat jusqu'à présent et il a produit un profil de nettoyage précieux après que le site a été piraté avant d'installer Wordfence et malgré toujours la dernière version de WordPress et des plugins.

Wordfence https://www.wordfence.com/

Steve
la source
Ajout /xmlrpc.phpà une règle de sécurité interdisant les IP qui y accèdent, il semble que cela pourrait bloquer le trafic légitime. Si un site avec des liens activés par pingback vers votre site, ce site enverra une demande à cette URL et sera immédiatement bloqué ... semble que cela pourrait causer des problèmes.
adam-asdf
0

j'utilise pour nginx ce petit code et cela fonctionne à 100%

location ~* (/wp-content/.*\.php|/wp-includes/.*\.php|/xmlrpc\.php$|/(?:uploads|files)/.*\.php$) {
deny all;
access_log off;
log_not_found off;
return 444;
}
Manuel K
la source