La especificación XML-RPC WordPress se elaboró para normalizar la comunicación entre los diferentes sistemas, lo que significa que las aplicaciones fuera de WordPress (como otras plataformas de blogs y clientes de escritorio) podían interactuar con WordPress.
Esta especificación ha formado parte de WordPress desde su creación e hizo un trabajo muy útil. Sin ella, WordPress habría estado en su propio silo, separado del resto de Internet.
Sin embargo, xmlrpc.php tiene sus desventajas. Puede introducir vulnerabilidades en tu sitio de WordPress y ha sido reemplazado por la REST API de WordPress, que hace un trabajo mucho mejor al abrir WordPress a otras aplicaciones.
En este post, explicaremos qué es xmlrpc.php, por qué debes desactivarlo, y te ayudaremos a identificar si se está ejecutando en tu 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. Lo hizo mediante la normalización de 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 del sistema se almacena en un archivo llamado xmlrpc.php, en el directorio raíz del sitio. Y sigue ahí, aunque XML-RPC está muy desactualizado.
En las primeras versiones de WordPress, XML-RPC estaba desactivado por defecto. Pero desde la versión 3.5, ha sido activado por defecto. La razón principal de esto fue permitir que la aplicación móvil de WordPress hable con lainstalación de WordPress.
Si usaste la aplicación móvil WordPress antes de la versión 3.5, quizás recuerdes haber tenido que habilitar XML-RPC en tu sitio para que la aplicación pueda publicar contenido. Esto se debe a que la aplicación no estaba ejecutando el propio WordPress, sino que era una aplicación separada que se comunicaba con tu sitio de WordPress usando xmlrpc.php.
Pero no sólo se utilizó la aplicación móvil para XML-RPC: también se usó para permitir la comunicación entre WordPress y otras plataformas de blogs, permitió trackbacks y pingbacks, y potenció el plugin Jetpack que vincula un sitio autoalojado de WordPress con WordPress.com.
Pero desde que el REST API se integró en el núcleo de WordPress, el archivo xmlrpc.php ya no se utiliza para esta comunicación. En su lugar, la REST API se utiliza para comunicarse con la aplicación móvil de WordPress, con los clientes de escritorio, con otras plataformas de blogs, con WordPress.com (para el plugin Jetpack) y con otros sistemas y servicios. La gama de sistemas con los que la REST API puede interactuar es mucho mayor que la permitida por xmlrpc.php. Además, hay mucha más flexibilidad.
Debido a que la REST API ha reemplazado a XML-RPC, ahora debería desactivar xmlrpc.php en su sitio. Veamos por qué.
¿Por qué deberías desactivar xmlrpc.php?
La razón principal por la que debes desactivar xmlrpc.php en tu sitio de WordPress es porque introduce vulnerabilidades de seguridad y puede ser el objetivo de ataques.
Ahora que XML-RPC ya no es necesario para comunicarse fuera de WordPress, no hay razón para mantenerlo activo. Por eso es prudente hacer tu sitio más seguro desactivándolo.
Si xmlrpc.php es una responsabilidad de seguridad y ya no hace un trabajo, ¿por qué no ha sido eliminado de WordPress por completo?
La razón de esto es porque una de las características clave de WordPress siempre será la compatibilidad con las versiones anteriores. Si administras bien tu sitio, sabrás que es esencial mantener actualizado WordPress, así como cualquier plugin o tema.
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 REST API, seguirán necesitando acceso a xmlrpc.php.
Veamos las vulnerabilidades específicas con más detalle.
Ataques DDoS a través de Pingbacks XML-RPC
Una de las funciones que xmlrpc.php habilitó fue pingbacks y trackbacks. Estas son las notificaciones que aparecen en los comentarios de tu sitio cuando otro blog o sitio se vincula a tu contenido.
La especificación XML-RPC fue lo que hizo posible esta comunicación, pero ha sido reemplazada por la REST API (como ya vimos).
Si XML-RPC está habilitado en tu sitio, un hacker podría potencialmente montar un ataque DDoS en tu sitio explotando xmlrpc.php para enviar un gran número de pingbacks a tu sitio en poco tiempo. Esto podría sobrecargar tu servidor y poner tu sitio fuera de acción.
Ataques de fuerza bruta a través de XML-RPC
Cada vez que xmlrpc.php hace una solicitud, envía el nombre de usuario y la contraseña para su autenticación. Esto presenta una importante responsabilidad de seguridad y es algo que la REST API no hace. De hecho, el REST API utiliza 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 hackers podrían utilizarla para intentar acceder a tu sitio. Un ataque de fuerza bruta como este podría permitirles insertar contenido, borrar código o dañar tu base de datos.
Si un atacante envía suficientes solicitudes a tu sitio, cada una con un par de nombres de usuario y contraseñas diferentes, existe la posibilidad de que eventualmente pueda dar con la correcta, dándole acceso a tu sitio.
Por eso, si estás ejecutando una versión actualizada de WordPress, que utiliza la REST API para comunicarse con sistemas externos, debes desactivar xmlrpc.php. No es necesario y podrías estar haciendo tu sitio vulnerable.
¿Está xmlrpc.php funcionando en tu sitio de WordPress?
Lo primero que tienes que hacer es identificar si xmlrpc.php está funcionando en tu sitio de WordPress.
No se trata de un simple caso de comprobar si el archivo está ahí: es parte de cada instalación de WordPress y estará presente incluso si XML-RPC está desactivado.
Para comprobar si xmlrpc.php está habilitado en tu sitio, utiliza la XML-RPC Validator Web App. Esto comprobará tu sitio y te dirá si xmlrpc.php está habilitado.
Esto muestra que xmlrpc.php ha sido desactivado en kinsta.com. Así que si ejecutas la comprobación y descubres que xmlrpc.php sigue habilitado en tu sitio, ¿cómo lo desactivas?
¿Cómo desactivar xmlrpc.php?
Hay tres formas de desactivar xmlrpc.php:
Echemos un vistazo a cada uno individualmente.
¿Cómo deshabilitar xmlrpc.php con un plugin?
Instalar un plugin para desactivar xmlrpc.php es la forma más fácil de hacerlo. El plugin Disable XML-RPC lo deshabilitará completamente. Así es como se usa.
Mi punto de partida es mi propia página web, en la que está activado xmlrpc.php. Puedes ver esto a través de la comprobación que hice:
Instala el plugin a través de la pantalla de plugins en el administrador de WordPress y actívalo.
No tienes que hacer nada más: al activar el plugin se desactivará el XML-RPC. Ahora, si hago una comprobación en mi sitio, obtengo un resultado diferente:
¡Es así de simple!
Deshabilitar los pingbacks XML-RPC con un plugin
¿Pero qué pasa si quieres deshabilitar algunos aspectos de xmlrpc.php y no otros? El plugin Disable XML-RPC Pingback sólo deshabilitan la funcionalidad de pingback, lo que significa que aún tienes acceso a otras características de XML-RPC si las necesitas.
El plugin funciona de la misma manera que el plugin Disable XML-RPC: sólo tienes que instalarlo, activarlo y funcionará.
Configurar la activación de la API de XML-RPC y REST con un plugin
Si deseas un control más detallado de cómo se configuran tanto xmlrpc.php como el REST API en tu sitio, puedes instalar el plugin REST XML-RPC Data Checker.
Una vez que hayas instalado y activado este plugin, ve a Settings > REST XML-RPC Data Checker y haz clic en la pestaña XML-RPC.
Esto te permite configurar exactamente qué aspectos de xmlrpc.php están activos en tu sitio.
Alternativamente, puedes simplemente apagarlo por completo. Y si también quieres controlar el REST API, el plugin te da otra pestaña para eso.
¿Cómo deshabilitar xmlrpc.php sin un plugin?
Si prefieres no instalar otro plugin en tu sitio, puedes deshabilitar xmlrpc.php añadiendo algún código en un filtro, o en tu archivo .htaccess. Veamos ambos métodos.
Deshabilitar xmlrpc.php a través de un filtro
Una opción aquí es usar el filtro xmlrpc_enabled para desactivar xmlrpc.php. Añade esta función a un plugin y actívalo en tu sitio:
add_filter( 'xmlrpc_enabled', '__return_false' );Podrías añadir esto a tu archivo de funciones temáticas, pero es mejor practicar para escribir un plugin.
La otra opción tiene que ver con la edición de tu archivo .htaccess, que está disponible con los proveedores de hosting que usan Apache, conectándose al servidor de tu sitio a través de FTP o cPanel.
Deshabilitar xmlrpc.php a través del archivo .htacess
En tu archivo .htaccess, añade este código:
<Files "xmlrpc.php">
Require all denied
</Files>Asegúrate de hacer una copia del viejo archivo antes de hacerlo, por si acaso te encuentras con algún problema.
Haz que tu proveedor de alojamiento deshabilite xmlrpc.php
Alternativamente, algunos proveedores de hospedaje deshabilitarán xmlrpc.php si se detecta un ataque.
Esto producirá un error 403 y detendrá el ataque en seco.
En Kinsta, no hay que preocuparse, esto ya está bloqueado. Ponte en contacto con el servicio de atención al cliente para cualquier problema.
Si lo haces tú mismo, es mejor usar uno de los métodos anteriores. Pero antes de hacerlo, siempre consulte primero con tu proveedor de alojamiento.
¿Cuándo necesitas habilitar xmlrpc.php?
Puede que hayan algunas ocasiones en las que necesite shabilitar xmlrpc.php en tu sitio de WordPress o cuando no debes deshabilitarlo completamente.
Estos son:
- No estás ejecutando la REST API (no aconsejada, pero necesaria en algunas situaciones) pero necesitas comunicarte entre tu sitio de WordPress y otros sistemas.
- No puedes actualizar WordPress a la versión 4.4 o superior, así que no tienes acceso a la REST API. Esto puede deberse a restricciones en la configuración del alojamiento (en cuyo caso cambiaría de proveedor de alojamiento) o a la incompatibilidad del tema o los plugins (en cuyo caso los reemplazaría o actualizaría).
- Estás trabajando con una aplicación externa que no puede acceder a la API de WP REST pero que puede acceder a XML-RPC (a largo plazo, aconsejaría actualizar esa aplicación o cambiar a una aplicación compatible con REST).
¡Eso es! Ninguna de estas son razones particularmente buenas para mantener la especificación XML-RPC encendida.
La única razón por la que aún está en WordPress es por la compatibilidad con versiones anteriores y sólo lo usarías si trabajas con sistemas anticuados. Para cualquiera que quiera 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ó antes de que se creara WordPress, como medio para que WordPress se comunicara con sistemas y aplicaciones externas. Tiene fallas de seguridad inherentes y podría hacer que tu sitio sea vulnerable a los ataques.
Ahora que el REST API permite que tu sitio se comunique con otras aplicaciones, puedes desactivar con seguridad xmlrpc.php. Si sigues los pasos anteriores, al deshabilitarlo mejorarás la seguridad de tu sitio.
Rachel McCollin has been helping people build websites with WordPress since 2010. She's a huge fan of self-hosted WordPress and wants to help as many people as possible create an awesome website with it.
Deja una respuesta