XFF / X-Forwarded-For について

こんにちはやまぱんです。
今回は XFF / X-Forwarded-For についてメモしておきます。
XFF の検証は参考に別記事にのリンクを張っているので別途見ていただけたらと思います。

XFF / X-Forwarded-Forとは

X-Forwarded-For (XFF) は、ウェブサーバーのリクエストヘッダーに含まれる情報の一つで、クライアントのIPアドレスを示すために使用されます。XFFは、特にプロキシサーバーが存在する場合に役立ちます。

プロキシサーバーを経由してリクエストが送信される場合、ウェブサーバーはプロキシサーバーのIPアドレスを受け取ります。しかし、クライアントのIPアドレスを知る必要がある場合は、XFFヘッダーが使用されます。このヘッダーには、リクエストを送信したクライアントのIPアドレスが含まれます。

例えば、クライアントが自宅のネットワークからリクエストを送信し、そのリクエストがプロキシサーバーを経由してウェブサーバーに到達する場合、XFFヘッダーには自宅のネットワークのIPアドレスが含まれます。これにより、ウェブサーバーは正確なIPアドレスを把握することができます。

XFFヘッダーは、セキュリティ上の理由から、不正なIPアドレスを含んでいる可能性があるため、信頼できるソースからのみ使用することが推奨されています。また、ウェブサイトの設定によっては、XFFヘッダーを無視することができます。

メリット

クライアントのIPアドレスをウェブサーバに伝えることで、アクセス制御や統計分析などに役立ちます。
ロードバランサでクライアントポート保持属性を有効にすると、クライアントのポート番号もウェブサーバに伝えることができます。

デメリット

このヘッダは正式な規格ではなく、様々な実装が存在するため、互換性や信頼性に問題が生じる可能性があります1。
このヘッダは容易に偽装されるため、セキュリティ上の脆弱性を引き起こす可能性があります。

調べた背景

Azure の構成に関して考えていた時の話で以下のような話がありました.

  • Azure Firewall → Azure Application Gateway → Webサーバのような経路 ってありなのか?

結論からいうとなしです。なぜなら
・ Azure Application Gateway は XFF を付与できる
・ Azure Firewall は XFF を付与できない
ので、Azure Firewall → Azure Application Gateway → Web サーバーみたいな通信経路にすると、
XFF に Azure Firewall のアドレスが格納されてしまい意味がないものになるからです。

・ 仮想ネットワークの Azure Firewall と Application Gateway
https://learn.microsoft.com/ja-jp/azure/architecture/example-scenario/gateway/firewall-application-gateway

Azure Application Gateway は、Secure Sockets Layer (SSL) 暗号化と解読を実行できる、マネージド Web トラフィック ロード バランサーであり、完全な HTTP(S) リバース プロキシです。Application Gateway は、X-Forwarded-For HTTP ヘッダー内の元のクライアント IP アドレスを保持します。 また、Application Gateway では、Web アプリケーション ファイアウォールを使用して、HTTP レイヤーで Web トラフィックを検査し、攻撃を検出します。

XFF / X-Forwarded-For のヘッダー情報を確認する方法

httpbin.org を使ったXFF / X-Forwarded-For のヘッダー情報を確認する方法

参考

・リクエストを送ってXFF / X-Forwarded-For のヘッダー情報を確認する方法
https://yamapan.tokyo/?p=2319

・ XFF ( X-Forwarded-For )
https://www.infraexpert.com/study/loadbalancer11.html

・Windows(IIS)でHTTPリクエストヘッダー (XFFなど)を確認する
https://yamapan.tokyo/?p=2735

シェアする

  • このエントリーをはてなブックマークに追加

フォローする