Help us understand the problem. What is going on with this article?

XFF

More than 5 years have passed since last update.

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 を採用したい
wakaba@github
若葉です。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away