Una guía completa sobre xmlrpc.php en WordPress (qué es, riesgos de seguridad, cómo deshabilitarlo)

La especificación XML-RPC de WordPress se desarrolló para estandarizar la comunicación entre diferentes sistemas, lo que significa que las aplicaciones fuera de WordPress (como otras plataformas de blogs y clientes de escritorio) podrían interactuar con WordPress.

Esta especificación ha sido parte de WordPress desde sus inicios e hizo un trabajo muy útil. Sin él, WordPress habría estado en su propio silo, separado del resto de Internet.

Sin embargo, xmlrpc.php tiene sus desventajas. Puede introducir vulnerabilidades en su sitio de WordPress y ahora ha sido reemplazada por la API REST de WordPress, que hace un trabajo mucho mejor al abrir WordPress a otras aplicaciones.

En esta publicación, explicaremos qué es xmlrpc.php, por qué debería deshabilitarlo y lo ayudaremos a identificar si se está ejecutando en su sitio de WordPress.

¿Listo? ¡Vamos a sumergirnos!

¿Qué es xmlrpc.php?

XML-RPC es una especificación que permite la comunicación entre WordPress y otros sistemas. Hizo esto al estandarizar esas comunicaciones, utilizando HTTP como mecanismo de transporte y XML como mecanismo de codificación.

XML-RPC es anterior a WordPress: estaba presente en el software de blogs b2, que se bifurcó para crear WordPress en 2003. El código detrás del sistema se almacena en un archivo llamado xmlrpc.php , en el directorio raíz del sitio. Y todavía está allí, aunque XML-RPC está en gran medida desactualizado.

En las primeras versiones de WordPress, XML-RPC estaba desactivado de forma predeterminada. Pero desde la versión 3.5, se ha habilitado de forma predeterminada. La razón principal de esto fue permitir que la aplicación móvil de WordPress se comunique con su instalación de WordPress.

Si usó la aplicación móvil de WordPress antes de la versión 3.5, puede recordar que tuvo que habilitar XML-RPC en su sitio para que la aplicación pudiera publicar contenido. Esto se debió a que la aplicación no ejecutaba WordPress en sí misma; en cambio, era una aplicación separada que se comunicaba con su sitio de WordPress usando xmlrpc.php.

Pero no fue solo la aplicación móvil para la que se usó XML-RPC: también se usó para permitir la comunicación entre WordPress y otras plataformas de blogs, permitió trackbacks y pingbacks, y impulsó el complemento Jetpack que vincula un WordPress autohospedado. sitio a WordPress.com.

Pero dado que la API REST se integró en el núcleo de WordPress, el archivo xmlrpc.php ya no se usa para esta comunicación. En cambio, la API REST se usa para comunicarse con la aplicación móvil de WordPress, con clientes de escritorio, con otras plataformas de blogs, con WordPress.com (para el complemento Jetpack) y con otros sistemas y servicios. El rango de sistemas con los que la API REST puede interactuar es mucho mayor que el permitido por xmlrpc.php. Además, hay mucha más flexibilidad.

Debido a que la API REST reemplazó a XML-RPC, ahora debe deshabilitar xmlrpc.php en su sitio. Veamos por qué.

Por qué debería deshabilitar xmlrpc.php

La razón principal por la que debe deshabilitar xmlrpc.php en su sitio de WordPress es porque presenta vulnerabilidades de seguridad y puede ser el objetivo de los ataques.

Ahora que XML-RPC ya no es necesario para comunicarse fuera de WordPress, no hay razón para mantenerlo activo. Es por eso que es aconsejable deshabilitar su sitio para que sea más seguro.

Si xmlrpc.php es una responsabilidad de seguridad y ya no funciona, ¿por qué no se eliminó por completo de WordPress?

La razón de esto es que una de las características clave de WordPress siempre será la compatibilidad con versiones anteriores. Si está administrando bien su sitio, sabrá que mantener actualizado WordPress, así como cualquier complemento o tema, es esencial.

Pero siempre habrá propietarios de sitios web que no quieran o no puedan actualizar su versión de WordPress. Si están ejecutando una versión anterior a la API REST, aún necesitarán acceso a xmlrpc.php.

