（以前はセキュリティチャネル経由で報告されましたが、却下され、現在は責任ある開示プロセスに従って公開開示を行っています）
要約 / リクエスト
ユーザーとして、IPアドレスを悪意のある第三者の画像ホスティングサーバーから保護するために、チャットに投稿されたホットリンクされた画像をサーバーでキャッシュしてから表示してほしいです。ただし、キャッシュ/プロキシされた画像は表示したいです。
Discourseにはすでにこのための設定がありますが、チャットには正しく適用されていません。関連するホットリンク設定（下記）の両方が有効になっている場合、フォーラムと同じように動作するはずです。つまり、サードパーティでホストされている画像はサーバーにダウンロードされ、その後ユーザーに表示されます。
背景 / 影響
インターネットフォーラムの昔は、ユーザーが画像を「ホットリンク」して第三者サーバーにホストされている画像を投稿することが一般的でした。
これは古いフォーラムでは一般的でしたが、インターネットが進歩するにつれて、これは悪い習慣であることがわかりました。ほとんどすべてのソーシャルメディアプラットフォームがこれを防ぐように進化しました。その理由の一部は、壊れた/失われた画像の問題や、小さなサーバーへの過負荷を回避するためでしたが、非常に重要なセキュリティ上の考慮事項もあります。
オフサイトサーバーから画像を投稿するユーザーは、その画像をリンクされたサーバーからダウンロードします。これにより、悪意のある第三者サーバーがユーザーのIPをログに記録できます。サーバーが悪意のあるユーザーによって実行されている場合、そのユーザーは他のユーザーのIPを知ることになるため、これは非常に問題があります。（悪意のあるユーザーがあなたのホームIPを見つけるためにあなたにメッセージを送るケースを想像してみてください）
漏洩したIPは、悪意のある人物によってユーザーの本当の身元を特定するために使用されたり、ホームルーター/PCの脆弱性をスキャンするために使用されたりする可能性があります。また、他のサイトにXSS脆弱性がある場合、別のサイトでXSSを実行できる可能性もあります。
これが、Twitter、Discord、Facebookなど、ほとんどすべての主要なソーシャルネットワークがセキュリティ上の理由で画像ホットリンクを行わなくなった理由です。すべてのサードパーティ画像は、ユーザーが直接プルするのではなく、サーバーにキャッシュされるようになりました。
関連するDiscourse設定
Discourseには2つの関連設定があります。
Block hotlinked media（ホットリンクされたメディアをブロック）は、ホットリンクされた画像をテキストリンクに置き換えます。
Download remote images to local（リモート画像をローカルにダウンロード）は、ホットリンクされた画像をローカルに保存された画像に変換します。
フォーラムでの設定の動作
これら両方の設定が有効になっている場合、私の限られたテストではフォーラムは期待どおりに動作しているようです。外部画像は、他のユーザーに表示される前にローカル画像に変換され、ユーザーのIPを保護します。広範なタイミング攻撃を試して動作を確認していませんが、少なくとも私の限られたテストでは正しく機能しました。
（これは、Twitter/Discord/Facebookなどのフォーラムと同様に、最新のソーシャルプラットフォームに期待する動作です）
チャットでの設定の動作
チャットでは、同様の動作を得ることができませんでした。設定のどの組み合わせでも満足のいく結果は得られませんでした。
両方の設定を有効にすると、リモート画像はリンクに変換されるだけです。しかし、**画像が他のユーザーに表示され、Webリクエストが発生する非常に短い時間枠があり、その結果、ユーザーIPが他のユーザーに公開されます。**これは基本的に最悪の結果です。ユーザーIPが公開され、画像も表示されません。
Block hotlinked mediaを無効にし、Download remote images to localを有効にすると、ホットリンクになります。実際にはリモート画像をダウンロードしていないようです。脆弱性ではありませんが、バグのようです。
Block hotlinked mediaを有効にし、Download remote images to localを無効にすると、両方を有効にした場合と同じ動作になります。画像ではなくリンクとして表示されますが、画像はリモートクライアントによってプルされることがあり、IPが公開されます。（画像が最初に送信されたときにブロックされることがありますが、2回目に一時的にブロックされない、またはその他のタイミングに関連する問題が頻繁に発生することがわかりました。）
（本日、gitの開発チェックアウトで再テストしました：3.5.0.beta8-dev (2c0635ee4c)）
開示 / 回答
以前（2024年）に電子メールとhackeroneでこれを報告しましたが、セキュリティ上の問題ではないと言われ、セキュリティレポート（2844784）は残念ながら却下されました。関連する声明は次のとおりです。
レポートありがとうございます。慎重なレビューの結果、説明されている動作はセキュリティ上の脆弱性ではなく標準的なWeb機能であるため、これをクローズします。
ブラウザが外部リソース（画像、スクリプトなど）を読み込む場合、必然的にホスティングサーバーへのリクエストが行われます。このサーバーは当然、リクエスト元のIPアドレスを確認します。これはインターネットの仕組みの基本であり、それ自体はセキュリティ上の脆弱性とは見なされません。IPアドレスは文脈によっては個人データと見なされることがありますが、標準的なWebリクエストを通じて公開されることは、インターネットを閲覧する際にユーザーが暗黙的に受け入れることが期待される動作です。
Discourseのホットリンク保護は、ユーザーのIPアドレスを外部サーバーから隠すためではなく、ホストされているコンテンツの不正使用を防ぐために設計されています。
これはホットリンクブロッキング機能の意図されたユースケースかもしれませんが、これを対処しないことはチャットプラグインのユーザーを危険にさらす可能性があると思います。特に、敵のホームIPを見つけて個人情報を暴露/DDOSしようとするユーザーがいる可能性のある、より活発なコミュニティでは。
また、現代において、信頼できるフォーラムサイトで信頼できないホットリンクURLにアクセスすることにユーザーが暗黙的に同意するという考えにも反対します。GDPR/その他の影響についてはわかりませんが、コメントしません。基本的なプライバシーの期待からすると、これは非常に古いフォーラムを除いては期待されるものではありません。間違いなく現代のフォーラムではありません。
2024年11月22日に、この問題についてこのフォーラムで公開する意向を通知しましたが、それ以降何も連絡がありませんでした。
他のDiscourse管理者にも認識してもらい、エンジニアリングチームによるホットリンク保護の改善を奨励してもらうために、ここに投稿します。長期間改善がないため、善意で投稿し、問題の重要性に対する認識と、おそらくコミュニティからの奨励によって改善がもたらされることを願っています。
お読みいただきありがとうございます 