[gelöst] settings.php + trusted_host_patterns + Protecting against HTTP HOST Header attacks
Eingetragen von ZNC (45)am 26.10.2016 - 07:27 Uhr in
Moin moin in die Runde,
nachdem ich nunmehr (erfolgreich nach meinem derzeitigen Wissenstand) Drupal 8.2.1 installiert habe, dachte ich "Alles in Butter". Bis ich im Konfigurationsbereich von Drupal die Warnmeldung "One or more problems were detected with your Drupal installation. Check the status report for more information." sah. Ich hangelte mich zum Statusbericht (status report) durch und las folgende Meldung "Trusted Host Settings: Nicht aktiviert: The trusted_host_patterns setting is not configured in settings.php. This can lead to security vulnerabilities. It is highly recommended that you configure this. See Protecting against HTTP HOST Header attacks for more information.".
Bei meinen Recherchen bin ich dann auf Protecting against HTTP HOST Header attacks gestoßen. Diesen Artikel versuchte ich zu übersetzen. Könnte jemand mir bei den fehlenden Übersetzungen (sind fett markiert) helfen?
Beginn der Übersetzung:
Schutz vor HTTP-HOST-Header Attacken
Stand: 23.09.2016
Drupal 7 erweiterte den Kern (core) um ein neues Feature, das dem Anwender nicht ins Auge sticht, aber manchmal als "der Cron des armen Mannes" bezeichnet wird. Diese Funktion aktiviert periodisch anstehende Aufgaben einer Drupal Seite wie beispielsweise Logfiles leeren, eMails verschicken und bestimmte Caches leeren. Aber in Kombination mit der dynamischen Erkennung der base_url (in Drupal 4.7 hinzugekommen), kann dies zu verrückten Situationen führen. Dieser Artikel beschreibt einige dieser Situationen, die mit einem oder beiden der Module auftreten können und was Sie tuen können, um dies zu verhindern. Die Beispiele unten gehen von einigen Standard-Konfigurationen aus - am Schluß werde ich ausführen, wie Sie dies, um solche Probleme zu verhindern, umgehen können.
Szenario 1: Versenden und Erhalten von Benutzer-eMails, die für eine andere Domäne bestimmt zu sein scheinen
Dieses Szenario ist ziemlich einfach zu bewerkstelligen:
- Weisen Sie eine neue Domain der IP einer existierenden Seite zu - die vorhandene Website soll www. beispielseite .com und der neue Name, der auf diese IP verweist, soll boeseSeite.beispielseite .org heißen.
- Besuchen Sie die URL: boeseSeite.beispielseite .org/user/password
- Geben Sie einen gängigen, auf dieser Seiten benutzten, Benutzernamen ein.
Das Ergebnis ist, dass in Schritt 2 die base_url Erkennung denkt, dass Ihre Website boeseSeite.beispielseite .org ist und somit alle Tokens für die eMails wie [user: one-time-login-url], die Links zu Ihrer Website, enthalten auf boeseSeite.beispielseite .org als Basis-URL ändert.
Der Benutzer, der diese E-Mail empfängt, sieht, dass der Benutzername und eMail der beispielseite.com jetzt irgendwie für boeseSeite.beispielseite .org verwendet wird, was normalerweise nur verwirrend ist. Allerdings können zwei üble Szenarien hieraus resultieren:
- In einem Worst-Case-Szenario könnte die boeseSeite über einen Passwort-Reset-Link in dieser eMail das Password somit erschleichen.
- Sie könnte Benutzername/Password auf der boeseSeite.beispielseite .org eingeben - ein sogenannter Social-Engineering-Angriff, was dann auf der Hauptseite verwendet werden könnte.
Szenario 2: Cache-Einträge, die eine falsche Domain beinhalten
Ein ähnliches Problem kann auftreten, wenn ein Benutzer die falsche Domäne verwendet, um Anfragen zu stellen und ies führt dazu, dass ein Cacheeintrag mit dynamischen, voll qualifizierten Domainnamen initialisiert wird. Nachfolgende, die Informationen aus diesem Cache abrufen, erhalten dann den falschen Domänennamen. Der Seitencache des Drupal Kerns verwendet, um dieses Problem zu verhindern, die Domäne als Teil der Cache-ID, aber andere Caching-Mechanismen in Drupal wären möglicherweise nicht so robust.
Szenario 3: Benachrichtigungsmails, die eine falsche Domain beinhalten
Bei Modulen, die während Cron-Aufträge abgearbeitet werden, eMails versenden, könnte ein weiteres Problem auftauchen. Dieses Szenario gilt für den "Cron des armen Mannes" in Verbindung mit der base_url-Erkennung. Wenn ein Anwender über eine falsche Domain in den "Cron des armen Mannes" einsteigt, während dort Benachrichtigungen in der Warteschlange sind, werden diese Benachrichtigungen mit der falschen Domain geschickt. Es verwirrt die Empfänger, da die eMails, die sie normalerweise von www. beispielseite .com erhalten, die boeseSeite.beispielseite .org beinhalten.
Lösungen für die verwirrenden Möglichkeiten mit der dynamischen base_url-Erkennung von Drupal
Es gibt mindestens vier mögliche Lösungen dieses Problem, aber nicht alle sind notwendig, um es zu beheben. Sie sollten sich die rauspicken, die für Ihre Umgebung die passende ist.
- Sie deklarieren ihre Domain als Ihr $base_url in sites/default/settings.php. Die dynamische base_url-Erkennung kann ein praktische Feature sein, kann aber auch zu Problemen führen. Eine Möglichkeit, Probleme zu verhindern, ist eben diesen Wert zu setzen.
- Benutzen Sie eine spezifische sites/example.com/settings.php und lassen Sie die base_url automatisch ermitteln. Dies hat die Auswirkung, dass Drupal überlassen wird, auf alle Subdomains von www. beispielseite .com zu antworten, dies kann manchmal vielleicht ein Vorteil sein.
- Konfigurieren Sie Ihren Webserver so, dass ihre Standard-Seite hochkommt, wenn eingehende Anfragen etwas anderes als Ihre Standard-Drupal-Installation ist, z. B. eine Fehlerseite.
- Richten sie Ihre Webserver-Konfiguration so aus, dass alle Anforderungen, die zwar nicht für ihre Domäne sind, aber Ihren Server erreichen, auf den richtigen Domänennamen weitergeleitet werden.
Trusted Host-Sicherheitseinstellung in Drupal 8
Ab Januar 2015 unterstützt Drupal 8 "trusted host patterns" (vertrauenswürdige Host-Muster), wo Sie eine Reihe von regulären Ausdrücken definieren können (und auch sollten), die eingehenden Anfragen müssen dann mit diesen Domänen-Eintragungen übereinstimmen. Beispielkonfiguration in settings.php:
<?php
$settings['trusted_host_patterns'] = array(
'^www\.beispielseite\.com$',
'^www\.forum\.beispielseite\.com$',
);
?>Anmerkung zur Schreibweise in trusted_host_patterns für den Domainnamen:
Zitat Hyp1:
Regex Zeichen:
^ = start of string
$ = start of string
/ = unescaped delimiter
. = any character
Für Domains bedeutet das:
Da ein Punkt "." in regex ein beliebiges Zeichen ist muss dieser escaped werden
Da ein Slash "/" in regex ein Delimiter ist muss dieses escaped werden
Für weitere Informationen Websiteentwicklung: PHP: Reguläre Ausdrücke
(Absatz: Zeichenklassen und klassenartige Konstrukte + Anker und Zusicherungen der Länge null)
- Anmelden oder Registrieren um Kommentare zu schreiben
Hi, das ist nicht ganz
am 26.10.2016 - 11:21 Uhr
Hi,
das ist nicht ganz richtig.
Zu der Schreibweise ein interessanter Thread "trusted_host_patterns" auf http://www.drupalcenter.de/node/55704
Scheinbar ist das \. keine Maskierung des Punktes, sondern dient der Eingrenzung des Domainnamens.
Auch bei einer normalen schreibweise würde der Punkt den Domainnamen abgrenzen: www.example.com
Der Punkt muss "escaped" werden weil das Trusted Hostname Pattern eine Regular Expression ist.
In Regex bedeutet der Punkt ein beliebiges Zeichen mit \. sagt man in Regex das tatsächlich
der Punkt gemeint ist und kein beliebiges Zeichen.
Gruss
Robert
Danke für Deine Rückmeldung
am 26.10.2016 - 13:14 Uhr
Danke für Deine Rückmeldung @Hyp1.
Wie sähe dann der Eintrag für beispielsweise diese Adresse aus: www. privat.meine-seite .com?
So?
'^www\.privat\.meine-seite\.com$'Hi
am 26.10.2016 - 13:31 Uhr
Ja, der Eintrag sähe so aus:
^www\.privat\.meine-seite\.de$zur vollständigen Erklärung:
Regex Zeichen:
^ = start of string
$ = start of string
/ = unescaped delimiter
. = any character
Für Domains bedeutet das:
Da ein Punkt "." in regex ein beliebiges Zeichen ist muss dieser escaped werden
Da ein Slash "/" in regex ein Delimiter ist muss dieses escaped werden
Du kannst das hier testen:
https://regex101.com/
ohne http://
^www\.privat\.meine-seite\.de$gültig:
www.privat.meine-seite.de
oder mit http://
^http:\/\/www\.privat\.meine-seite\.de$gültig:
http://www.privat.meine-seite.de
Hoffe das bringt Licht ins Dunkel ;-)
Gruss
Robert
Lieben Dank. Jetzt ist nur
am 26.10.2016 - 14:06 Uhr
Lieben Dank.
Jetzt ist nur noch die Übersetzung offen. Vielleicht jemand da, der Hilfestellung geben kann?
Übersetzung:2. [en: Use a
am 26.10.2016 - 15:46 Uhr
Übersetzung:
2. [en: Use a specific sites/example.com/settings.php and leave dynamic $base_url - this has the implication of letting Drupal respond to all subdomains of example.com which may or may not be a benefit. > de: ?]
2. Benutzen Sie eine spezifische sites/example.com/settings.php
und lassen Sie $base_url dynamisch - das hat die Auswirkung, dass Drupal auf alle subdomains von example.com antwortet. Dies kann ein Vorteil oder auch ein Nachteil sein
Gruss
Robert
Übersetzung gesucht: settings.php + trusted_host_patterns + ...
am 27.10.2016 - 07:17 Uhr
Hallo Robert,
Use a specific sites/example.com/settings.php and leave dynamic $base_url
Ist damit nicht:
Benutzen Sie eine separate sites/example.com/settings.php und verwenden keine dynamische base_url-Erkennung
gemeint?
Das muss man wohl ausprobieren
am 27.10.2016 - 07:35 Uhr
leave kann belassen, aber auch verlassen, oder bleiben lassen heißen.
Hallo @ronald, ja das ist
am 27.10.2016 - 08:01 Uhr
Hallo @ronald, ja das ist klar, wie würdest Du diesen Satz übersetzen?
Den Durchblick habe ich noch nicht. Wenn man die Zusammenhänge kennt, könnte z.B. auch dies mit
Benutzen Sie eine separate sites/example.com/settings.php und belassen Sie die dynamische base_url-Erkennung
übersetzt werden, nicht?
eben weil es nicht eindeutig ist
am 27.10.2016 - 08:08 Uhr
kommst du ums probieren nicht herum.
Ich hätte es auch genau so gesehen - to leave something - es belassen wie es ist.
Man muss bei Softwaredokumentationen aber auch damit rechnen, dass diese von Menschen aus ganz anderen Sprach- und Kulturräumen geschrieben worden sind.
Vielleicht gehst du auf die Suche nach einer anderen Beschreibung, die eindeutiger ist.
Meist haben sich mehrere Personen in unterschiedlichen Ländern mit der Thematik befasst.
Hi Leute, ich weiss zwar was
am 27.10.2016 - 13:34 Uhr
Hi Leute,
ich weiss zwar was gemeint(Semantik) ist, aber Übersetzen(Syntax) ist halt etwas anderes.
Aber evtl. hilft es dabei wenn ich schreibe wie ich denke dass es gemeint ist.
Hier im ersten Satz ist die Rede von einem Unterverzeichnis im Document Root des Servers.
Ich leite das daraus ab, weil von default/settings.php die Rede ist und $base_path nicht gesetzt werden müsste, wäre die Site im Document Root.
->
Sie deklarieren ihre Domain als Ihr $base_url in sites/default/settings.php. Die dynamische base_url-Erkennung kann ein praktische Feature sein, kann aber auch zu Problemen führen. Eine Möglichkeit, Probleme zu verhindern, ist eben diesen Wert zu setzen.
Hier im zweiten Satz ist die Rede von RICHTIGEN Domains bzw. Domain Aliase
Das leite ich daraus ab, dass von sites/example.com/settings.php die Rede ist und dynamisch kann der $base_url nur sein wenn er NICHT gesetzt ist.
Wäre $base_url hier gesetzt würde die Site auch nur für diesen Antworten.
->
[en: Use a specific sites/example.com/settings.php and leave dynamic $base_url - this has the implication of letting Drupal respond to all subdomains of example.com which may or may not be a benefit. > de: ?]
Soll heissen ich kann es zwar erklären aber auch nur schlecht Übersetzen
Liebe Grüsse vor allem an Dich Ronald! ;-)
settings.php + trusted_host_patterns + Protecting against HTTP H
am 29.10.2016 - 06:33 Uhr
Dies ist die Antwort auf meine Frage aus https://www.drupal.org/node/1992030#comment-11754560:
Hello, first of all I had to explain, that I have rudimentary knowledge of english. I tried to translate this into german, but two sentences are not clear for me (I think because of my lacks):
1. "Submit a username that is likely to be populated." Do you mean, to try to find a popular username?
2. "Use a specific sites/example.com/settings.php and leave dynamic $base_url - this has the implication of letting Drupal respond to all subdomains of example.com which may or may not be a benefit." I couldn't understand wether "leave" in german means to skip something or to left something.
Antwort von gregglers
Good questions. I've tried to edit the document to make it clearer to understand because it wasn't that clear in English really.
To address your questions:
1. Yes, your understanding is correct. A popular username or one likely to exist for any reason (e.g. a site like drupal.org is likely to have an account named drupal and drupalfan but that is not a popular username anywhere else).
2. Leave it (do not hard-code a value) so it has the default behavior where it is dynamic.
Er hat die Übersetzungen folgendermaßen geändert:
1. Submit a username that is likely to be used on the site
2.Use a specific sites/example.com/settings.php and let $base_url be detected dynamically - this has the implication of letting Drupal respond to all subdomains of example.com which may or may not be a benefit.
Mir hats geholfen. Mein Dank an Euch.
wie machte ich das bei localhost und einer Mailadresse,
am 15.04.2019 - 05:07 Uhr
die auf meinem provider liegt, bei dem ich künftig das Projekt hochladen will?
Also localhost (Ordner var/www/html/web/drupal) und Mailadresse z.B. adminmails@providerdomain.xyz
Danke für Hinweise!
LG
D.
Das SMTP-Modul einsetzen.
am 15.04.2019 - 09:15 Uhr
Das SMTP-Modul einsetzen. Dort definierst Du den Server, den User und das Passwort, unter dem die Mail abgeschickt werden soll. Du kannst da also eine Deiner Mailadressen mutzen.