HTTP-Header

HTTP-Proxy-Header, wie z.B. X-Forwarded-For und Via, werden von Proxy-Servern verwendet, um Informationen über den ursprünglichen Client, den Anforderungspfad und andere Kontextdaten an den Upstream-Server zu übermitteln, die sonst durch die Anwesenheit des Proxys verschleiert würden.

Wenn eine HTTP-Anforderung einen oder mehrere Proxy-Server durchläuft, sieht der unmittelbar vorgelagerte Server typischerweise die IP-Adresse des letzten Proxys, nicht die des ursprünglichen Clients. Proxy-Header beheben dies, indem sie spezifische HTTP-Header hinzufügen oder ändern, wodurch die IP, das Protokoll, der Host des ursprünglichen Clients und die Reihenfolge der Proxys an den endgültigen Zielserver kommuniziert werden können.

X-Forwarded-For

Der X-Forwarded-For (XFF)-Header ist ein De-facto-Standard-Header, der verwendet wird, um die ursprüngliche IP-Adresse eines Clients zu identifizieren, der über einen HTTP-Proxy oder Load Balancer eine Verbindung zu einem Webserver herstellt.

Zweck

Sein Hauptzweck ist es, dem Webserver den Zugriff auf die IP-Adresse des ursprünglichen Clients für Protokollierung, Analyse, Sicherheit und anwendungsspezifische Logik (z.B. IP-basierte Zugriffskontrolle, Geolokalisierung) zu ermöglichen. Ohne XFF würden alle Anforderungen so aussehen, als kämen sie von der IP-Adresse des Proxy-Servers.

Format und Beispiele

Der XFF-Header kann eine Komma-getrennte Liste von IP-Adressen enthalten. Wenn eine Anforderung mehrere Proxys durchläuft, hängt jeder Proxy die IP-Adresse des Clients, der sich mit ihm verbunden hat, an den XFF-Header an.

• X-Forwarded-For: <client>, <proxy1>, <proxy2>

Beispiel 1: Einzelner Proxy
Ein Client (192.0.2.1) verbindet sich mit einem Proxy (198.51.100.1), der sich dann mit dem Ursprungsserver verbindet.
Der Proxy fügt hinzu:

X-Forwarded-For: 192.0.2.1

Der Ursprungsserver sieht die Anforderung von 198.51.100.1 und X-Forwarded-For: 192.0.2.1.

Beispiel 2: Mehrere Proxys
Ein Client (192.0.2.1) verbindet sich mit Proxy A (198.51.100.1), der sich mit Proxy B (203.0.113.1) verbindet, der sich dann mit dem Ursprungsserver verbindet.
1. Client zu Proxy A: Proxy A fügt X-Forwarded-For: 192.0.2.1 hinzu.
2. Proxy A zu Proxy B: Proxy B empfängt X-Forwarded-For: 192.0.2.1. Proxy B hängt 198.51.100.1 daran an.
Der Header wird zu: X-Forwarded-For: 192.0.2.1, 198.51.100.1.
3. Proxy B zu Ursprungsserver: Der Ursprungsserver empfängt X-Forwarded-For: 192.0.2.1, 198.51.100.1.

In einer Kette von Proxys ist die linkeste IP-Adresse typischerweise der ursprüngliche Client. Die rechteste IP-Adresse ist die IP des unmittelbar vorgelagerten Proxys (der Client, der sich mit dem aktuellen Proxy verbunden hat).

Sicherheitsaspekte für X-Forwarded-For

Der X-Forwarded-For-Header kann von einem böswilligen Client leicht gefälscht werden. Ein Client kann eine Anforderung mit einem gefälschten X-Forwarded-For-Header senden.

GET / HTTP/1.1
Host: example.com
X-Forwarded-For: 10.0.0.1, 1.1.1.1

Wenn ein Proxy dies blind anhängt, könnte der vom Ursprungsserver empfangene Header wie X-Forwarded-For: 10.0.0.1, 1.1.1.1, <proxy_ip> aussehen.
Daher sollten nachgeschaltete Anwendungen nicht dem gesamten X-Forwarded-For-Headerwert direkt vertrauen. Die allgemein akzeptierte Praxis ist es, nur der rechtesten nicht vertrauenswürdigen IP-Adresse in der Liste als tatsächliche Client-IP zu vertrauen, nachdem alle Einträge entfernt wurden, die zu bekannten vertrauenswürdigen Proxys gehören. Viele Webserver und Anwendungsframeworks bieten Mechanismen zur Angabe einer Liste vertrauenswürdiger Proxys.

Via

Der Via-Header ist ein Standard-HTTP-Header, der die zwischengeschalteten Proxys und Gateways angibt, durch die eine Anforderung (oder Antwort) gegangen ist.

Zweck

