Was sind HTTP-Host-Header-Angriffe?

HTTP-Host-Header-Angriffe sind zu einer gängigen Technik für Angreifer geworden und es gibt mehrere Varianten. Bevor wir uns näher mit den Angriffen und ihren Möglichkeiten befassen, wollen wir zunächst klären, was ein HTTP-Host-Header ist.

Was ist der HTTP-Host-Header?

Der HTTP-Host-Header stellt Host- und Portinformationen bereit und soll Origin-Servern helfen, zu bestimmen, welche Ressourcen verwendet werden sollen, wenn sie Service-Anforderungen für mehrere Domains verarbeiten.

Andere Host-Header

Manchmal ergänzen Apps den Host-Header mit zusätzlichen Host-ähnlichen Headern wie „X-Forwarded-Host“, „X-Host“ und anderen Varianten. Wir werden diese in einigen der folgenden Angriffsbeschreibungen verwenden, da sie bei unsachgemäßer Verwendung auf die gleiche Weise anfällig sind wie der Host-Header.

Die Arten von HTTP-Host-Header-Angriffen

Der Host-Header ist ein wichtiger Bestandteil der Internetnutzung, aber Anwendungen werden anfällig für Sicherheitslücken, wenn der Host-Header implizit als vertrauenswürdig eingestuft, für zusätzliche Funktionen verwendet oder falsch konfiguriert wird. Angreifer können dieses Verhalten instrumentalisieren, indem sie verschiedene Arten von Inhalten in den Host-Header einfügen, was zu schwerwiegenderen Sicherheitslücken führen kann, darunter:

Host-Header-Vergiftung
Web-Cache-Poisoning
Passwort-Reset-Poisoning
Server-Side Request Forgery

Je nachdem, wie eine Anwendung die vom Host-Header bereitgestellten Werte verwendet, könnten dadurch auch andere Angriffe wie Cross-Site-Scripting oder SQL-Injection ermöglicht werden, genau wie jede andere vom Nutzer bereitgestellte Eingabe, wenn sie nicht sicher verarbeitet wird. Gehen wir zunächst davon aus, dass Sie den Host-Header nicht in rohen SQL-Queries verwenden, und befassen wir und mit den direkteren Angriffen.

1. Host-Header-Poisoning

In den einfachsten Fällen kann eine Anwendung den Host-Header-Wert verwenden, um Traffic umzuleiten, z. B. auf die Anmeldeseite der Anwendung. Wenn die Anwendung den Host-Header verwendet, um den Umleitungslink zu erstellen, kann ein Angreifer die folgende HTTP-Anforderung senden:

GET / HTTP/1.1
Host: www.attackers-domain.example.com

Und eine Antwort generieren, die auf seine kontrollierte Domain umleitet:

HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php

An sich ist dieser Angriff nicht sehr nützlich, da es schwierig ist, einen ins Visier genommenen Nutzer dazu zu bringen, diese Anfrage zu stellen. Allerdings kann Host-Header-Poisoning mit anderen Angriffen kombiniert werden, um seine Effektivität zu steigern.

2. Web-Cache-Poisoning

Web-Cache-Poisoning ist keine Host-Header-Schwachstelle im eigentlichen Sinne, sondern ein Bereitstellungsmechanismus, der das bereits erwähnte Host-Header-Poisoning ausnutzbar macht. Nehmen wir an, eine Anwendung verwendet nicht den Host-Header, um ihre Umleitungslinks zu erstellen (gut!), sondern stattdessen einen alternativen Header wie X-Host (schlecht!). In diesem Szenario kann ein Angreifer seine Domain in X-Host injizieren, um den Redirect zu manipulieren; jedoch benötigt er immer noch eine Möglichkeit, diesen Redirect an die Nutzer auszuliefern.

Hier kommt das Web-Cache-Poisoning ins Spiel. Web-Caches verwenden typischerweise Teile einer HTTP-Anfrage als „Schlüssel“, um zu bestimmen, wann Cache-Inhalte verwendet werden sollen, anstatt die Anforderung an den Origin-Server zu senden. Dieser Schlüssel beinhaltet in der Regel den Host-Header und kann auch andere Header enthalten. In unserem Beispiel, wenn X-Host nicht Teil des Cache-Schlüssels ist, aber unsicher in der Antwort verwendet wird (wie in unserem Redirect-Beispiel), können Angreifer den Cache verwenden, um anderen Nutzern ihre bösartige Umleitung auszuliefern. Der Angreifer findet dann einen Weg, seine Anforderung im Cache zu speichern, um sie an andere Nutzer auszuliefern.

Sehen wir uns ein Beispiel für Web-Cache-Poisoning an. Zuerst lässt der Angreifer die folgende Anfrage im Cache speichern, die seine bösartige Domain im X-Host-Header enthält und in einem Redirect verwendet wird:

GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com

X-Host: www.attackers-domain.example.com

Ein gutartiger Nutzer beschließt dann, die Anwendung zu besuchen, und sendet eine normale Anfrage:

GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.super-cool-fun-domain.example.com

Angenommen, die Anfrage des Angreifers wurde basierend auf dem Pfad und dem Host-Header gecacht, erhält der gutartige Nutzer nun die manipulierte gecachte Antwort, die ihn auf die Seite des Angreifers umleitet:

HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php

Web-Cache-Poisoning-Angriffe beruhen auf der Diskrepanz zwischen Headern, die als Cache-Schlüssel verwendet werden, und Headern, die von der Anwendung zur Formulierung von Antworten verwendet werden. Im obigen Beispiel bot der X-Header eine Möglichkeit, gecachte Antworten zu manipulieren, indem Nutzer anstelle der eigentlichen Anwendung auf eine bösartige Website umgeleitet wurden.

3. Passwort-Reset-Poisoning

Passwort-Reset-Poisoning ist dem vorherigen Host-Header-Poisoning sehr ähnlich, da die anfällige Anwendung den Host-Header verwendet, um den Link zum Zurücksetzen des Passworts zu erstellen, der während des Reset-Workflows an den angeforderten Nutzer gesendet wird. Zum Beispiel könnte ein Angreifer die folgende POST-Anfrage senden, um ein Zurücksetzen des Passworts für den Nutzer „alice“ zu beantragen:

POST /password-reset HTTP/1.1
Host: www.attackers-domain.example.com
...

user=alice

Die Anwendung verwendet den Wert aus dem Host-Header, um den Reset-Link zu erstellen, und sendet eine E-Mail mit dem Link an den Nutzer „alice“:

www.attackers-domain.example.com?reset_token=super-random-reset-token-value-12345

Wenn der Nutzer auf den Link klickt, erfasst der Angreifer das Reset-Token und kann das Passwort des Nutzers auf seinen eigenen Wert zurücksetzen.

4. Server-Side Request Forgery

Server-Side Request Forgery (SSRF) ist eine Sicherheitslücke, die es einem Angreifer ermöglicht, die serverseitige Anwendungsanfrage an einen beliebigen Standort zu senden. Bei einer Host-Header-SSRF nutzt der Angreifer das Routing aus, das von Systemen zwischen dem Nutzer und der serverseitigen Anwendung verwendet wird. Wenn diese Middleware (z. B. ein Loadbalancer) anfällig für Host-Header-SSRF ist, kann der Angreifer dies möglicherweise nutzen, um mit internen Systemen zu interagieren, auf die er sonst keinen Zugriff hätte. Eine gängige Methode, dies zu testen, besteht darin, eine eindeutige, kontrollierte Domain (z. B. den Burp Collaborator von Portswigger oder interactsh von ProjectDiscovery) in den Host-Header-Wert einzufügen. Wenn diese eindeutige Domain während eines Host-Header-Angriffs eine DNS-Abfrage oder eine andere Anfrage von einem System im Netzwerkpfad der Zielanwendung (z. B. dem Loadbalancer) erhält, könnte sie anfällig für SSRF sein. Diese Angriffe sind in der Praxis meist komplex, haben aber auch verheerende Folgen, wie die Forschung von James Kettle ausführlich zeigt.

Beispiele aus der Praxis für HTTP-Host-Header-Angriffe

Nun, da Sie die Arten von Host-Header-Angriffen kennen, werfen wir einen Blick auf einige Beispiele aus der Praxis.

CVE-2022-29933: Passwort-Reset-Poisoning in Craft CMS

SEC Consult stellte fest, dass die Standardinstallation von Craft CMS E-Mails zum Zurücksetzen des Passworts unter Verwendung des Werts des HTTP-Headers „X-Forwarded-Host“ erstellt. In diesem Beispiel injiziert ein Angreifer seine kontrollierte Domain in den X-Forwarded-Host, um den Link zum Zurücksetzen des Passworts für den Nutzer „alice“ wie folgt zu vergiften:

POST /index.php?p=admin/actions/users/send-password-reset-email HTTP/1.1
Host: <installation-domain>
X-Forwarded-Host: www.attackers-domain.example.com
...
Cookie: CRAFT_CSRF_TOKEN=[...]

loginName=alice@example.com

Wenn der Nutzer alice@example.com seine E-Mail zum Zurücksetzen des Passworts erhält, enthält sie einen Link zu einer vom Angreifer kontrollierten Domain:

http://www.attackers-domain.example.com/index.php?p=admin/set-password&code=<reset-code>&id=<uuid>

Wenn der Nutzer dem Link folgt, hat der Angreifer jetzt den Reset-Code des Nutzers erfasst und kann das Passwort zurücksetzen, um das Konto zu übernehmen.

