EN

HTTP-Host-Header-Angriff: Erläuterung und Beispiele

In diesem Artikel:

Um die Host-Header-Injektion zu verstehen, müssen wir uns zunächst ansehen, was ein Host-Header ist, wie er funktioniert und wie er manipuliert werden kann, um bösartige Inhalte einzuschleusen, Web-Caches zu vergiften, Passwörter zurückzusetzen und vieles mehr. 

Im Folgenden erfahren Sie, was Sie über den Host-Header und diesen Injektionsangriff wissen müssen.

Was ist ein HTTP-Host-Header?

Der HTTP-Host-Header ist ein Anfrage-Header, der die Domäne angibt, auf die ein Client (Browser) zugreifen möchte. Dieser Header ist notwendig, weil es für Server ziemlich normal ist, Websites und Anwendungen unter derselben IP-Adresse zu hosten. Sie wissen jedoch nicht automatisch, wohin die Anfrage zu richten ist. 

Wenn der Server eine Anfrage erhält, prüft er den Parameter des Host-Headers, um festzustellen, welche Domäne die Anfrage bearbeiten muss, und leitet sie dann weiter. Manchmal kann der Header bei der Weiterleitung an die entsprechende Domäne geändert werden. In diesem Fall kann die Host Header Injection auftreten.

Der Grund dafür, dass viele Websites unter einer IP-Adresse gehostet werden, ist zum einen die Erschöpfung der verfügbaren IPv4-Adressen und zum anderen die Beliebtheit von Cloud-Hosting.

Es gibt zwei Arten, über die mehrere Websites unter derselben IP-Adresse zugänglich sind. Zum einen sind dies die Fälle, in denen ein virtueller Host oder zum anderen ein zwischengeschaltetes System vorhanden ist. 

Virtueller Host 

Wenn mehrere Websites oder Anwendungen auf einem Server gehostet werden, spricht man von virtuellem Hosting. Der Server hat in diesem Szenario eine einzige IP-Adresse, und die eingehenden Anfragen werden an die entsprechenden Domänen weitergeleitet. 

Zwischengeschaltete Systeme

Alternativ dazu können mehrere Websites unter einer IP-Adresse zu finden sein, wenn zwischengeschaltete Systeme verwendet werden. In diesem Fall kann sich eine Website auf einem separaten Server befinden, der Zugriff erfolgt jedoch über einen Vermittler, z. B. einen Reverse-Proxy-Server, ein Content Delivery Network (CDN), ein Web-Syndikat oder eine andere Form der Verkehrsumleitung. 

Aus ähnlichen Gründen wie oben muss der Vermittler wissen, wohin er eingehende Anfragen weiterleiten soll.

Was ist die Funktion des HTTP-Host-Headers?

Da Websites und Anwendungen keine eigenen IP-Adressen haben, besteht der Zweck des Host-Headers darin, dem Server Informationen über den richtigen Empfänger der Anfrage zu liefern, der sich in einem nachgeordneten Bereich befindet. 

Der Host-Header gibt an, welche beim Server gehostete Domäne (Back-End) die Anfrage des Clients empfangen und verarbeiten soll, und der Server leitet sie entsprechend weiter. Der Server leitet die Anfrage entsprechend weiter. Das Back-End antwortet dann auf demselben Weg auf die Anfrage, da es nicht weiß, wie die Anfrage in das Netzwerk gelangt ist.

Beispiel für den HTTP-Host-Header

Wenn Sie zum Beispiel unsere Blog-Hauptseite aufrufen möchten, würde die Anfrage den folgenden Host-Header enthalten:

GET /security-penetration-testing-blog HTTP/1.1
Host: www.crashtest-security.com

Was passiert nun, wenn der Host-Header in der Anfrage fehlerhaft ist? Leider sind die meisten Server so konfiguriert, dass sie bei Anfragen, die keinen erkennbaren Host-Header haben, den ersten virtuellen Host (d. h. eine Standard-Website) verwenden. 