Der Via-Header dient mehreren Zwecken:
* Nachverfolgbarkeit: Er bietet eine Spur der Proxy-Kette, nützlich zur Fehlerbehebung bei Netzwerkpfaden.
* Schleifenerkennung: Er kann helfen, Anforderungsschleifen in Proxy-Ketten zu erkennen.
* Protokollkompatibilität: Er signalisiert die von jedem zwischengeschalteten Proxy verwendeten Protokollversionen, was für Protokollkonvertierungen relevant sein kann.

Format und Beispiele

Jeder Proxy fügt seinen eigenen Via-Eintrag zum Header hinzu. Das Format für jeden Eintrag ist protocol-name/protocol-version host:port (comment). Das Feld comment ist optional und kann beliebige Informationen enthalten.

Via: <protocol-name>/<protocol-version> <host>:<port> (comment)

Beispiel:
Ein Client sendet eine Anforderung, die Proxy A (Hostname proxy-a.example.com, Port 8080) und Proxy B (Hostname proxy-b.example.com, Port 80) durchläuft.

1. Client zu Proxy A: Proxy A fügt Via: HTTP/1.1 proxy-a.example.com:8080 hinzu.
2. Proxy A zu Proxy B: Proxy B empfängt Via: HTTP/1.1 proxy-a.example.com:8080. Proxy B stellt seinen eigenen Eintrag voran.
   Der Header wird zu: Via: 1.1 proxy-b.example.com, 1.1 proxy-a.example.com:8080.
   (Hinweis: HTTP/ wird oft weggelassen, wenn es sich um HTTP handelt, und Port 80/443 kann weggelassen werden.)
3. Proxy B zu Ursprungsserver: Der Ursprungsserver empfängt den vollständigen Via-Header.

Datenschutz- und Betriebsüberlegungen

Der Via-Header legt die interne Netzwerktopologie und Hostnamen offen, was in einigen Implementierungen ein Sicherheits- oder Datenschutzrisiko darstellen könnte. Organisationen könnten sich dafür entscheiden, diesen Header für extern zugängliche Proxys zu entfernen oder zu ändern, um die Offenlegung interner Netzwerkinformationen zu verhindern.

Forwarded

Der Forwarded-Header ist ein standardisierter Header, der in RFC 7239 definiert ist und die De-facto-Header X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto ersetzen soll.

Zweck

Er bietet eine strukturiertere und erweiterbare Möglichkeit, Informationen über den ursprünglichen Client, den Proxy selbst und den ursprünglichen Anforderungskontext (Host, Protokoll) an den Upstream-Server zu übermitteln.

Format und Beispiele

Der Forwarded-Header kann einen oder mehrere Sätze von Parametern enthalten, die durch Kommas getrennt sind und jeden Proxy in der Kette repräsentieren. Jeder Satz von Parametern verwendet Schlüssel-Wert-Paare. Gängige Parameter sind:
* for: Die IP-Adresse (oder verschleierter Bezeichner) des ursprünglichen Clients.
* by: Die IP-Adresse (oder verschleierter Bezeichner) des Proxys, der die Anforderung weitergeleitet hat.
* host: Der ursprüngliche Host-Header, der vom Client angefordert wurde.
* proto: Das ursprüngliche Protokoll (z.B. http oder https), das vom Client verwendet wurde.

Forwarded: for=<client_ip>; proto=<protocol>; host=<original_host>
Forwarded: for=<client_ip>, for=<proxy_ip>; proto=<protocol>

Beispiel 1: Einzelner Proxy
Ein Client (192.0.2.1) verbindet sich über HTTPS mit einem Proxy (198.51.100.1), der example.com anfordert.
Der Proxy fügt hinzu:

Forwarded: for=192.0.2.1; proto=https; host=example.com

Beispiel 2: Mehrere Proxys
Client (192.0.2.1) -> Proxy A (198.51.100.1) -> Proxy B (203.0.113.1) -> Ursprungsserver.
1. Client zu Proxy A: Proxy A fügt Forwarded: for=192.0.2.1; proto=https; host=example.com hinzu.
2. Proxy A zu Proxy B: Proxy B empfängt den Header. Proxy B hängt seinen eigenen Eintrag an, einschließlich by, um sich selbst zu identifizieren.
Der Header wird zu:
Forwarded: for=192.0.2.1; proto=https; host=example.com, for=198.51.100.1; by=203.0.113.1
(Hinweis: Die Parameter host und proto sind typischerweise nur im ersten Eintrag für den ursprünglichen Client enthalten, es sei denn, ein Proxy führt eine Protokoll- oder Host-Umschreibung durch.)

Vergleich: X-Forwarded-For vs. Forwarded

Andere Proxy-Header

X-Forwarded-Host

Dieser De-facto-Header identifiziert den ursprünglichen Host, der vom Client im Host-HTTP-Anforderungsheader angefordert wurde. Er ist nützlich, wenn ein Proxy oder Load Balancer den Host-Header ändert (z.B. für internes Routing), bevor die Anforderung an den Upstream-Server weitergeleitet wird, die Anwendung aber den vom Client angeforderten ursprünglichen Host für Aufgaben wie das Generieren absoluter URLs oder die Handhabung virtueller Hosts kennen muss.