Veamos las vulnerabilidades específicas con más detalle.

Ataques DDoS a través de XML-RPC Pingbacks

Una de las funciones que habilitó xmlrpc.php fue pingbacks y trackbacks. Estas son las notificaciones que aparecen en los comentarios de su sitio cuando otro blog o sitio enlaza con su contenido.

La especificación XML-RPC fue lo que hizo posible esta comunicación, pero fue reemplazada por la API REST (como ya vimos).

Si XML-RPC está habilitado en su sitio, un pirata informático podría montar un ataque DDoS en su sitio al explotar xmlrpc.php para enviar una gran cantidad de pingbacks a su sitio en poco tiempo. Esto podría sobrecargar su servidor y poner su sitio fuera de servicio.

Ataques de fuerza bruta a través de XML-RPC

Cada vez que xmlrpc.php realiza una solicitud, envía el nombre de usuario y la contraseña para la autenticación. Esto presenta una responsabilidad de seguridad significativa y es algo que la API REST no hace. De hecho, la API REST usa OAuth, que envía tokens para la autenticación en lugar de nombres de usuario o contraseñas.

Debido a que xmlrpc.php envía información de autenticación con cada solicitud, los piratas informáticos podrían usarla para intentar acceder a su sitio. Un ataque de fuerza bruta como este podría permitirles insertar contenido, eliminar código o dañar su base de datos.

Si un atacante envía suficientes solicitudes a su sitio, cada una con un par de nombre de usuario y contraseña diferente, existe la posibilidad de que eventualmente pueda dar con la correcta, dándole acceso a su sitio.

Por eso, si está ejecutando una versión actualizada de WordPress, que utiliza la API REST para comunicarse con sistemas externos, debe deshabilitar xmlrpc.php . No es necesario y podría estar haciendo que su sitio sea vulnerable.

¿Se está ejecutando xmlrpc.php en su sitio de WordPress?

Lo primero que debe hacer es identificar si xmlrpc.php se está ejecutando en su sitio de WordPress.

Este no es un caso simple de verificar si el archivo está allí: es parte de cada instalación de WordPress y estará presente incluso si XML-RPC está deshabilitado.

Para verificar si xmlrpc.php está habilitado en su sitio, use el servicio de validación XML-RPC de WordPress. Esto verificará su sitio y le dirá si xmlrpc.php está habilitado.

Aquí está el resultado que obtuve cuando revisé este sitio en el servicio.

Esto muestra que xmlrpc.php se ha desactivado en kinsta.com. Entonces, si ejecuta la verificación y descubre que xmlrpc.php todavía está habilitado en su sitio, ¿cómo lo desactiva?

Cómo deshabilitar xmlrpc.php

Hay tres formas de deshabilitar xmlrpc.php:

Echemos un vistazo a cada uno individualmente.

Regístrese para recibir el boletín

¿Quiere saber cómo aumentamos nuestro tráfico en un 1000 %?

¡Únase a más de 20,000 personas que reciben nuestro boletín semanal con consejos internos de WordPress!

Suscríbase ahora

Cómo deshabilitar xmlrpc.php con un complemento

Instalar un complemento para deshabilitar xmlrpc.php es la forma más fácil de hacerlo. El complemento Deshabilitar XML-RPC lo deshabilitará por completo. Así es como lo usas.

Mi punto de partida es mi propio sitio web, en el que está habilitado xmlrpc.php. Puedes ver esto a través del cheque que hice:

Instale el complemento a través de la pantalla Complementos en el administrador de WordPress y actívelo.

No tiene que hacer nada más: activar el complemento hará que deshabilite XML-RPC. Ahora, si reviso mi sitio, obtengo un resultado diferente:

¡Es así de simple!

Deshabilite los pingbacks XML-RPC con un complemento

Pero, ¿qué sucede si desea deshabilitar algunos aspectos de xmlrpc.php y otros no? El complemento Disable XML-RPC Pingback le permite deshabilitar solo la funcionalidad de pingback, lo que significa que aún tiene acceso a otras funciones de XML-RPC si las necesita.

El complemento funciona de la misma manera que el complemento Deshabilitar XML-RPC: simplemente instálelo, actívelo y funcionará.

