Les risques de la « vraie » IP client

Résumé

• Lors de la récupération de la « Real Client IP » depuis l’en-tête X-Forwarded-For, il faut utiliser l’IP la plus à droite
• L’IP la plus à gauche dans l’en-tête XFF est généralement considérée comme « la plus proche du client », donc « presque la vraie », mais elle peut être falsifiée (spoofable). Il ne faut l’utiliser pour rien de lié à la sécurité
• Lorsqu’on sélectionne l’IP XFF la plus à droite, il faut utiliser la dernière occurrence de cet en-tête
• Les valeurs de « True Client IP » définies par un reverse proxy (X-Real-IP, True-Client-IP, etc.) sont utiles, mais
  • cela dépend de la manière dont le reverse proxy définit cette valeur
  • le reverse proxy lui-même a peut-être déjà été trompé (spoofed)
  • cela dépend aussi de la configuration du reverse proxy lui-même
• Les en-têtes qui ne sont pas explicitement définis par le reverse proxy ne sont pas fiables
  • Par exemple, si l’on n’est pas derrière Nginx ou s’il n’est pas configuré pour toujours définir cet en-tête, il ne faut pas lire l’en-tête X-Real-IP, car on pourrait lire une valeur falsifiée
• De nombreuses implémentations de rate limiting utilisent des IP falsifiables et sont vulnérables au contournement du rate limiting ainsi qu’aux attaques d’épuisement mémoire
• Si du code ou votre infrastructure utilise quelque chose lié à la « real client ip », reportez-vous à la suite pour les détails techniques

Détails (le texte est long, seuls les titres sont repris)

• Introduction : déterminer la « real client ip » est horrible de nos jours
• Pièges
  • Les en-têtes ne sont pas fiables
  • Plusieurs en-têtes
  • IP privées
  • IP splitting
  • Les données non chiffrées ne sont jamais fiables
  • Des en-têtes comme X-Client-IP et True-Client-IP peuvent être falsifiés
  • Comprendre X-Forwarded-For
• Éviter les pièges
  • Algorithme pour obtenir la vraie IP
    • Récupérer toutes les valeurs d’IP
    • Choisir lesquelles utiliser selon les exigences de sécurité
    • La plus à gauche, la plus à droite
• Exemples concrets
  • Cloudflare, Nginx, Apache
  • Akamai
  • Fastly
  • Azure
  • go-chi/chi
  • didip/tollbooth
  • ulule/limiter
  • sethvargo/go-limiter
  • Let's Encrypt
  • Express
  • Traefik
  • phpList
  • IIS
  • Tor
• Avancé : pièges théoriques et méthodes d’attaque
• RFC 7239: Forwarded HTTP Extension, June 2014

[tribela]

Par exemple, si vous êtes derrière Nginx, ou si quelque chose d’autre le définit toujours explicitement, il ne faut pas lire l’en-tête X-Real-IP. Sinon, vous risquez de lire une valeur usurpée.

Je pense qu’il s’agit ici d’une légère erreur de traduction. Le texte original est le suivant.

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.

Par exemple, si vous n’êtes pas derrière Nginx, ou derrière autre chose configuré pour toujours définir cet en-tête, vous ne devez pas lire l’en-tête X-Real-IP, car vous liriez alors une valeur usurpée.

[xguru]

Ah, je vais corriger ça. Merci !

[tribela]

En général, on utilise la variable d’environnement TRUSTED_PROXY pour exclure une à une, en partant de la droite, les proxys « de confiance », puis on prend la première IP qui apparaît.
On considère aussi souvent les IP internes (192.168.0.0/16, etc.) comme des proxys de confiance.