X-Forwarded-For定义
この定義は、誰かがこの投稿を閲覧して目にした場合に備えて説明しますが、これで準備は完了だと思います。
X-Forwarded-For: <client>, <proxy1>, <proxy2>
これは、タイトルを説明する基本的にすべてのページで見られるものです。X-Forwarded-For誤用がこれほど一般的であるのも不思議ではありませんか?
X-Forwarded-Forヘッダーが信頼されていません
何よりもまず、管理下にないプロキシによって追加された (または追加されたように見える) XFF IP は完全に信頼できないということを常に認識しておく必要があります。どのプロキシでも、必要に応じてヘッダーを追加、削除、または変更できます。クライアントは、最初にヘッダーを、スプーフィング ボールを回転させるために必要なものに設定することもできます。たとえば、 AWS Load Balancer 2に対してこのリクエストを行うと…
curl -X POST https://my.load.balanced.domain/login -H "X-Forwarded-For: 1.2.3.4, 11.22.33.44"
...ロード バランサの背後にあるサーバーは次のものを取得します。
X-Forwarded-For: 1.2.3.4, 11.22.33.44, <actual client IP>
この：
curl -X POST https://my.load.balanced.domain/login -H "X-Forwarded-For: oh, hi,,127.0.0.1,,,,"
...これが得られます:
X-Forwarded-For: oh, hi,,127.0.0.1,,,,, <actual client IP>
ご覧のとおり、すでに存在するものはすべてそのまま渡され、変更されず、検証されません。最終的な実際の IP は、既存の IP に追加されるだけです。
(curl クライアントとカスタム クライアントに加えて、ブラウザー リクエストに XFF ヘッダーを設定できるようにするChrome 拡張機能が少なくとも 1 つあります。しかし、ヘッダーをどのように設定するかは私たちにとって重要ではありません。唯一重要なのは、攻撃者ができることです。やれ。）
要約する
具体的な手順については、「実際の」クライアント IP の危険性 | adam-pを参照してください。
私たちが学んだこと、得た知恵、開発した視点のいくつかをまとめてみましょう。
-
ヘッダーから「実際のクライアント IP アドレス」を取得する場合は
X-Forwarded-For、リストの右端の IP を使用します。 -
XFF ヘッダーの左端の IP は、多くの場合、「クライアントに最も近く」、「最も本物である」と考えられますが、簡単にスプーフィングされる可能性があります。セキュリティ関連には使用しないでください。
-
一番右の XFF IP を選択するときは、必ずそのヘッダーの最後のインスタンスを使用してください。
-
リバース プロキシ
X-Real-IP)(存在するなどTrue-Client-IP設定された特別な「リアル クライアント IP」を使用しても問題ない場合があります。c ) リバース プロキシの構成方法 (場合によっては)。 -
独自のリバース プロキシによって明確に設定されていないヘッダーは信頼されません。たとえば、常にヘッダーを設定する Nginx などを使用していない場合は、スプーフィングされた値を読み取ることになるため、ヘッダーをチェックしてはなりません。
X-Real-IP -
多くのレート リミッター実装ではスプーフィング可能な IP が使用されており、レート リミッター エスケープやメモリ枯渇攻撃に対して脆弱です。
コードまたはインフラストラクチャのどこかで「実際のクライアント IP」を使用している場合は、それを取得する方法をすぐに確認する必要があります。
右端の XFF IP のみを使用し、左端の IP は決して使用しないでください。しかし、真剣に、それを使用しないでください。