web-dev-qa-db-ja.com

X-Forwarded-For IP、X-Real-IP、VPN、TORの違い

私はこれに取り組んでいるGoogle ChromePrivacy Preserving Extensionに取り組んでいます。ユーザーエージェントなどのヘッダー情報を偽装できる場所です。

X-Forwarded-For IPになりすまして http://whatsmyuseragent.com/ にアクセスすると、別のIPと物理的な場所が表示されます。一方、 http://whatismyipaddress.com/location-feedback にアクセスすると、実際のIPと物理的な場所が表示されます。

TOR/VPNから同じサイトにアクセスすると、場所とIPがまったく異なります。これは、TOR/VPNが私の本当のアイデンティティを隠すことを意味します。プロキシが私のリクエストを受け取り、その代わりにそれらを転送することを知っています。なぜX-Forwarded-For IPが同じことをしないのですか?私が何度も変更したにもかかわらず、発信元IPに通知するだけで、なりすましX-Forwarded-For IPのポイントは何ですか?

4
Curtis Hagen

X-Forwarded-Forヘッダーは、ソースNATの場合にクライアントの実際のIPを転送するために使用できます。しかし、すべてのアプリケーションがそれらを使用するわけではありません。

このヘッダーは、アプリケーションがクライアントに属する実際のIPを知る必要がある場合、適切なアーキテクチャーに応じて、ロードバランサーまたはリバースプロキシによって挿入されることがよくあります。

このヘッダーが挿入されると、アプリケーションは2つのIPを確認できます。

  • TCP/IP接続で使用されるソースIP
  • X-Forwarded-Forヘッダーで設定されたIP

このヘッダーを設定しても、実際のIPは非表示になりません(TCP/IP接続で引き続き使用されるため)が、アプリケーションをだましてしまう可能性があります。ただし、ご覧のとおり、すべてのアプリケーションが使用しているわけではありません。

TORおよびVPNの場合、これはTCP/IP接続で使用されるIPであり、(それぞれ)出口ノード/ VPNゲートウェイによって変更されます。ただし、これらはアプリケーションレイヤーで動作せず(また、動作してはいけません)、X-Forwarded-For HTTPヘッダーを挿入しない(そして、動作できないはずです)ため、実際のIPは非表示です。

6
Jyo de Lys

追加のヘッダー(通常、X-を接頭辞として使用するという非推奨の規則によって識別可能)は単なる規則です。また、クライアントとサーバー間のプレーンテキスト接続にアクセスできるユーザーなら誰でも編集できます。

したがって、X-Forwarded-for(または「Via」、またはその他のバリアント)の存在は、実際のIPの信頼できる指標ではありません。このようなヘッダーがないことは、直接接続を示すものではありません。 OTOHでは、HTTPSリクエストでこのようなヘッダーが存在することを重要視できます。

銀行を強奪しようとしていて、X-Forwarded-Forヘッダーの存在下で銀行がクライアントのアドレスを無視する場合、トレイルをカバーするための非常に簡単な方法が提供されています。

非常に難しい で、TCP/IPパケットに現れる「from」アドレスを偽装することは可能です。したがって、通常は正確なエンドポイントとして信頼できます(ただし、実際のクライアントは、このデバイスをNAT router/proxy)として使用して別のアドレスにある場合があります)。

[tor]プロキシが私のリクエストを受け取り、その代わりにそれらを転送することを知っています。なぜX-Forwarded-For IPは同じことをしないのですか?

まず、X-Forwarded-Forはリクエストに含まれる少しのテキストですが、torはネットワークインフラストラクチャと関連プロトコルです。第2に、ヘッダーが追加されるコンテキストは、パケットストリームを再構成するプロキシを介して接続が送信され、要求に対していくつかの操作を実行する場合です。これには、オリジンホストへの要求の送信が含まれます。

2
symcbean