Die Risiken der „echten“ Client-IP

Zusammenfassung

• Wenn die „Real Client IP“ aus dem Header X-Forwarded-For geholt wird, sollte die IP ganz rechts verwendet werden
• Die IP ganz links im XFF-Header gilt normalerweise als diejenige, die dem Client am nächsten ist, also als „fast echt“, lässt sich aber fälschen (spoofable). Sie sollte für nichts Sicherheitsrelevantes verwendet werden
• Wenn die XFF-IP ganz rechts ausgewählt wird, muss die letzte Instanz dieses Headers verwendet werden
• Von Reverse-Proxys gesetzte Werte für die „True Client IP“ (X-REal-IP, True-Client-IP usw.) sind ebenfalls brauchbar, aber
  • es hängt davon ab, wie der Reverse-Proxy diesen Wert setzt
  • der Reverse-Proxy selbst könnte bereits getäuscht worden sein (spoofed)
  • es hängt davon ab, wie der Reverse-Proxy konfiguriert ist
• Header, die nicht ausdrücklich vom Reverse-Proxy gesetzt werden, sind nicht vertrauenswürdig
  • Wenn man sich zum Beispiel nicht hinter Nginx befindet oder nicht sichergestellt ist, dass der Header immer gesetzt wird, sollte der Header X-Real-IP nicht gelesen werden. Andernfalls könnte ein gefälschter Wert gelesen werden
• Viele Rate-Limiter-Implementierungen verwenden spoofbare IPs und sind dadurch anfällig für das Umgehen von Rate Limits sowie für Memory-Exhaustion-Angriffe
• Wenn im Code oder in der Infrastruktur etwas verwendet wird, das mit der „real client ip“ zusammenhängt, sollten die folgenden technischen Details gelesen werden

Details (wegen der Länge werden nur die Überschriften übertragen)

• Einführung: Heutzutage die „real client ip“ zu ermitteln, ist furchtbar
• Fallstricke
  • Header sind nicht vertrauenswürdig
  • Mehrere Header
  • Private IPs
  • IP Splitting
  • Unverschlüsselte Daten sind niemals vollständig vertrauenswürdig
  • Dinge wie X-Client-IP und True-Client-IP lassen sich spoofen
  • X-Forwareded-For verstehen
• Fallstricke vermeiden
  • Algorithmus zum Ermitteln der echten IP
    • Alle IP-Werte erfassen
    • Je nach Sicherheitsanforderung auswählen, welcher verwendet wird
    • Ganz links, ganz rechts
• Praxisbeispiele
  • Cloudflare, Nginx, Apache
  • Akamai
  • Fastly
  • Azure
  • go-chi/chi
  • didip/tollbooth
  • ulule/limiter
  • sethvargo/go-limiter
  • Let's Encrypt
  • Express
  • Traefik
  • phpList
  • IIS
  • Tor
• Fortgeschritten: Theoretische Fallstricke und Angriffsmethoden
• RFC 7239: Forwarded HTTP Extension, June 2014

[tribela]

Zum Beispiel sollte man den Header X-Real-IP nicht lesen, wenn man sich nicht hinter Nginx befindet oder er nicht ausdrücklich immer gesetzt wird. Andernfalls könnte man einen gefälschten Wert auslesen.

Dieser Teil scheint leicht falsch übersetzt zu sein. Das Original lautet wie folgt.

For example, you must not check the X-Real-IP header if you’re not behind Nginx or something else that always sets it, because you’ll be reading a spoofed value.

Zum Beispiel darf man den Header X-Real-IP nicht lesen, wenn man sich nicht hinter Nginx befindet oder er nicht so konfiguriert ist, dass er immer gesetzt wird. Denn sonst würde man einen gefälschten Wert auslesen.

[xguru]

Ah, ich werde das korrigieren. Danke!

[tribela]

Üblicherweise wird mit der Umgebungsvariable TRUSTED_PROXY von rechts beginnend jeweils ein „vertrauenswürdiger“ Proxy nach dem anderen ausgeschlossen und dann die erste dabei auftauchende IP verwendet.
Oft werden dabei auch interne IPs (192.168.0.0/16) usw. als vertrauenswürdige Proxys behandelt.