Paramètres d'hôtes de confiance

05/07/2025, by Ivan

Cette documentation est incomplète. Obtenez plus d’informations.

Protection contre les attaques par en-tête HTTP HOST (ne laissez pas votre site croire qu’il s’agit d’un autre)

Drupal 7 a ajouté au noyau une nouvelle fonctionnalité qui n’est pas destinée à une interaction directe avec l’utilisateur, mais est parfois appelée poormanscron. Cette fonction exécute les tâches périodiques du site Drupal, telles que le nettoyage des fichiers journaux, l’envoi d’e-mails et le vidage des caches. Cette fonctionnalité combinée à la détection dynamique de « base URL » (ajoutée dans Drupal 4.7) peut entraîner des situations étranges. Cet article décrit certaines de ces situations étranges survenant avec l’un ou l’autre des modules, et ce que vous pouvez faire pour les éviter. Les commentaires ci-dessous supposent certaines configurations par défaut — à la fin, je décrirai comment s’écarter de ces réglages par défaut pour éviter ces problèmes.

Scénario 1. Envoi / réception d’e-mails d’utilisateurs destinés à un autre domaine

Ce comportement est assez facile à reproduire :

1. Pointez un nouveau domaine vers l’adresse IP d’un site existant — appelons le site existant http://www.example.com et le nouveau nom pointant vers cette IP sera http://other-site.example.org.

2. Visitez l’URL : http://other-site.example.org/user/password

3. Entrez un nom d’utilisateur probablement utilisé sur le site.

En conséquence, à l’étape 2, la détection de $base_url considère que votre site est http://other-site.example.org et tous les tokens pour les e-mails, comme [user: one-time-login-url], contiennent des liens vers ce domaine comme base URL. L’utilisateur recevant cet e-mail verra que son nom d’utilisateur et son adresse e-mail pour example.com sont maintenant d’une certaine façon utilisés sur http://other-site.example.org, ce qui est généralement déroutant. Cependant, deux scénarios néfastes peuvent en découler :

Dans le pire des cas, cela peut conduire à ce qu’ils cliquent sur un lien de réinitialisation de mot de passe que le site malveillant pourrait alors utiliser pour se connecter au site en leur nom.
Ils peuvent saisir leur nom d’utilisateur / mot de passe sur http://other-site.example.org — une attaque dite d’ingénierie sociale — qui pourrait ensuite être utilisée contre le site principal.

Scénario 2. Cache contenant un domaine incorrect

Un problème similaire peut survenir lorsqu’un utilisateur utilise un mauvais domaine pour faire une requête, qui remplit une entrée cache avec des domaines dynamiques et pleinement qualifiés. Les visites suivantes, qui récupèrent ces données du cache, recevront un mauvais nom de domaine. Le cache de page de base Drupal utilise le domaine comme partie de l’identifiant cache, ce qui évite ce problème, mais d’autres mécanismes de cache peuvent ne pas être aussi robustes.

Scénario 3. Notifications e-mail contenant un domaine incorrect

Un autre problème peut survenir sur les sites qui utilisent des modules envoyant des e-mails lors de l’exécution de cron. Ce scénario nécessite poormanscron avec la détection dynamique de base_url. Si un utilisateur exécute accidentellement poormanscron alors que des notifications sont en file d’attente, mais en visitant un mauvais domaine, alors ces notifications seront envoyées avec ce mauvais domaine. Les utilisateurs seront très confus de voir des mails contenant des liens vers http://other-site.example.org alors qu’ils s’attendent à recevoir des mails du domaine example.com.

Solutions pour les problèmes liés à la détection dynamique de base_url dans Drupal

Il existe au moins quatre solutions possibles à ce problème, bien que toutes ne soient pas nécessaires pour éviter l’apparition du problème. Vous devez choisir selon votre environnement.

Vous pouvez définir un domaine spécifique comme votre $base_url dans sites/default/settings.php. Bien que la détection dynamique soit pratique, elle peut poser problème. Une façon de l’éviter est de fixer une valeur permanente.
Utilisez un fichier sites/example.com/settings.php spécifique et laissez la détection dynamique de $base_url — ce qui signifie que Drupal répondra à tous les sous-domaines example.com, ce qui peut être un avantage ou non.
Configurez votre serveur web pour afficher une page par défaut lorsque la requête entrante ne correspond pas à l’installation Drupal par défaut, par exemple une page d’erreur.
Configurez votre serveur web pour rediriger toutes les requêtes arrivant sur votre serveur qui ne correspondent pas au domaine correct vers le nom de domaine approprié.

Configuration de la sécurité Trusted Host dans Drupal 8

Depuis janvier 2015, Drupal 8 supporte les « patterns de trusted hosts », où vous pouvez (et devez) spécifier un ensemble d’expressions régulières que les domaines des requêtes entrantes doivent correspondre. Un exemple de configuration dans settings.php ressemblerait à :

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

Voir l’historique des modifications pour plus d’informations. Notez que si vous développez localement, vous pouvez (temporairement) bloquer votre site avec cette configuration. Dans ce cas, vous devez ajouter un pattern trusted host pour '^localhost$'.

Configuration Trusted Host pour MAMP 3

Pour le développement local, le pattern MAMP (3.5.2) '^localhost$' génère une erreur « Nom d’hôte non valide pour ce serveur » et empêche le chargement du site. La solution est de changer ce pattern pour le nom du site sans numéro de port. Par exemple, pour mon site de test "drupal8" :

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

Cela active Trusted Host.

NOTE : sur MAMP 4.2, '^localhost$' fonctionne parfaitement.

Configuration Trusted Host pour Acquia Dev Desktop 2 (testé avec Drupal 8.6.2 et PHP 7.2.8)

Si vous utilisez Acquia Dev Desktop 2, essayez ce pattern trusted host. Remplacez "sitename" par le nom de votre site :

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

Configuration Trusted Host pour XAMPP (testé avec Drupal 8.4.0 et PHP 7.1.8)

Pour activer le mécanisme Trusted Host, il faut définir les hôtes autorisés dans $settings['trusted_host_patterns'].

Ouvrez le fichier settings.php et mettez à jour avec le code suivant pour configurer Trusted Host :

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

Ici :

'^localhost$' : permet au site de fonctionner uniquement via localhost.
'^192\.168\.00\.52$' : permet au site de fonctionner uniquement depuis l’adresse IP système (différents systèmes ont des IP différentes).
'^127\.0\.0\.1$' : permet au site de fonctionner via 127.0.0.1 au lieu de localhost.

Note : en cas d’utilisation de multisite, indiquez tous les patterns d’hôtes autorisés pour le site.

Paramètres Trusted Host pour Lando (testé avec Drupal 8.7.10 et PHP 7.2)

Pour activer Trusted Host, incluez vos hôtes autorisés dans $settings['trusted_host_patterns'].

Ouvrez settings.php et mettez à jour avec :

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

Note : le conteneur Lando contient plus de variables d’environnement qui peuvent être utilisées pour configurer correctement les identifiants de base de données. Pour cela, regardez $lando_info=json_decode(getenv('LANDO_INFO'), TRUE); ou utilisez phpinfo();.

Types de blocs supplémentaires (EBT) – Nouvelle expérience de Layout Builder❗

❗Types de paragraphes supplémentaires (EPT) – Nouvelle expérience Paragraphes