Da der Host-Header benutzergesteuert ist, ist es möglich, Anfragen mit beliebigen Host-Headern an den ersten virtuellen Host eines beliebigen Servers zu senden. Dies ist möglich, weil es keine Möglichkeit gibt, zu überprüfen, ob die im Host-Header enthaltene Domäne mit der IP-Adresse übereinstimmt, die Teil des anfänglichen Transmission Control Protocol (TCP) Handshake ist. Somit kann jeder, der die eingehende Anfrage manipulieren kann, den Host-Header verfälschen.

Dies öffnet Tür und Tor für Host-Header-Injektionen, die das serverseitige Verhalten manipulieren und dem Benutzer bösartige Inhalte liefern.

Was sind Host-Header-Injektionen?

Eine Host-Header-Injection nutzt die Schwachstelle einiger Websites aus, Host-Header wahllos zu akzeptieren, ohne sie zu validieren oder ganz zu umgehen. 

Dies ist gefährlich, da viele Anwendungen auf den Host-Header angewiesen sind, um Links zu generieren, Skripte zu importieren, die richtige Umleitungsadresse zu ermitteln, Links zum Zurücksetzen von Passwörtern zu erzeugen usw. Wenn eine Anwendung also den Host-Header abruft, kann es passieren, dass sie bösartige Inhalte in der Antwort ausliefert, die dort eingefügt wurden.

Ein Beispiel wäre eine Anfrage zum Abrufen Ihrer E-Banking-Webseite: https://www.your-ebanking.com/login.php.

Wenn es dem Angreifer gelingt, den Host-Header in der Anfrage zu manipulieren und ihn in https://www.attacker.com/login.php zu ändern, könnte diese gefälschte Website den Benutzern angezeigt werden und sie dazu verleiten, ihre Anmeldedaten einzugeben. 

Die obige Darstellung ist ein grobes Beispiel dafür, wie ein Host-Header eingeschleust werden könnte. Eine erfolgreiche Host-Header-Injektion kann zu Web-Cache-Poisoning, Passwort-Reset-Poisoning, Zugriff auf interne Hosts, Cross-Site-Scripting (XSS), Umgehung der Authentifizierung, Brute-Force von virtuellen Hosts und vielem mehr führen!

Im Folgenden werden die beiden wichtigsten Szenarien für HTTP-Host-Header-Injection beschrieben.

Web-Cache-Vergiftung

Web-Cache-Vergiftung liegt vor, wenn ein Angreifer einen Caching-Proxy-Server oder andere Zwischensysteme manipulieren kann, die von einer Website bedient werden. 

Zu diesem Zweck muss der Angreifer zunächst den Proxy selbst vergiften. Ist dies gelungen, kann er unerwartete Benutzer, die nach einer bestimmten Website suchen, abfangen und ihnen eine gefälschte Website anbieten. 

Je nach Fall geschieht dies durch Änderung des Host-Headers, durch Verwendung mehrerer Host-Header oder durch Verwendung des X-Forwarded-Host-Headers. Letzteres wird verwendet, wenn eine Anwendung Host-Header zurückweist, die manipuliert wurden. Im Grunde sind dies nur verschiedene Ansätze, um das Ziel zu erreichen, vergiftete Inhalte zu liefern.

Wenn Benutzer erfolgreich getäuscht werden, führen sie möglicherweise Skripte aus, die Tür und Tor für andere Angriffe öffnen.

Kompromittierung der Passwortrücksetzung

Eine weitere Auswirkung, die eine Host-Header-Injection haben kann, ist die Kompromittierung der Passwort-Reset-Funktion. Dadurch können sie Benutzer dazu verleiten, auf einen Link zum Zurücksetzen zu klicken und dann ihr neues Kennwort zurückzusetzen und zu erfassen. Um dieses Problem zu verstehen, ist es notwendig, den Unterschied zwischen relativen und absoluten URLs zu kennen.

Relative und absolute URLs

