Archivo de la etiqueta: micropíldora

Micropíldora 5 – Deshabilitar función xmlrpc.php de WordPress

Deja un comentario

Según podemos leer en la Wikipedia, XML-RPC es un protocolo de llamada a procedimiento remoto (Remote Procedure Call) que usa el formato XML para codificar los datos y utiliza el protocolo web (HTTP) para la transmisión de los datos.

Logo de XML-RPC WordPress

XML-RPC WordPress logo. Fuente imagen: JJW Design

Dentro de la plataforma WordPress podríamos traducir esta frase como el sistema que permite la ejecución de instrucciones en nuestro blog de forma remota.

Gracias a este sistema podemos publicar de forma remota o gestionar nuestro blog con la aplicación móvil de WordPress, pero claro se trata de una herramienta de gestión que es muy probable que la gran mayoría de usuarios no utilicemos (y muchos ni siquiera conozcan).

A partir de WordPress 3.5 se habilitó esta posibilidad de gestión remota por defecto (antes era opcional), llegando incluso a quitar la opción de activar o desactivarlo desde los ajustes del panel de control. Por el principio de mínima exposición si no vamos a utilizarlo es preferible bloquearlo.

Cómo bloquear el acceso al sistema XML-RPC

Ya que no existe la posibilidad de deshabilitar el sistema XML-RPC en los ajustes de WordPress, tenemos dos opciones:

  1. Utilizar un plugin específico como puede ser Disable XML-RPC.
  2. Utilizar el fichero .htaccess de nuestro blog para bloquear el acceso. Esta es la opción que veremos a continuación

Bloquear acceso al fichero xmlrpc.php desde .htaccess

XMLRPC habilitado

Ejemplo de acceso habilitado al sistema xmlrpc.php

Utilizaremos las opciones de gestión de ficheros del archivo .htaccess para bloquear cualquier acceso al fichero xmlrpc.php, deshabilitando así esta funcionalidad de control remoto.

En la primera captura podéis ver cómo se ve un acceso al fichero xmlrpc.php desde un navegador normal: nos avisa de que el formato recibido no es el esperado pero el mero hecho de que responda demuestra que el servicio está activo.

Para bloquear el acceso a este fichero bastará con añadir al fichero .htaccess las siguientes líneas:

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

Bloqueo del sistema xmlrpc

Ejemplo de bloqueo de acceso al sistema xmlrpc

Con esto indicamos al servidor que cualquier acceso al fichero xmlrpc.php debe ser bloqueado. Si intentamos acceder al fichero con nuestro navegador veremos un mensaje del servidor indicando que no estamos autorizados a acceder. Así eliminamos la posibilidad de que nadie acceda a la gestión de nuestro WordPress desde este entorno.

Micropíldora 4 – Forzar el uso de HTTPS

1 respuesta
Paso de HTTP a HTTPS Prevent SQL Injection. Fuente imagen: Planetainformatico.es

Paso de HTTP a HTTPS. Fuente imagen: Planetainformatico.es

Estamos acostumbrados a que cuando accedemos a una página cifrada con certificados SSL nuestro navegador nos lo muestre en la barra de direcciones con un icono de un candado y cambiando el protocolo HTTP por el HTTPS. El hecho de utilizar este cifrado nos asegura que el tráfico entre el cliente y la web accedida es seguro, pero ¿cómo hacemos que nuestros visitantes de nuestra web pasen de utilizar el protocolo HTTP estándar por el HTTPS?

Suponiendo que tengáis instalado correctamente un certificado SSL en vuestro servidor (consultar con la ayuda de vuestro hosting sino lo sabéis) la solución es tan sencilla como modificar el fichero de configuración .htaccess para que todas las peticiones que lleguen al puerto 80 (el usado por HTTP) se redirijan a la correspondiente URL pero usando el prefijo https://. Así el navegador de nuestros usuarios utilizará el protocolo seguro siempre que se conecte a nuestra web.

Tan sólo buscar el modulo rewrite y añadir las dos instrucciones marcadas en azul: en la primera se indica la condición que debe suceder (un acceso al puerto 80 del servidor) y qué cambio debe realizarse (cambiar la URL para que empiece por https://securizando.com/):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
…
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://securizando.com/$1 [R,L]
</IfModule>
# END WordPress

Obviamente deberéis cambiar la URL en rojo por la de vuestro blog 😉

Micropíldora 3 – Protege tu Apache contra SQL Injection

Deja un comentario

Los ataques SQL Injection son los más comunes en el mundo web y uno de los primeros que e suelen probar contra los servicios web de cualquier empresa.  Los ataques más básicos de esta categoría consisten en solicitar información no prevista a la base de datos de tal manera que bien nos la muestre en pantalla o bien que la podamos deducir (Blind SQL Injection). Esta solicitud de información suele realizarse añadiendo instrucciones SQL a la petición normal de tal forma que el servicio responda, además de la petición original y legítima, con la información que solicita el atacante o bien de tal forma que se pueda extrapolar. El funcionamiento de los ataques a ciegas (Blind SQL Injection) se tratará en su propio artículo.

Ejemplo ficticio de ataque SQL donde se solicitaría la versión de la base de datos que funciona tras la página web:

http://www.webvictima.com/?id=1 union select @@version()

Las instrucciones SQL utilizan diferentes palabras claves por lo que intentar localizarlas en las cadena de texto de las peticiones que llegan a nuestro navegador podría servir como medida de protección ante estos ataques. En el siguiente código se busca las palabras claves union y select dentro de la URL solicitada y en caso de encontrarlas se devolverá la página de error 404 (Page Not found) que haya definida en la configuración del servidor Apache. Como una de las técnicas básicas de los atacantes para evitar ser detectado es ofuscar las cadenas de peticiones para evitar su fácil detección se han incluido las conversiones de las cadenas de caracteres en formatos hexadecimal y Unicode que suelen ser utilizados:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*(union|%75%6E%69%6F%6E|&#117;&#110;&#105;&#111;&#110;).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(select|%73%65%6C%65%63%74|&#115;&#101;&#108;&#101;&#99;&#116;).* [NC]
RewriteRule . – [R=404,L,NC]
</IfModule>

Este truco supone que el servidor Apache tiene correctamente activado y configurado el módulo de rewrite y se ha definido correctamente la página de error 404. Como siempre que se tocan ficheros de configuración haced una copia de seguridad antes 😉