「本当の」クライアントIPの危険性

 (adam-p.ca)
21 ポイント 投稿者 xguru 2022-03-07 | 3件のコメント | WhatsAppで共有

要約

  • X-Forwarded-For ヘッダーから「Real Client IP」を取得する際は、最も右側の IP を使うこと
  • XFF ヘッダーの最も左側の IP は通常「クライアントに最も近い」「ほぼ本物」と見なされるが、偽装可能（spoofable）。セキュリティに関わる用途には使わないこと
  • 最も右側の XFF IP を選ぶときは、そのヘッダーの最後のインスタンスを使う必要がある
  • リバースプロキシが設定する「True Client IP」の値（X-Real-IP、True-Client-IP など）も有用ではあるが
    • リバースプロキシがその値をどのように設定しているかによる
    • リバースプロキシ自体がすでに欺かれている（spoofed）可能性もある
    • リバースプロキシの設定がどうなっているかによって変わる
  • リバースプロキシが特別に設定していないヘッダーは信頼できない
    • たとえば、Nginx の背後にない、あるいは常に（ヘッダーを）設定するようになっていないなら、X-Real-IP ヘッダーを読んではならない。偽装された値を読んでしまう可能性があるため
  • 多くの Rate Limiter 実装が偽装可能な IP を使っており、レートリミット回避やメモリ枯渇攻撃に脆弱である
  • コードやインフラで「real client ip」に関するものを使っているなら、以下の技術的な内容を参照すること

詳細（長いため見出しのみ訳します）

  • 紹介 : 最近の「real client ip」特定はひどく厄介
  • 落とし穴
    • ヘッダーは信頼できない
    • 複数のヘッダー
    • プライベート IP
    • IP Splitting
    • 暗号化されていないデータは常に信頼できない
    • X-Client-IP、True-Client-IP のようなものは偽装可能
    • X-Forwarded-For を理解する
  • 落とし穴を避ける
    • 本当の IP を取得するためのアルゴリズム
      • すべての IP 値を取得する
      • セキュリティ要件に応じて何を使うか選ぶ
      • 最も左、最も右
  • 実例
    • Cloudflare, Nginx, Apache
    • Akamai
    • Fastly
    • Azure
    • go-chi/chi
    • didip/tollbooth
    • ulule/limiter
    • sethvargo/go-limiter
    • Let's Encrypt
    • Express
    • Traefik
    • phpList
    • IIS
    • Tor
  • 上級 : 理論上の落とし穴と攻撃手法
  • RFC 7239: Forwarded HTTP Extension, June 2014

関連記事

3件のコメント

 
tribela 2022-03-08

たとえば Nginx の背後にある場合や、特別に常に指定しているのでなければ X-Real-IP ヘッダーを読んではならない。スプーフィングされた値を読んでしまう可能性があるためです。

この部分は少し誤訳のようです。原文はこちらです。

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.

たとえば、Nginx の背後にいない、または常に（ヘッダーが）設定されるようになっていないのであれば、X-Real-IP ヘッダーを読んではならない。スプーフィングされた値を読んでしまうことになるためです.
 
xguru 2022-03-08

ああ、修正しておきます。ありがとうございます！
 
tribela 2022-03-08

一般的な方法では、TRUSTED_PROXY環境変数を使って、右端から「信頼できる」プロキシを1つずつ除外していき、最初に現れたIPを使用します。
通常は内部IP（192.168.0.0/16）などを信頼できるプロキシとして扱うこともあります。