In den meisten Fällen müssen Websites und Anwendungen die Domäne, unter der sie betrieben werden, nicht kennen und geben daher relative URLs anstelle von absoluten URLs an. Relative URLs sind aus Sicht der Entwicklung die bessere Wahl und bieten mehr Sicherheit.

In bestimmten Fällen ist jedoch eine absolute URL erforderlich, z. B. wenn Links als Antwort auf eine Anforderung zum Zurücksetzen des Kennworts erstellt werden. Darüber hinaus ist eine absolute URL erforderlich, weil die Benutzer von außen auf die Website zugreifen und daher die vollständige Domänenadresse kennen müssen. 

Wenn eine Webanwendung den Host-Header verwendet, um den Link zum Zurücksetzen des Kennworts zu generieren, besteht die Möglichkeit, dass sie den Benutzern einen manipulierten Link liefert, wenn der Host-Header manipuliert wurde. Wenn die Benutzer den Link nicht weiter beachten und die Website so aussieht, wie sie es erwarten, könnten sie ihre Anmeldedaten unabsichtlich an einen Angreifer weitergeben. 

Schwachstellen in der Kopfzeile des Hosts

Schwachstellen in Host-Headern können aus verschiedenen Gründen auftreten. Erstens gibt es selbst bei sorgfältiger Handhabung des Host-Headers Möglichkeiten, den Host zu überschreiben und eine Injektion durchzuführen. Viele Schwachstellen sind auf Standardkonfigurationsoptionen auf der Serverseite zurückzuführen oder darauf, dass Komponenten von Drittanbietern integriert werden, die nicht ordnungsgemäß abgesichert sind. 

Häufige Gründe für diese Art von Injektionsangriffen sind:

  • Server, die aufgrund einer Standard- oder Fallback-Option beliebige oder fehlerhafte Host-Header akzeptieren
  • Fehlerhafte Domain-Validierung, die es Angreifern ermöglicht, den Port zu manipulieren oder eine beliebige Subdomain einzufügen
  • Zweideutige Anfragen, die doppelte Host-Header, absolute URLs in der Anfragezeile zusammen mit einem Host-Header, eingerückte Header usw. enthalten
  • Geschmuggelte HTTP-Anfragen 
  • Eingefügte Override-Header wie X-Host, X-Forwarded-Server und andere

Wie lassen sich Host-Header-Angriffe verhindern?

Je nach Art Ihrer Konfiguration gibt es verschiedene Möglichkeiten, Host-Header-Injektionen zu verhindern. Der einfachste Ansatz besteht natürlich darin, dem Host-Header stets zu misstrauen und ihn nicht in serverseitigem Code zu verwenden. Diese einfache Änderung kann die Möglichkeit eines Host-Header-Angriffs auf Sie im Wesentlichen ausschließen. 

Dies ist jedoch nicht immer möglich, und wenn Sie den Host-Header verwenden müssen, sollten Sie die folgenden Maßnahmen in Betracht ziehen.

Verwenden Sie so oft wie möglich relative URLs.

Überlegen Sie zunächst, ob Ihre absoluten URLs unerlässlich sind. Oftmals ist es möglich, stattdessen relative URLs zu verwenden.

Wenn Sie bestimmte absolute URLs verwenden müssen, z. B. für Transaktions-E-Mails, muss die Domäne in der serverseitigen Konfigurationsdatei angegeben und von dort übernommen werden. Dadurch wird die Möglichkeit des Passwort-Reset-Poisoning ausgeschlossen, da bei der Erzeugung eines Tokens nicht auf den Host-Header verwiesen wird. 

Host-Header validieren

Benutzereingaben müssen immer als unsicher angesehen werden und sollten zuerst validiert und bereinigt werden. Eine Möglichkeit, Host-Header bei Bedarf zu validieren, besteht darin, eine Whitelist zulässiger Domänen zu erstellen und Host-Header in eingehenden Anfragen mit dieser Liste zu vergleichen. Hosts, die nicht erkannt werden, sollten zurückgewiesen oder umgeleitet werden.