Beispiel:
Client fordert example.com an. Proxy leitet an internen Host app-server-1 weiter.

Host: app-server-1
X-Forwarded-Host: example.com

X-Forwarded-Proto

Dieser De-facto-Header identifiziert das Protokoll (HTTP oder HTTPS), das der Client verwendet hat, um sich mit dem Proxy oder Load Balancer zu verbinden. Dies ist entscheidend, wenn der Proxy eine SSL/TLS-Terminierung durchführt, d.h. der Client verbindet sich über HTTPS, der Proxy aber über unverschlüsseltes HTTP mit dem Backend-Server kommuniziert. Die Anwendung muss das ursprüngliche Protokoll kennen, um korrekte Links zu generieren (z.B. https:// anstelle von http://).

Beispiel:
Client verbindet sich über HTTPS mit einem Load Balancer. Load Balancer verbindet sich über HTTP mit dem Backend.

X-Forwarded-Proto: https

X-Real-IP

Dies ist ein weiterer De-facto-Header, der häufig von NGINX verwendet wird, um die IP-Adresse des ursprünglichen Clients zu übermitteln. Im Gegensatz zu X-Forwarded-For enthält er typischerweise nur eine einzige IP-Adresse – die des ursprünglichen Clients oder des unmittelbar vorgelagerten vertrauenswürdigen Proxys. Er wird oft vom ersten Proxy in einer Kette gesetzt, nachdem der X-Forwarded-For-Header validiert wurde.

Beispiel:

X-Real-IP: 192.0.2.1

Praktische Implikationen und Anwendungsfälle

Proxy-Header sind grundlegend für den ordnungsgemäßen Betrieb und die Sicherheit in modernen Webarchitekturen, die Proxys, Load Balancer und CDNs umfassen.

• Protokollierung und Analyse: Genaue Client-IP-Adressen sind unerlässlich für Webserver-Zugriffsprotokolle, Verkehrsanalysen und die Verfolgung des Nutzerverhaltens.
• Sicherheit:
  • IP-basierte Zugriffskontrolle: Einschränkung des Zugriffs auf bestimmte Ressourcen basierend auf Client-IP-Adressen.
  • Ratenbegrenzung: Verhinderung von Missbrauch oder DDoS-Angriffen durch Begrenzung der Anforderungen pro Client-IP.
  • Web Application Firewalls (WAFs): Anwendung von Sicherheitsregeln basierend auf der Identität des ursprünglichen Clients.
  • Geolokalisierung: Bestimmung des geografischen Standorts eines Benutzers zur Inhaltsanpassung oder Compliance.
• Anwendungslogik:
  • URL-Generierung: Anwendungen benötigen X-Forwarded-Host und X-Forwarded-Proto, um korrekte absolute URLs (z.B. für Weiterleitungen oder Links innerhalb der Anwendung) zu konstruieren, die der ursprünglichen Anforderung des Clients entsprechen.
  • Sitzungsverwaltung: Einige Sitzungsmechanismen können an IP-Adressen gebunden sein.
  • Mandantenfähige Anwendungen: Unterscheidung von Mandanten basierend auf dem ursprünglichen Host-Header.
• Debugging und Fehlerbehebung: Der Via-Header und die vollständige X-Forwarded-For-Kette können helfen, Probleme mit Netzwerkpfaden zu diagnostizieren und problematische Proxys zu identifizieren.

Proxy-Konfiguration und Best Practices für die Sicherheit

Die Konfiguration von Proxys zur korrekten Handhabung dieser Header ist entscheidend.

• Vertrauensgrenzen: Vertrauen Sie X-Forwarded-For- (oder Forwarded-) Einträgen nur von bekannten und vertrauenswürdigen Upstream-Proxys. Implementieren Sie eine Logik, um den Header zu parsen, vertrauenswürdige Proxy-IPs zu identifizieren und die wahre Client-IP aus dem rechtesten nicht vertrauenswürdigen Eintrag abzuleiten.
• Header-Entfernung/-Bereinigung: Bei extern zugänglichen Proxys sollten Sie das Entfernen oder Bereinigen von Via-Headern und internen benutzerdefinierten X--Headern in Betracht ziehen, um die Offenlegung von Informationen über die interne Netzwerktopologie zu verhindern.
• Konsistenz: Stellen Sie sicher, dass alle Proxys und Load Balancer in einer Kette konsistent konfiguriert sind, um diese Header korrekt anzuhängen oder zu setzen.
• Standard vs. Benutzerdefiniert: Während Forwarded der Standard ist, bleiben X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weit verbreitet. Implementierungen unterstützen oft beides oder priorisieren den Forwarded-Header, falls vorhanden.