Configuraciones de host confiable

Esta documentación está incompleta. Obtenga más información.

Protección contra ataques de encabezado HTTP HOST (no permita que su sitio piense que es otro)

Drupal 7 añadió al núcleo una nueva función que no está destinada a la interacción directa con el usuario, pero a veces se llama poormanscron. Esta función ejecuta tareas periódicas del sitio Drupal, como limpieza de archivos de registro, envío de correos electrónicos y limpieza de cachés. Esta función, combinada con la detección dinámica de la «URL base» (añadida en Drupal 4.7), puede causar algunas situaciones extrañas. Este artículo describe algunas de esas situaciones, que ocurren con ambos módulos o ambos juntos, y qué puede hacer para prevenirlas. Los comentarios a continuación asumen algunas configuraciones por defecto — al final explicaré cómo salir de estas configuraciones predeterminadas para evitar estos problemas.

Escenario 1. Recepción/envío de correos electrónicos de usuarios destinados a otro dominio

Este comportamiento es bastante fácil de reproducir:

1. Apunte un nuevo dominio a la dirección IP de un sitio existente — llamemos al sitio existente http://www.example.com, y el nuevo nombre que apunta a esa IP será http://other-site.example.org.

2. Visite la URL: http://other-site.example.org/user/password

3. Ingrese un nombre de usuario que probablemente se use en el sitio.

Como resultado, en el paso 2 la detección de $base_url considera que su sitio es http://other-site.example.org, y todos los tokens para correo electrónico, por ejemplo [user: one-time-login-url], que contienen enlaces a su sitio, serán modificados para usar http://other-site.example.org como URL base. El usuario que reciba este correo electrónico verá que su nombre de usuario y correo electrónico para example.com se usan ahora de alguna manera en http://other-site.example.org, lo que normalmente sólo causa confusión. Sin embargo, de esto pueden surgir dos malos escenarios:

• En el peor caso, esto puede hacer que hagan clic en un enlace de restablecimiento de contraseña que un sitio malicioso podría usar para acceder al sitio en nombre de ese usuario.
• Pueden ingresar su nombre de usuario/contraseña en http://other-site.example.org — un ataque de ingeniería social — que luego podría usarse en el sitio principal.

Escenario 2. Caché con registros que contienen dominio incorrecto

Un problema similar puede ocurrir cuando un usuario usa un dominio incorrecto para hacer una solicitud, y esta petición llena un registro en la caché con dominios totalmente calificados y dinámicos. Visitas posteriores que extraen datos de esta caché obtendrán el dominio incorrecto. La caché de página interna del núcleo Drupal usa el dominio como parte del identificador de caché, previniendo este problema, pero otros mecanismos de caché pueden ser menos resistentes.

Escenario 3. Notificaciones por correo con dominio incorrecto

Otro problema puede ocurrir en sitios que usan módulos que envían correos electrónicos durante la ejecución de cron. Este escenario requiere poormanscron con detección dinámica de base_url. Si un usuario accidentalmente ejecuta poormanscron cuando hay notificaciones en cola visitando con un dominio incorrecto, las notificaciones se enviarán con ese dominio incorrecto. Los usuarios estarán muy confundidos de por qué el correo que esperan recibir desde example.com contiene enlaces con el dominio http://other-site.example.org.

Soluciones para la experiencia confusa con la detección dinámica de base_url en Drupal

Existen al menos cuatro soluciones posibles a este problema, aunque no todas son necesarias para evitar que ocurra. Usted debe elegir la que mejor se adapte a su entorno.

1. Puede establecer un dominio específico como su $base_url en sites/default/settings.php. Aunque la detección dinámica puede ser una función conveniente, también puede causar problemas. Una forma de detener esto es establecer un valor fijo.

2. Use un sites/example.com/settings.php específico y deje que la detección de $base_url sea dinámica — esto significa que Drupal responde a todos los subdominios de example.com, lo que puede o no ser una ventaja.

3. Configure su servidor web para mostrar una página predeterminada cuando la solicitud entrante no coincida con la instalación predeterminada de Drupal, por ejemplo, páginas de error.

4. Configure el servidor web para redirigir todas las solicitudes entrantes a su servidor que no pertenezcan al dominio correcto hacia el nombre de dominio correcto.

Configuración de seguridad de host confiable en Drupal 8

A partir de enero de 2015, Drupal 8 soporta «patrones de hosts confiables», donde usted puede (y debe) especificar un conjunto de expresiones regulares que deben coincidir con los dominios en las solicitudes entrantes. Un ejemplo de configuración en settings.php se ve así:

$settings['trusted_host_patterns'] = [
  '^www\.example\.com$',
];

Vea arriba el registro de cambios para más detalles. Note que si está desarrollando localmente, puede bloquear temporalmente su sitio con la configuración anterior por sí mismo. En ese caso, debe agregar un patrón de host confiable para '^localhost$'.

Configuración de host confiable para MAMP 3

Para desarrollo local, el patrón MAMP (3.5.2) '^localhost$' da un error «Nombre de host especificado no válido para este servidor» y no carga el sitio. Encontré una solución cambiándolo al nombre del sitio sin número de puerto. En mi sitio de prueba "drupal8":

$settings['trusted_host_patterns'] = [
  '^drupal8$',
];

activó el host confiable.

NOTA: en MAMP 4.2 '^localhost$' funciona perfectamente.

Configuración de host confiable para Acquia Dev Desktop 2 (probado con Drupal 8.6.2 y PHP 7.2.8)

Si usa Acquia Dev Desktop 2, pruebe el siguiente patrón de host confiable. Cambie "sitename" por el nombre de su sitio:

$settings['trusted_host_patterns'] = array(
    '^sitename\.dd$',
);

Configuración de host confiable para XAMPP (probado con Drupal 8.4.0 y PHP 7.1.8)

Para habilitar el mecanismo de hosts confiables, debemos incluir nuestros hosts permitidos en $settings['trusted_host_patterns'].

Abra el archivo settings.php y actualice el siguiente código para habilitar la configuración de host confiable:

$settings['trusted_host_patterns'] = [
  '^localhost$',                          
  '^192\.168\.00\.52$',
  '^127\.0\.0\.1$',
];

Aquí,

• '^localhost$': permitirá que el sitio funcione solo desde localhost.
• '^192\.168\.00\.52$': permitirá que el sitio se ejecute solo desde la IP del sistema (cada sistema puede tener IP diferentes).
• '^127\.0\.0\.1$': permitirá que el sitio funcione desde 127.0.0.1 en lugar de localhost.

Nota: Si ejecuta multisite, especifique todos los patrones de host que su sitio debe permitir.

Configuración de host confiable para Lando (probado con Drupal 8.7.10 y PHP 7.2)

Para habilitar el mecanismo de hosts confiables, debemos incluir nuestros hosts permitidos en $settings['trusted_host_patterns'].

Abra el archivo settings.php y actualice el siguiente código para habilitar la configuración de host confiable:

$settings['trusted_host_patterns'] = [
  '^'.getenv('LANDO_APP_NAME').'\.lndo\.site$',   # acceso proxy lando
  '^localhost$',                                  # acceso localhost
  '^'.getenv('LANDO_APP_NAME').'\.localtunnel\.me$', # acceso lando share
  '^192\.168\.1\.100$',                           # acceso IP LAN
];

Nota: El contenedor de Lando contiene más variables de entorno que pueden usarse para establecer las credenciales de base de datos correctas. Para esto, vea $lando_info=json_decode(getenv('LANDO_INFO'), TRUE); o consulte phpinfo().