Wie man eine solche Whitelist implementiert, ist in der entsprechenden Dokumentation des Frameworks nachzulesen. 

Bei der Validierung von Host-Headern müssen Sie auch feststellen, ob die Anfrage vom ursprünglichen Zielhost stammt oder nicht.

Whitelist vertrauenswürdiger Domains

Bereits in der Entwicklungsphase sollten Sie eine Whitelist aller vertrauenswürdigen Domänennamen erstellen, von denen Ihr Reverse Proxy, Load Balancer oder andere Zwischensysteme Anfragen weiterleiten dürfen. Dies hilft Ihnen, Routing-basierte Angriffe wie z. B. Server-Side Request Forgery (SSRF) zu verhindern.

Domänenzuordnung implementieren

Ordnen Sie jeden Ursprungsserver zu, an den der Proxy Anfragen weiterleiten soll, d. h. ordnen Sie Hostnamen Websites zu.

Ablehnung von Override-Headern

Host-Override-Header, wie z. B. X-Host und X-Forwarded-Host, werden häufig für Header-Injections verwendet. Server unterstützen diese Header manchmal standardmäßig, daher ist es wichtig, sich zu vergewissern, dass dies nicht der Fall ist.

Vermeiden Sie die Verwendung von rein internen Websites unter einem virtuellen Host

Host-Header-Injektionen können verwendet werden, um auf interne (private) Domänen zuzugreifen. Vermeiden Sie dieses Szenario und hosten Sie keine öffentlichen und privaten Websites auf demselben virtuellen Host. 

Erstellen Sie einen virtuellen Dummy-Host

Wenn Sie Apache oder Nginx verwenden, können Sie einen virtuellen Dummy-Host erstellen, um Anfragen von nicht erkannten Host-Headern (d. h. gefälschte Anfragen) abzufangen und Cache Poisoning zu verhindern.

Korrigieren Sie Ihre Serverkonfiguration

Host-Header-Injektionen sind häufig auf Standardeinstellungen, fehlerhafte oder alte Serverkonfigurationen zurückzuführen. Die Überprüfung und Korrektur Ihrer Serverkonfiguration kann erhebliche Schwachstellen beseitigen, die Tür und Tor für Injektionen öffnen.

Häufig gestellte Fragen

Was ist eine Host-Header-Injektion?

Die HTTP-Host-Header-Injection ist ein Angriff, bei dem ein böswilliger Akteur den Host-Header in einer Client-Anfrage manipuliert. Dadurch wird der virtuelle Host oder das zwischengeschaltete System dazu verleitet, dem Client in der Antwort manipulierte Inhalte zu liefern.

Sind Host-Header-Angriffe gefährlich?

Host-Header-Injektionen können potenziell gefährlich sein, da sie zu einem kompromittierten Web-Cache oder einer manipulierten Passwort-Rücksetzfunktion führen können. Glücklicherweise lassen sie sich mit der richtigen Serverkonfiguration leicht verhindern.

Wie lassen sich Host-Header-Angriffe vermeiden?

Am wichtigsten ist, dass Sie Host-Headern überhaupt nicht oder nur nach vorheriger Überprüfung vertrauen. Wenn Sie keine andere Wahl haben, als Host-Header zu verwenden, implementieren Sie eine Whitelist der zulässigen Domänen. 

Welche Risiken sind mit einer Host-Header-Injektion verbunden?

Ein erfolgreicher Host-Header-Angriff kann zu vielen verschiedenen Problemen führen, z. B. zu einem kompromittierten Web-Cache oder einem manipulierten Passwort-Reset, zu Cross-Site-Scripting- oder Server-Side-Forgery-Anfragen, SQL-Injektionen, Session-Hijacking und vielem mehr.

Testen Sie unseren automatischen HTTP-Header-Scanner

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit https://example.com
Wir scannen derzeit https://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 06/12/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.