Einstellungen für vertrauenswürdige Hosts

Diese Dokumentation ist unvollständig. Mehr Informationen erhalten.

Schutz vor HTTP HOST Header Angriffen (verhindern, dass Ihre Website denkt, sie sei jemand anderes)

Drupal 7 hat eine neue Funktion in den Core integriert, die nicht für die direkte Interaktion mit Benutzern gedacht ist, aber manchmal als poormanscron bezeichnet wird. Diese Funktion führt periodische Aufgaben auf der Drupal-Website aus, wie das Bereinigen von Logdateien, das Versenden von E-Mails und das Leeren von Caches. Diese Funktion zusammen mit der dynamischen Erkennung der „Basis-URL“ (eingeführt in Drupal 4.7) kann zu einigen seltsamen Situationen führen. Dieser Artikel beschreibt einige dieser Probleme, die mit beiden Modulen oder beiden zusammen auftreten können, und was Sie tun können, um sie zu verhindern. Die unten stehenden Hinweise beziehen sich auf einige Standardkonfigurationen – am Ende erkläre ich, wie Sie von diesen Standardeinstellungen abweichen können, um diese Probleme zu vermeiden.

Szenario 1: Empfang/Versand von Benutzer-E-Mails, die für eine andere Domain bestimmt sind

Dieses Verhalten ist relativ leicht zu reproduzieren:

1. Weisen Sie eine neue Domain der IP-Adresse der bestehenden Website zu – nennen wir die bestehende Seite http://www.example.com, und der neue Name, der auf dieselbe IP zeigt, ist http://other-site.example.org.

2. Besuchen Sie die URL: http://other-site.example.org/user/password

3. Geben Sie einen Benutzernamen ein, der wahrscheinlich auf der Website existiert.

Als Ergebnis erkennt $base_url in Schritt 2, dass Ihre Website http://other-site.example.org ist, und alle E-Mail-Token wie [user:one-time-login-url], die Links zur Website enthalten, werden so geändert, dass sie http://other-site.example.org als Basis-URL verwenden. Der Benutzer, der diese E-Mail erhält, sieht, dass sein Benutzername und seine E-Mail-Adresse für example.com nun irgendwie auf http://other-site.example.org verwendet werden, was normalerweise verwirrend ist. Es können jedoch zwei problematische Szenarien entstehen:

• Im schlimmsten Fall klicken sie auf den Passwort-Zurücksetzen-Link, den eine bösartige Website dann nutzen kann, um sich im Namen dieses Benutzers einzuloggen.
• Sie könnten ihren Benutzernamen/Passwort auf http://other-site.example.org eingeben – eine sogenannte Social-Engineering-Attacke –, die dann auf der Hauptseite ausgenutzt werden kann.

Szenario 2: Zwischenspeicherung von Inhalten mit falscher Domain

Ein ähnliches Problem kann auftreten, wenn ein Benutzer eine falsche Domain für die Anfrage verwendet und die Antwort in den Cache mit einer dynamisch bestimmten, vollqualifizierten Domain gespeichert wird. Nachfolgende Zugriffe, die diese zwischengespeicherten Daten verwenden, erhalten eine falsche Domain. Der Core-Seitencache von Drupal verwendet die Domain als Teil der Cache-ID, was dieses Problem verhindert, aber andere Cache-Mechanismen sind möglicherweise nicht so resistent.

Szenario 3: E-Mail-Benachrichtigungen mit falscher Domain

Ein weiteres Problem kann auf Websites auftreten, die Module verwenden, die während des Cron-Laufs E-Mails versenden. Dieses Szenario setzt poormanscron mit dynamischer Basis-URL-Erkennung voraus. Wenn ein Benutzer versehentlich poormanscron auslöst, während Benachrichtigungen mit einer falschen Domain in der Warteschlange sind, werden diese Benachrichtigungen mit der falschen Domain versandt. Die Benutzer sind dann verwirrt, warum sie E-Mails von example.com erhalten, die Links zur Domain http://other-site.example.org enthalten.

Lösungen für Probleme mit dynamischer Drupal base_url-Erkennung

Es gibt mindestens vier mögliche Lösungen für dieses Problem, obwohl nicht alle zwingend notwendig sind. Sie sollten je nach Ihrer Umgebung auswählen.

