仮にユーザーが次のような任意のURLからアバターを使用できるようにしたいとします。
<img class="avatar" src="{user input}" />
私が考えることができる多くの問題があります:
data uris
したがって、自己完結型のPDFファイルを作成できる可能性があります。これは実際に<img />
鬼ごっこ?javascript:
表記<a />
要素そしておそらくもっともっと。
実際にそのイメージをダウンロードして提供せずに安全にする方法はありますか?
受け取った文字列が有効であることを確認する必要があります。この原則を覚えておいてください。受け入れられない文字列をブラックリストにするのではなく、受け入れられる文字列をホワイトリストに入れる必要があります。
/var/www
フォルダー内からアクセス可能なシンボリックリンクを処理する方法、およびサーバーが親ディレクトリへの参照を使用して絶対URLを解決する方法を理解する必要もあります。 www.server.com/../../../etc/passwd
。http
またはhttps
)を使用していることを確認してください。 ¹知らないうちにリンクを提供したユーザーはいつでもファイルを変更できるため、実際に指しているファイルが何であるかを確認しても、アプリオリな意味はありません。そのコードがブラウザーのレンダリングルーチンでバグをトリガーすると、サイトをレンダリングする(サンドボックス化された)ブラウザープロセスが危険にさらされます。
イメージを使用して、自分のユーザーのIPアドレスを収集できることに注意してください。攻撃者は、サイトに使用した画像を照会するIPアドレスを待機して収集するだけです。
401攻撃は今では修正されるはずですが、一部のブラウザではまだ適切に処理されない可能性があります。これは StackExchangeスレッド で説明されています。 this Chromeバグ追跡スレッド のように、Chromeは画像が401エラーをトリガーしたときに認証プロンプトを表示しなくなりました。
これらの2つの脅威に対する一般的な解決策があります:イメージをダウンロードしてキャッシュします。それをする余裕があれば、ユーザーが安全であるという確信が高まります。 それはあなたが求めているものではないことを知っていますが、それはあなたの最善の行動方針です
画像をキャッシュしているので、もう一度ホワイトリストに登録する必要があります。
an攻撃者がfile:///some/user/secret/on/their/local/machine
などを実行できることが指摘されています。ファイルを取得せず、URLをそのままにした場合、サイトをレンダリングするレンダリングプロセスによってファイルが読み込まれる可能性があります。レンダリングのバグを悪用する画像へのsecondURLと組み合わせて、攻撃者はこのファイルのコンテンツを取得する可能性があります。
² SVGファイルは特に危険です であり、現在それらをフィルタリングするための利用可能なツールがないことに注意してください。