HTTP X-Forwarded-For: ヘッダー ($ENV{HTTP_X_FORWARDED_FOR}) のよくある話のまとめ
- reverse proxy よりも外側で付けられることがあるので、無条件で信頼しても良いわけではない
- reverse proxy より外で付けられた XFF は reverse proxy で落としても良いかもしれないが、
- 落とす設定を忘れたり、いつのまにか無効になってたりすると困るので、値を信頼したいなら相応の予防措置が必要
- XFF にはそれなりに有用な情報が詰まってるので最低でも reverse proxy のログには残したいし、アプリケーションサーバーで取りたくなることもあるかもしれない (しないかもしれない)
- reverse proxy よりも内側で付けられることがあるので (多段になっている場合)、ヘッダーや値が1つだけとは限らない
- 最初は1つだけだと思っていたのに、後からキャッシュサーバーを挟む必要がでてきたら・・・?
- XFF が既にあるときに、前につける串と後につける串がある
- なので最初とか最後とかを拾うだけではだめ
- データセンター内のプライベートIPアドレスを除去するという対策が提案されてる
- なお、アプリケーションサーバー → キャッシュサーバー → reverse proxy → アプリケーションサーバーみたいな内部から内部への経路だと、グローバルアドレスの前にも後にも内部IPアドレスが付いた XFF になったりする
- アプリケーションサーバー → proxy → アプリケーションサーバーのような経路を使うとグローバルIPアドレスが無い XFF になるので、それがあり得るならそれなりにケアが必要
- 最外 reverse proxy で相手のアドレスを独自ヘッダーに入れて XFF じゃなくてそちらを使う、という対策が提案されている
- 独自ヘッダーが既に付けられている場合は落とす必要はやはりある
- ちなみに XFF が最も広く使われているが、他にも同目的のヘッダーがある
-
X-Client-IP:、X-Sakura-Forwarded-For:、CF-Connecting-IP:など - IETF は
Forwarded:ヘッダーを新たに開発したが、本稿にまとめた問題を解決するものではない - 混在するとどれを採用するべきか問題がますます複雑になるので、 reverse proxy の類を作るなら、できるだけ XFF を採用したい
-