Configure la activación de API REST y XML-RPC con un complemento

Si desea un control más detallado de cómo se configuran xmlrpc.php y REST API en su sitio, puede instalar el complemento REST XML-RPC Data Checker.

Una vez que haya instalado y activado este complemento, vaya a Configuración > Comprobador de datos REST XML-RPC y haga clic en la pestaña XML-RPC .

Esto le permite configurar exactamente qué aspectos de xmlrpc.php están activos en su sitio.

Alternativamente, puede simplemente apagarlo por completo. Y si también desea controlar la API REST, el complemento le brinda otra pestaña para eso.

Cómo deshabilitar xmlrpc.php sin un complemento

Si prefiere no instalar otro complemento en su sitio, puede deshabilitar xmlrpc.php agregando un código en un filtro o en su archivo .htaccess. Veamos ambos métodos.

Deshabilite xmlrpc.php a través de un filtro

Una opción aquí es usar el filtro xmlrpc_enabled para deshabilitar xmlrpc.php. Agregue esta función a un complemento y actívela en su sitio:

 add_filter( 'xmlrpc_enabled', '__return_false' );

Puede agregar esto a su archivo de funciones de tema, pero es una mejor práctica escribir un complemento.

La otra opción tiene que ver con la edición de su archivo .htaccess, que está disponible con proveedores de alojamiento que usan Apache, conectándose al servidor de su sitio a través de FTP o cPanel.

Deshabilite xmlrpc.php a través del archivo .htacess

En su archivo .htaccess , agregue este código:

 <Files xmlrpc.php> Order Allow,Deny Deny from all </Files>

Asegúrese de hacer una copia del archivo anterior antes de hacerlo, en caso de que tenga algún problema.

Haga que su proveedor de alojamiento deshabilite xmlrpc.php

Alternativamente, algunos proveedores de alojamiento deshabilitarán xmlrpc.php si se detecta un ataque.

En Kinsta, cuando se detecta un ataque a través de XML-RPC, se agrega automáticamente un fragmento de código al archivo Nginx.config:

 location ~* ^/xmlrpc.php$ { return 403; }

Esto producirá un error 403 y detendrá el ataque en seco.

Si está haciendo esto usted mismo, es mejor usar uno de los métodos anteriores. Pero antes de hacerlo, siempre consulte primero con su proveedor de alojamiento.

¿Cuándo necesita habilitar xmlrpc.php?

Puede haber algunas ocasiones en las que necesite habilitar xmlrpc.php en su sitio de WordPress o cuando no deba deshabilitarlo por completo.

Estos son:

• No está ejecutando la API REST (no se recomienda, pero es necesario en algunas situaciones), pero necesita comunicarse entre su sitio de WordPress y otros sistemas.
• No puede actualizar WordPress a la versión 4.4 o superior, por lo que no tiene acceso a la API REST. Esto podría deberse a restricciones en la configuración de su alojamiento (en cuyo caso cambiaría de proveedor de alojamiento) o incompatibilidad de temas o complementos (en cuyo caso los reemplazaría o actualizaría).
• Está trabajando con una aplicación externa que no puede acceder a la API REST de WP pero puede acceder a XML-RPC (a largo plazo, recomendaría actualizar esa aplicación o cambiar a una aplicación compatible con REST).

¡Eso es todo! Ninguna de estas son razones particularmente buenas para mantener activada la especificación XML-RPC.

La única razón por la que todavía está en WordPress es por compatibilidad con versiones anteriores y solo lo usaría si está trabajando con sistemas obsoletos. Para cualquiera que desee mantener sus sitios actualizados y trabajar con la última tecnología, deshabilitar xmlrpc.php es el camino a seguir.

Resumen

La especificación XML-RPC se desarrolló incluso antes de que se creara WordPress, como un medio para que WordPress se comunicara con sistemas y aplicaciones externos. Tiene fallas de seguridad inherentes y podría hacer que su sitio sea vulnerable a ataques.

Ahora que la API REST permite que su sitio se comunique con otras aplicaciones, puede deshabilitar xmlrpc.php de manera segura. Si sigue los pasos anteriores, al desactivarlo mejorará la seguridad de su sitio.