Was ist Host Header Injection?

Der HTTP-Header Host nennt den Zielhost einer Anfrage und ermöglicht mehreren Websites dieselbe IP-Adresse. HTTP/2 und HTTP/3 transportieren dieselbe Information sinngemäß in :authority. Host Header Injection entsteht, wenn Proxy oder Anwendung einen vom Client kontrollierten Host für sicherheitsrelevante URLs, Routing, Cache oder Vertrauensentscheidungen verwendet.

Welche Funktion hat der Host Header?

Ein Webserver wählt anhand des Hosts den virtuellen Server, TLS-Konfigurationen greifen zuvor meist auf SNI zurück. Frameworks verwenden den Host außerdem, um absolute Links und Weiterleitungen zu erzeugen. Hinter Reverse Proxies kommen Header wie X-Forwarded-Host oder Forwarded hinzu. Diese Werte sind nur vertrauenswürdig, wenn ein bekannter Proxy sie selbst setzt und clientseitige Varianten zuverlässig entfernt.

Wie wird er missbraucht?

Bei einer Passwort-zurücksetzen-Funktion erzeugt die Anwendung beispielsweise https://{Host}/reset?token=.... Akzeptiert sie attacker.example, versendet sie einen gültigen Token in einem Link zur fremden Domain. Andere Anwendungen leiten unbekannte Hosts um, laden Assets von ihnen, wählen Mandanten oder interne Backends. Angreifer variieren Host, Port, absolute Request-Zeile sowie mehrere Forwarding-Header, um unterschiedliche Komponenten zu beeinflussen.

Welche Auswirkungen sind möglich?

Welche Rolle spielen Forwarded Header?

Ein Reverse Proxy muss den ursprünglichen Host gegebenenfalls an das Backend weitergeben. Problematisch wird eine pauschale Einstellung wie „allen Proxies vertrauen“: Ein direkter Client kann dann X-Forwarded-Host selbst bestimmen. Proxy-Ketten können Werte anhängen oder überschreiben, und Anwendung sowie WAF wählen womöglich unterschiedliche Positionen. Die Architektur muss festlegen, welcher Proxy vertrauenswürdig ist, welche Header er bereinigt und welchen einzelnen Wert das Backend verwendet.

Wie wird Host Header Injection verhindert?

1. Anfragen am ersten erreichbaren Proxy nur für ausdrücklich konfigurierte Hosts annehmen; unbekannte Hosts verwerfen.
2. Öffentliche Basis-URLs für Reset-, Einladungs- und Bestätigungslinks fest konfigurieren, nicht aus der Anfrage ableiten.
3. Forwarded Header von externen Clients entfernen und nur Werte bekannter Proxy-Adressen akzeptieren.
4. Host oder interne Hostnamen niemals als Authentifizierung oder Autorisierung verwenden.
5. Cache-Schlüssel und Mandantenzuordnung müssen den validierten kanonischen Host konsistent berücksichtigen.
6. Default Virtual Host ohne sensible Anwendung bereitstellen und direkten Backendzugriff sperren.

Codebeispiel: Reset-Link nicht aus dem Host Header bauen

Verwundbar:

$resetUrl = $request->getSchemeAndHttpHost()
    . '/password/reset?token=' . urlencode($token);

Sicherer: Eine validierte öffentliche Basis-URL wird fest konfiguriert.

$resetUrl = rtrim(config('app.url'), '/')
    . '/password/reset?token=' . urlencode($token);

Zusätzlich sollte der Edge-Proxy unbekannte Hosts verwerfen. Eine feste Basis-URL schützt die Linkerzeugung, ersetzt aber nicht die konsistente Host-Validierung in Proxy, Anwendung und Cache.

Wie wird sie getestet?

Tester verändern Host, Port, absolute Request-URL, :authority und relevante Forwarded-Header einzeln und kombiniert. Sie beobachten Links, Redirects, Cache, E-Mails und Routing. Reset-Tests verwenden ausschließlich eigene Testkonten und kontrollierte Domains. Eine Reflexion des Hosts ist nur ein Hinweis; entscheidend ist, ob daraus ein sicherheitsrelevanter Effekt oder eine Vertrauensverletzung entsteht.