博士

やっほー、ロボ子！今日のITニュースはね、「X-Forwarded-For」ヘッダーの落とし穴についてなのじゃ。

ロボ子

博士、こんにちは。X-Forwarded-Forヘッダーですか。クライアントのIPアドレスをサーバーに伝えるために使うものですよね。

博士

そうそう！でもね、これが結構アブナイのじゃ。記事によると、多くのプロジェクトでセキュリティの脆弱性が生じているらしいぞ。

ロボ子

脆弱性ですか？具体的にはどのような問題があるのでしょうか？

博士

例えば、レートリミッターの実装が甘いと、IPを偽装されてレート制限を回避されたり、メモリを枯渇させられたりする可能性があるみたい。

ロボ子

なるほど。XFFヘッダー自体が信頼できないということですね。「プロキシはヘッダーを追加、削除、または変更できる」と記事にもあります。

博士

その通り！クライアントだって自由にヘッダーを設定できるからの。それに、同じ名前のヘッダーが複数存在したり、プライベートIPアドレスが紛れていたりすることもあるみたいじゃ。

ロボ子

XFFヘッダーは標準化されていないので、IPアドレスの区切り方も曖昧なんですね。カンマとスペースで区切るのが一般的だけど、スペースが必須ではない、と。

博士

そう！さらに、HTTPで通信している場合は、ヘッダーが途中で書き換えられる可能性もあるぞ。リバースプロキシが不要なヘッダーを削除してくれないこともあるみたいじゃ。

ロボ子

では、どうすればこれらの落とし穴を回避できるのでしょうか？

博士

記事によると、プライベートIPアドレスをクライアントIPとして使うのは絶対にダメ。制御できるリバースプロキシが最初に追加したIPのみを信頼するのが基本じゃ。

ロボ子

セキュリティに関わる処理では、信頼できるIP（右端）を使うべき、とありますね。セキュリティに関係ない処理でも、ユースケースをよく考える必要がある、と。

博士

記事では、CloudflareやNginx、Apacheは適切に設定されていれば右端のIPを使うらしいぞ。Azure Front Doorは左端と右端の両方を提供するみたいじゃ。

ロボ子

go-chi/chiやJettyは左端のIPアドレスを使うので、スプーフィングに弱いんですね。Traefikは「信頼できるプロキシ数」に基づいて右端を使うように設定できる、と。

博士

リバースプロキシの背後にあるサーバーに直接アクセスできる場合、攻撃者はXFFヘッダーを偽造できるからの。CDNを使ったRe-fronting攻撃なんてのもあるみたいじゃ。

ロボ子

ネットワーク構成の変更で設定が古くなり、脆弱性が生まれることもあるんですね。パーサーの解釈の違いも問題になる、と。

博士

そうそう。だから、「左に危険、右に信頼」なのじゃ！自分で設定したヘッダー以外は信用しちゃダメ！

ロボ子

肝に銘じます。セキュリティ実装の一貫性のなさは良くない、という言葉も重いですね。

博士

そういうこと！最後に、記事からの教訓じゃ。「右端の XFF IP のみを使用し、左端は絶対に使用しないようにする」。

ロボ子

よくわかりました、博士！

博士

ところでロボ子、XFFヘッダーって、なんだかエックス JAPANみたいじゃない？

ロボ子

…博士、それはちょっと無理があります。