Host-Header-Injection

Was ist Host-Header-Injection?

Anwendungen erstellen Links zum Zurücksetzen von Passwörtern aus dem Host - oder X-Forwarded-Host -Header der eingehenden Anfrage, sodass der Anforderer entscheiden kann, wohin sie zeigen. Sie erstellen eine Reset-Anfrage mit einer Lookalike-Domain in X-Forwarded-Host neu, lassen die Anwendung ein echtes Token über Ihren Link senden und wiederholen es innerhalb seiner Lebensdauer, um das Konto zu besitzen. Anschließend erstellen Sie die Basis-URL aus einem konfigurierten APP_BASE_URL , anstatt Daten anzufordern, unterstützt durch eine Host-Zulassungsliste am Proxy. Die gleiche Form verbirgt sich in signierten Download-URLs und Cache-Schlüsseln.

Was Sie lernen in Host-Header-Injection

• <code>req.headers.host</code> als nicht vertrauenswürdige Eingabe erkennen: Der Header bezeichnet die Behauptung des Aufrufers, wohin er die Anfrage gesendet hat, nicht die Identität der Anwendung
• Die Lösung mit einer konfigurierten Konstante anwenden: URLs aus <code>process.env.APP_BASE_URL</code> bauen (je Umgebung in der Deployment-Konfiguration gesetzt), niemals aus von der Anfrage abgeleiteten Werten
• Mit einer strikten Host-Header-Allowlist auf Framework- oder Proxy-Ebene ergänzen, damit jede andere Aufrufstelle, die den Header weiterhin liest, gehärtet ist
• Jede Stelle, die URLs baut, auf dasselbe Anti-Pattern prüfen: E-Mail-Vorlagen, signierte Download-URLs, Weiterleitungen, Cache-Keys und E-Mail-Fußzeilen
• Verinnerlichen: Ein Angreifer kontrolliert Anfrage-Header, ein Betreiber kontrolliert die Deployment-Konfiguration; sicherheitsrelevante URL-Basen gehören auf die Seite des Betreibers

Host-Header-Injection — Trainingsschritte

1. Die Reset-Funktion nutzen

   Bob hat es auf Verdanta-Konten abgesehen. Die App verwaltet persönliche Finanzen; jedes Konto, das er übernimmt, verschafft ihm direkten Zugriff auf echte Bankguthaben. Er kennt kein Passwort, also beginnt er dort, wo er keines braucht: auf der Seite zum Zurücksetzen vergessener Passwörter. Zunächst sendet er eine Anfrage mit einer eigenen Wegwerfadresse, um genau zu beobachten, welche Anfrage die Seite ausführt.

2. Den Endpunkt ermitteln

   Die Anfrage wurde gesendet und vom Browser aufgezeichnet. Bob öffnet das Network-Panel, um zu sehen, wohin die Seite sie tatsächlich geschickt hat.

3. Das Body-Schema prüfen

   Eine Anfrage verrät Bob alles Nötige. Er prüft, was die Seite in den Body der Anfrage geschrieben hat.

4. Die Reset-Anfrage fälschen

   Bob erstellt dieselbe Anfrage im API Tester neu. Dort kann er etwas hinzufügen, das ein Browserformular nie setzen lässt: einen gefälschten Host-Header. Er fordert einen Reset für Alices echtes Konto an, teilt der Anwendung jedoch mit, die Anfrage sei bei account-verdanta.app eingegangen – einer Lookalike-Domain, die er registriert und kontrolliert (beachten Sie .app; die echte Website von Verdanta lautet account.verdanta.com). Baut die Anwendung den Reset-Link aus dem Header, enthält Alices E-Mail seine Domain und ihr echtes Token.

5. Die Antwort verrät nichts

   Die API antwortet mit einem einfachen 200 und einer allgemeinen Nachricht. Nichts in der Antwort deutet darauf hin, dass etwas schiefgelaufen ist; genau deshalb bleibt dieser Fehler unbemerkt. Der Schaden steckt nicht in der Antwort, die Bob sehen kann. Er steckt in der E-Mail, die jetzt in Alices Posteingang liegt und einen Link enthält, der mit seiner Domain beginnt.

6. Eine Passwort-Reset-E-Mail

   Nach Feierabend erhält Alice eine Passwort-Reset-E-Mail von Verdanta. Sie hat keine angefordert, doch sie sieht genauso aus wie die echte: gleicher Absender, gleicher Wortlaut, gleiches Layout.

7. Den Reset-Link anklicken

   Alice klickt auf den Link, um ihr Passwort zurückzusetzen – genau wie jede andere Person auch.

8. Die Adressleiste prüfen

   Die Reset-Seite öffnet sich. Sie sieht aus wie Verdanta, doch die Adressleiste erzählt eine andere Geschichte.

9. Das Token abfangen

   Alices Klick hat Verdanta nie erreicht. Ihr Browser hat account-verdanta.app geöffnet, den von Bob kontrollierten Server, und das Reset-Token stand in der URL. Auf seinem eigenen Rechner verfolgt Bob das Access-Log dieses Servers, um abzufangen, was gerade eingetroffen ist.

10. Das Token erneut einsetzen

    Das Token gehört Alice, liegt jetzt aber in Bobs Händen. Bei Reset-Token ist es unerheblich, wer sie vorlegt. Bevor es abläuft, setzt er es gegen den echten Endpunkt ein und vergibt ein Passwort seiner Wahl.