Dieser Angriff umgeht die schwache X-Forwarded-Host-Validierung, um blindes SSRF auf files.slack.com zu ermöglichen. Zuerst versucht files.slack.com, den Host-Header und den X-Forwarded-Host-Header während der Verarbeitung zu validieren und gibt einen HTTP 500-Antwortcode zurück, wenn sie nicht files.slack.com sind. Die X-Forwarded-Host-Validierung kann jedoch umgangen werden, indem ein @-Zeichen an das Ende der Domain angehängt wird. Der Angreifer richtet also eine Callback-Domain ein, um Anfragen abzufangen (z. B. mit Burp Collaborator oder interactsh von ProjectDiscovery) und sendet die folgende Anfrage an files.slack.com:

GET /<URI> HTTP/1.1
Host: files.slack.com
...
X-Forwarded-Host: files.slack.com@www.unique-attackers-domain.example.com

Die URL files.slack.com in der aus dem X-Forwarded-Host-Header erstellten URL wird als HTTP-Nutzer (HTTP BasicAuth) behandelt, und www.unique-attackers-domain.example.com wird als Hostname behandelt. Der Angreifer erhält eine Anfrage von einem Backend-System, die das erfolgreiche SSRF bestätigt. Von hier aus können verschiedene Blind-SSRF-Techniken verwendet werden, um Informationen offenzulegen, mit Backend-Systemen zu interagieren und mehr.

So verhindern Sie HTTP-Host-Header-Angriffe

Es gibt mehrere Möglichkeiten, HTTP-Host-Header-Angriffe zu verhindern, die sich in ihrer Wirksamkeit und ihren Nachteilen unterscheiden. Im Folgenden finden Sie umsetzbare Lösungen, um diese Art von Angriff zu verhindern.

Vermeiden Sie die Verwendung des Host-Header-Werts und seiner Varianten im Anwendungscode

Der einfachste Weg, Host-Header-Angriffe zu verhindern, besteht darin, die Verwendung des Host-Header-Werts in Ihrem Anwendungscode zu vermeiden. Zusätzlich werden Host-Header-Angriffe vollständig vereitelt, wenn stattdessen serverseitige Konfigurationen oder relative URLs verwendet werden.

Führen Sie eine strikte Validierung der Host-Header-Werte durch

Falls Sie den Host-Header-Wert verwenden müssen, sollten die folgenden Techniken angewendet werden, um Host-Header-Angriffe zu verhindern:

Überprüfen Sie, ob der Host-Header in einer Liste von zulässigen Werten enthalten ist. Wenn Ihre Anwendung beispielsweise nur drei Domains verwendet, stellen Sie sicher, dass der Host-Header nur einer dieser drei Werte ist.
Stellen Sie sicher, dass nur ein Host-Header vorhanden ist. Doppelte Host-Header können manchmal verwendet werden, um die Validierung zu umgehen, wenn die Validierung und die Verwendung des Headers dazu führen, dass unterschiedliche Werte aus der Anfrage abgerufen werden.
Vermeiden Sie die Verwendung von Host-Header-Alternativen und -Überschreibungen wie X-Host oder X-Forwarded-Host, und wenn es notwendig ist, befolgen Sie die gleichen Empfehlungen wie für den Host-Header.

So trägt Fastly dazu bei, HTTP-Host-Header-Angriffe zu verhindern

Befolgen Sie die Anleitung von Fastly zur Verhinderung von Cache-Poisoning, um sicherzustellen, dass zusätzliche Schutzmaßnahmen vorhanden sind.

Wenn Sie die Fastly Web Application Firewall (WAF) der nächsten Generation verwenden, können Sie zusätzliche Schutzmaßnahmen hinzufügen, um sich vor HTTP-Host-Header-Angriffen zu schützen und alle Anfragen mit ungültigen Host-Headern zu blockieren (z. B. solche, die nicht in Ihrer Liste der zulässigen Domains stehen).

Zusammenfassung

Der Host-Header ist ein wesentlicher Bestandteil des Internets (und von Fastly), aber wenn dem Host-Header implizit vertraut wird, er für zusätzliche Funktionen genutzt oder falsch konfiguriert wird, können Angreifer dieses Verhalten ausnutzen, indem sie verschiedene Arten von schädlichen Inhalten einschleusen. Dies kann mehrere Arten von Angriffen ermöglichen, darunter Host-Header-Poisoning, Web-Cache-Poisoning, Passwort-Reset-Poisoning und Server-Side Request Forgery (SSRF). Mit den von uns beschriebenen Lösungen in Kombination mit den Anleitungen von Fastly zur Vermeidung von Cache-Poisoning können Anwendungen Varianten von Host-Header-Angriffen verhindern.

Erfahren Sie mehr über die Sicherheitsfunktionen von Fastly.

Demo anfordern