Instellingen voor vertrouwde host

Deze documentatie is onvolledig. Voeg meer informatie toe.

Bescherming tegen HTTP HOST Header-aanvallen (voorkom dat je site denkt dat het een andere is)

Drupal 7 heeft een nieuwe functie aan de core toegevoegd die niet bedoeld is voor directe gebruikersinteractie, maar soms wordt genoemd poormanscron. Deze functie voert periodieke taken van de Drupal-site uit, zoals het opschonen van logbestanden, het verzenden van e-mails en het wissen van caches. Deze functie, in combinatie met dynamische detectie van de “base URL” (toegevoegd in Drupal 4.7), kan leiden tot enkele vreemde situaties. Dit artikel beschrijft enkele van deze situaties die zich kunnen voordoen en hoe je ze kunt voorkomen.

Scenario 1. Gebruikers ontvangen of verzenden e-mails die voor een ander domein bedoeld zijn

Dit gedrag is vrij eenvoudig te reproduceren:

1. Wijs een nieuw domein toe aan het IP-adres van een bestaande site – stel dat de bestaande site http://www.example.com is, en het nieuwe domein dat naar dit IP verwijst is http://other-site.example.org.

2. Bezoek de URL: http://other-site.example.org/user/password

3. Voer een gebruikersnaam in die waarschijnlijk bestaat op de site.

Als gevolg daarvan zal Drupal tijdens stap 2 denken dat de basis-URL http://other-site.example.org is. Alle e-mails die dynamische URL-tokens bevatten, zoals [user:one-time-login-url], zullen verwijzen naar dit verkeerde domein. Dit kan leiden tot verwarring of, erger nog, tot beveiligingsproblemen:

• In het ergste geval kan een kwaadwillende partij de link voor wachtwoordherstel gebruiken om zich toegang te verschaffen tot de site.
• Gebruikers kunnen hun wachtwoord invoeren op het verkeerde domein – een vorm van social engineering – waardoor hun inloggegevens kunnen worden misbruikt.

Scenario 2. Caching van inhoud met het verkeerde domein

Een vergelijkbaar probleem kan optreden wanneer een gebruiker de verkeerde domeinnaam gebruikt en deze aanvraag gegevens in de cache opslaat met het verkeerde domein. Latere bezoekers die de gecachte inhoud oproepen, krijgen mogelijk foutieve domeinnaamreferenties te zien. De interne paginacache van Drupal gebruikt het domein als onderdeel van de cache-ID, maar andere cachingmechanismen doen dat mogelijk niet.

Scenario 3. Cron-taken die e-mails met een verkeerd domein verzenden

Op sites die modules gebruiken die e-mails versturen via cron, kan dit probleem ook optreden. Als poormanscron actief is en dynamisch de verkeerde base URL detecteert, kunnen meldingen per ongeluk worden verzonden met het verkeerde domein.

Oplossingen voor problemen met dynamische base_url-detectie

Er zijn verschillende manieren om dit probleem te vermijden. Kies de oplossing die past bij jouw serverconfiguratie:

1. Stel een vaste waarde in voor $base_url in sites/default/settings.php. Dit voorkomt dat Drupal dynamisch de URL probeert te bepalen.
2. Gebruik afzonderlijke configuratiebestanden voor elke site, bijvoorbeeld sites/example.com/settings.php.
3. Configureer je webserver zodat verzoeken voor onbekende domeinen een foutpagina of standaardpagina weergeven.
4. Stel je webserver in om alle verzoeken voor niet-geautoriseerde domeinen door te sturen naar het juiste domein.

Beveiligingsinstellingen voor Trusted Host Patterns in Drupal 8

Vanaf januari 2015 ondersteunt Drupal 8 “trusted host patterns”. Hiermee kun je reguliere expressies definiëren die de toegestane domeinen specificeren voor inkomende HTTP-verzoeken. Een voorbeeldconfiguratie in settings.php ziet er als volgt uit:

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

Let op: tijdens lokale ontwikkeling kan deze instelling voorkomen dat je site laadt. Voeg daarom indien nodig '^localhost$' toe.

Trusted Host-instellingen voor MAMP 3

In MAMP (3.5.2) veroorzaakt '^localhost$' soms een foutmelding “Invalid host name specified for this server”. De oplossing is om de sitenaam zonder poortnummer te gebruiken. Bijvoorbeeld, voor een testsite met de naam "drupal8":

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

Dit activeert Trusted Host correct. (Opmerking: in MAMP 4.2 werkt '^localhost$' wel goed.)

Trusted Host-instellingen voor Acquia Dev Desktop 2

Als je Acquia Dev Desktop 2 gebruikt (getest met Drupal 8.6.2 en PHP 7.2.8), gebruik dan het volgende patroon (vervang “sitename” door de naam van je site):

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

Trusted Host-instellingen voor XAMPP

Voor XAMPP (getest met Drupal 8.4.0 en PHP 7.1.8), voeg de volgende regels toe aan settings.php:

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

• '^localhost$': laat alleen toegang vanaf localhost toe.
• '^192\.168\.00\.52$': staat toegang toe vanaf een specifiek lokaal IP-adres.
• '^127\.0\.0\.1$': staat toegang toe via 127.0.0.1 in plaats van localhost.

Opmerking: bij gebruik van een multisite-instelling moeten alle toegestane domeinen worden vermeld in $settings['trusted_host_patterns'].

Trusted Host-instellingen voor Lando

Voor Drupal op Lando (getest met Drupal 8.7.10 en PHP 7.2):

$settings['trusted_host_patterns'] = [
  '^'.getenv('LANDO_APP_NAME').'\.lndo\.site$',
  '^localhost$',
  '^'.getenv('LANDO_APP_NAME').'\.localtunnel\.me$',
  '^192\.168\.1\.100$',
];

Opmerking: Lando-containers bevatten meerdere omgevingsvariabelen die je kunt gebruiken voor database- of netwerkconfiguraties. Raadpleeg bijvoorbeeld:

$lando_info = json_decode(getenv('LANDO_INFO'), TRUE);

of gebruik phpinfo() om ze te bekijken.