Host

Verwendung

Jede HTTP/1.1-Anfrage enthält einen Host-Header. Der Header ermöglicht virtuelles Hosting, bei dem ein einzelner Server mit einer IP-Adresse mehrere Domains beherbergt. Ohne Host hat der Server keine Möglichkeit zu bestimmen, welche Domain der Client erreichen wollte.

Der Wert enthält den angeforderten Hostnamen und eine optionale Portnummer, getrennt durch einen Doppelpunkt. Wird kein Port angegeben, gilt der Standardport des Schemas: Port 80 für HTTP und Port 443 für HTTPS.

Ein Server, der eine HTTP/1.1-Anfrage ohne Host-Header empfängt, antwortet mit 400 Bad Request. Dieselbe Antwort gilt, wenn eine Anfrage mehr als einen Host-Header enthält, da die Mehrdeutigkeit den Server daran hindert, den korrekten virtuellen Host auszuwählen.

In HTTP/2 und HTTP/3 ersetzt das Pseudo-Header-Feld :authority den Host-Header. Clients, die HTTP/2- oder HTTP/3-Anfragen senden, legen die Host-Information stattdessen in :authority ab. Wandelt ein Gateway eine HTTP/2-Anfrage in HTTP/1.1 um, erzeugt das Gateway den Host-Header aus dem Wert von :authority.

Der Host-Header unterscheidet sich vom Origin-Header. Host identifiziert bei jeder Anfrage den Zielserver. Origin identifiziert die Quelle einer Cross-Origin-Anfrage und erscheint nur in bestimmten Zusammenhängen wie CORS-Preflight-Anfragen und Formularübermittlungen.

host

Der Domainname oder die IP-Adresse des Zielservers.

port

Eine optionale TCP-Portnummer. Wird sie weggelassen, wird der Standardport des Anfrageschemas angenommen (80 für HTTP, 443 für HTTPS).

Host: <host>:<port>

Beispiel

Eine normale HTTPS-Anfrage an einen Webserver lässt den Port weg, weil 443 der Standard für HTTPS ist.

GET /articles/http-headers HTTP/1.1
Host: example.re

Läuft ein Server auf einem nicht standardmäßigen Port, wird die Portnummer hinter dem Hostnamen angegeben.

GET /api/status HTTP/1.1
Host: api.example.re:8443

Eine Anfrage an eine IP-Adresse enthält die Adresse direkt. Diese Form ist in Entwicklungsumgebungen und bei internen Diensten verbreitet.

GET /health HTTP/1.1
Host: 192.168.1.100:3000

Sicherheit

Host-Header-Injection tritt auf, wenn Anwendungen den Host-Wert zur Erzeugung von URLs verwenden (Links zum Zurücksetzen von Passwörtern, kanonische URLs, Weiterleitungen), ohne den Wert zuvor zu validieren. Ein Angreifer sendet eine Anfrage mit einem gefälschten Host-Wert und bringt die Anwendung dazu, Links zu erzeugen, die auf eine von ihm kontrollierte Domain verweisen.

Validieren Sie den Host-Header gegen eine Whitelist erwarteter Werte. Definieren Sie in nginx server_name mit einem standardmäßigen Auffang-Serverblock, der 444 zurückgibt. Setzen Sie in Django ALLOWED_HOSTS auf die Liste der zugelassenen Domains. Konfigurieren Sie in Rails host_authorization in der Anwendungsumgebung. Browser behandeln Host als verbotenen Anfrage-Header und verhindern so, dass clientseitiges JavaScript den Wert verändert, doch Server-zu-Server-Anfragen und Werkzeuge wie curl unterliegen dieser Einschränkung nicht.