1. Sie können eine feste Domain als $base_url in sites/default/settings.php festlegen. Obwohl die dynamische Erkennung praktisch sein kann, kann sie auch Probleme verursachen. Eine Möglichkeit, dies zu vermeiden, besteht darin, einen festen Wert zu setzen.

2. Verwenden Sie eine bestimmte sites/example.com/settings.php und lassen Sie $base_url dynamisch ermitteln – das bedeutet, Drupal reagiert auf alle Subdomains von example.com, was Vor- oder Nachteile haben kann.

3. Konfigurieren Sie Ihren Webserver so, dass die Standardseite angezeigt wird, wenn eine eingehende Anfrage nicht zur vorgesehenen Drupal-Installation passt, z. B. eine Fehlerseite.

4. Konfigurieren Sie den Webserver so, dass alle Anfragen, die nicht zur erlaubten Domain gehören, auf die korrekte Domain umgeleitet werden.

Trusted Host Einstellungen in Drupal 8

Stand Januar 2015 unterstützt Drupal 8 „Trusted Host Patterns“, mit denen Sie (und sollten) eine Reihe von regulären Ausdrücken angeben können, die die Domains in eingehenden Anfragen validieren. Ein Beispiel in settings.php sieht so aus:

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

Siehe den obigen Changelog-Eintrag für weitere Details. Beachten Sie, dass Sie bei lokaler Entwicklung Ihre Site durch diese Einstellung selbst blockieren können. In diesem Fall sollten Sie ein Trusted Host Pattern für '^localhost$' hinzufügen.

Trusted Host Einstellung für MAMP 3

Bei lokaler Entwicklung führt die Einstellung '^localhost$' in MAMP 3.5.2 zur Fehlermeldung „Der angegebene Hostname ist für diesen Server nicht zulässig“ und die Site lädt nicht. Die Lösung war, den Eintrag ohne Portnummer auf den Site-Namen zu ändern. In meinem Testprojekt „drupal8“:

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

machte Trusted Host aktiv.

HINWEIS: In MAMP 4.2 funktioniert '^localhost$' ohne Probleme.

Trusted Host Einstellung für Acquia Dev Desktop 2 (getestet mit Drupal 8.6.2 und PHP 7.2.8)

Wenn Sie Acquia Dev Desktop 2 verwenden, versuchen Sie folgendes Trusted Host Pattern. Ersetzen Sie "sitename" durch den Namen Ihrer Site:

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

Trusted Host Einstellung für XAMPP (getestet mit Drupal 8.4.0 und PHP 7.1.8)

Um den Trusted Host Mechanismus zu aktivieren, müssen wir gültige Hosts in $settings['trusted_host_patterns'] definieren.

Öffnen Sie die Datei settings.php und aktualisieren Sie den folgenden Code, um Trusted Host einzurichten:

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

Hier bedeutet:

• '^localhost$': Erlaubt der Site nur den Zugriff über localhost.
• '^192\.168\.00\.52$': Erlaubt der Site nur den Zugriff über die System-IP (unterschiedliche Systeme haben unterschiedliche IPs).
• '^127\.0\.0\.1$': Erlaubt der Site den Zugriff über 127.0.0.1 anstelle von localhost.

Hinweis: Bei Multisite-Installationen geben Sie alle erlaubten Hostmuster für jede Site an.

Trusted Host Einstellungen für Lando (getestet mit Drupal 8.7.10 und PHP 7.2)

Um Trusted Host zu aktivieren, müssen gültige Hosts in $settings['trusted_host_patterns'] definiert sein.

Öffnen Sie die Datei settings.php und aktualisieren Sie sie wie folgt:

$settings['trusted_host_patterns'] = [
  '^'.getenv('LANDO_APP_NAME').'\.lndo\.site$',    # Lando Proxy Zugriff
  '^localhost$',                                  # localhost Zugriff
  '^'.getenv('LANDO_APP_NAME').'\.localtunnel\.me$', # Lando Share Zugriff
  '^192\.168\.1\.100$',                           # LAN IP Zugriff
];

Hinweis: Der Lando-Container enthält weitere Umgebungsvariablen, die zur korrekten Datenbankkonfiguration verwendet werden können. Siehe $lando_info=json_decode(getenv('LANDO_INFO'), TRUE); oder phpinfo(); für Details.