クライアントIPに加えて、「X-Forwarded-For」または同様のHTTPヘッダーに基づいてクライアントを識別する利点
X-Forwarded-For ヘッダーは、一部のHTTPプロキシでクライアントのIPアドレスを識別するために使用されます。 Wikiページ（上記にリンク）は、ISPもこのヘッダーを使用する可能性があると述べています。
さらに、クライアントの識別に使用できるさまざまな追加ヘッダーがあります。いくつかの例は次のとおりです。
- HTTP_CLIENT_IP
- HTTP_X_FORWARDED_FORは、IPのコンマ区切りリストにすることができます
- HTTP_X_FORWARDED
- HTTP_X_CLUSTER_CLIENT_IP
- HTTP_FORWARDED_FOR
- HTTP_FORWARDED
これらのヘッダーのいずれかを使用して、アクセスを制御したり、サイトへのアクセスをブロックまたは許可したりできますか？
例えば。段階的にブロックする：最初にHTTP_Header_X、次にクライアントIP？これらのヘッダーの既知の使用法は何ですか？例えばISP、Squidなどのプロキシソフトウェアなど.
次に、一部のWebサーバーがこれらのヘッダーの存在（または欠如）に基づいて応答を動的に変更する可能性があることを検討していました。サーバーがIPアドレスでユーザーを禁止したとします。受信したIPまたはこのヘッダーで指定されたIPに基づいてユーザーを禁止する必要がありますか？次に、サーバーが課したIP禁止を回避する方法として、このヘッダーを偽装する可能性を検討しました。
- これらのヘッダーの周りにはどのようなセキュリティ上の問題が存在する可能性がありますか？それに対処する適切な方法は何ですか？
例えば。ロギングなどに関連するものを含める.
これらのHTTPヘッダーcanはアクセス制御の目的で使用されますが、これらのヘッダーの存在やデータの有効性には依存しません。
私がそれらを使用するのに最も多く使用するのはロギングです。これらのヘッダーのいずれかが存在すること、または存在する場合でも、それらに有効なデータが含まれることは保証されません。 Firefox用のX-Forwarded-Forなりすましプラグインがあり、おそらく他のブラウザ用のプラグインもあることは知っています。これにより、情報が統計レベル（トレンド分析、パターン分析など）でのみ役立つようになります。これらのヘッダーを収集してログに記録することには、確かに何らかの価値があります。それらに依存することはしないでください
あらゆる種類の認証またはアクセス制御のためのHTTPヘッダーへの依存は、最悪の行為として分類する必要があります。
アクセスと認証を制御するより良い方法があります。
ハッカーがあなたのサイトに侵入すると、自分のオリジンを隠すためにプロキシを通過しようとします。これらのプロキシのほとんどは、これらのヘッダーの1つを追加します。これらのヘッダーをログに記録すると、オリジンを発見する可能性が高くなります。
たとえば、2年前、ハッカーは気候研究者から盗んだメールを懐疑論者のWebサイトに投稿するために open proxies を使用しました。それらのWebサイトがこれらのヘッダーを追跡していれば、ハッカーの身元を発見できた可能性があります。
X-Forwarded-For：ヘッダーは、プロキシを経由したかどうかに関係なく、クライアントによって追加できます。シンプルな curl -H "X-Forwarded-For: 127.0.0.1" http://example.comはこれを実現します。
エンドユーザーにプライバシーを提供するために、このヘッダーを削除するようにプロキシを構成できます。多くの公に利用可能なプロキシは、これを行うことを宣伝しています。
カンマ区切りのリストにあるIPアドレスのallを確認し、それらのいずれかに基づいてアクセスをブロックまたは許可することもできますが、上記の2つの点は、これらのヘッダーを完全に変更するクライアント。アクセス制御は信頼できません。
すべての既知の匿名プロキシサーバーのリストを維持することは困難で、最終的には無駄な作業です。
これを行うことから何か利点がありますか？おそらく。攻撃者が匿名のプロキシを見つけるか、自分のヘッダーを偽装するまで、攻撃者をしばらく苛立たせるかもしれません。この欲求不満は、彼をより簡単なターゲットに移動させるのに十分かもしれません。
欠点はありますか？スプーフィングされたヘッダーは非常に長く、形式が正しくなく、IPアドレスがまったく含まれていない可能性があります。同じヘッダーの複数のコピーが存在する場合もあります。このすべてのチェックを行うコードを追加すると、セキュリティ上の欠陥を含む可能性のある新しいバグが発生する可能性があります。また、不正なヘッダー、長いヘッダー、または複数のヘッダーに大きなオーバーヘッドが発生する可能性もあります。
補足：Apacheを使用している場合、 mod_rpaf は、いくつかのヘッダーの1つから最後のIPアドレスを取得し、内部のREMOTE_Host変数をそれで置き換えます。これは主に、Webサーバーがリバースプロキシの背後にある場合に役立ちます。
つまり、mod_rpafを使用している場合、Apache内のIPアドレスによるアクセス制御は信頼性が低く、簡単に回避できます。
リストの最後のIPアドレスが正しいこと、または実際のIPアドレスが正しいことは保証されません。保証されている唯一の既知の値は、実際に接続しているIPアドレスです。
大部分はLadadadaに同意します-これはユーザー提供のデータですが、正確であるとは限りませんが、少なくともクライアントアドレスはなりすましが非常に困難です。
しかし、エンドポイントアドレスにある程度の自信がある場合でも、そのIPアドレスに基づいてリクエストを認証することは悪い考えです。
これらのヘッダーのいずれかを使用して、アクセスを制御したり、サイトへのアクセスをブロックまたは許可したりできますか？
それは間違いなくアクセスを許可するための基準であってはなりません-しかし、それはblocking accessの有効な基準ではないという意味ではありません。結局のところ、あなたのサイトを悪用するつもりの誰かがあなたのサイトへのアクセスを妨げるような行動をとることによって得られる可能性はほとんどありません。
実際、サービス拒否攻撃に効果的に対応できるようにしたい場合は、疑わしい攻撃の属性に基づくフィードバックシステムが適しています。これがfail2banの機能です。
X-Forwarded-Forヘッダーフィールドの値は、クライアント側で設定できます。これは、X-Forwarded-Forスプーフィングとも呼ばれます。ただし、Web要求がプロキシサーバー（匿名性の低い非エリートプロキシサーバー）を介して行われた場合、プロキシサーバーはクライアント（ユーザー）のIPアドレスを追加してX-Forwarded-Forフィールドを変更します。これにより、X-Forwarded-Forフィールドに2つのコンマ区切りのIPアドレスが生成されます。したがって、Webサーバーは、必要に応じて、プロキシサーバーの使用を検出し、スプーフィングを検出する可能性があります。次の記事では、Pythonコードサンプル X-Forwarded-For Spoofing を使用してこれについて説明しています。