ユーザー提供のURLを取得することのセキュリティリスク
次の機能をWebアプリケーション（オンライン製品データベース、必要に応じて）に追加することを検討しています。
- 画像をアップロードする代わりに、ユーザーは画像の（自己ホスト型）URLを提供できます。画像の代わりにURLを保存します。
ここまでは順調ですね。ただし、場合によっては、Webアプリケーションで（外部からユーザーが指定した）URLから画像をfetchして、何かを実行する必要があります（たとえば、 PDF製品データシート）に画像を含めます。
これは私に関係があります。それは、私たちのWebサーバーがHTTPリクエストをユーザー指定のURLに送信することを意味するためです。これで実行できる多くの邪悪なことをすぐに考えることができます（たとえば、URLとしてhttp://192.168.1.1/...を入力し、いくつかの一般的なルーターWebインターフェイスのエクスプロイトを試します）。これは クロスサイトリクエストフォージェリ に似ていますが、ユーザーをだましてWebリクエストを送信させるのはWebサーバーではなく、ユーザーがWebサーバーをだますだけです。
確かに、私はこの問題に直面する最初のものではありません。したがって、私の質問：
- この攻撃ベクトルには名前がありますか？ （さらに調査できるように...）
- ユーザーが提供するURLの取得に関連する他のリスクはありますか？
- これらのリスクを軽減するために確立されたベストプラクティスのテクニックはありますか？
この特定の脆弱性には確かに名前があります。これは、サーバー側要求偽造（SSRF）と呼ばれます。 SSRFは、内部ネットワーク上の他のWebページ、ループバックからアクセスした場合にのみ利用できる他のサービス（他のWebサービスとAPI、場合によってはデータベース）など、アプリケーション開発者が意図していないリソースをユーザーがサーバー側アプリケーションに取得できるようにするときです。サーバー）、さらにはサーバー上のファイル（file:///etc/passwd）。不正使用の例については、 SSRF Bible および PayloadsAllTheThings を参照してください。これはイメージタグであるため、ほとんどのものが表示されない可能性がありますが、修正する必要があります。
それについて何をしますか？ OWASP SSRFチートシート を参照できます。状況は2番目のケースと一致しますが、POSTへのリクエストの変更や一意のトークンの追加など）の軽減策のすべてを実行することはできません。
- ホワイトリストで許可されているプロトコル：HTTPとHTTPSを許可し、それ以外は許可しません（例：
^https?://などの正規表現）。 - 指定されたホスト名がパブリックであることを確認してください：多くの言語にはIPアドレスライブラリが付属しています。ターゲットホスト名が非プライベートで予約されていないIPv4またはIPv6アドレスに解決されるかどうかを確認します*。
- 私自身の追加、カスタムファイアウォールルール：Webアプリケーションを実行するシステムユーザーは、すべての内部ネットワーク要求とローカルサービスをブロックする制限的なファイアウォールルールにバインドされる可能性があります。これは、Linuxで
iptables/nftablesを使用して可能です。または、アプリケーションのこの部分をコンテナ化/分離してロックダウンします。
おそらく、取得時にファイルのMIMEタイプを検証して、それがイメージであることを確認することもできます。また、イメージをフェッチするときにリダイレクトを受け入れないでください。そうする場合は、リダイレクトに対してまったく同じ検証を実行してください。悪意のあるWebサーバーは、内部リソースにリダイレクトする3xx応答を送信する可能性があります。
さらに、ユーザーが入力したデータからPDFを生成すると述べました。画像のURLは別として、PDFジェネレーターはこれまでXXE（XML eXternal Entityインジェクション）とSSRFの脆弱性の繁殖地でした。そのため、カスタムURLを修正した場合でも、PDF生成ライブラリは、これらの問題を回避するか、検証を自分で実行します。DEFCONトークでは、問題の概要を説明しています（ PDFダウンロード ）。
*コメントで述べたように、DNS応答には複数の結果が含まれる可能性があり、要求間で応答が変わる可能性があり、チェック時間の使用時間（TOCTOU）の問題が発生します。緩和、解決、検証を1回行い、最初に検証されたIPアドレスを使用してリクエストを作成し、Hostヘッダーを付加して正しい仮想ホストに到達できるようにします。
画像の代わりにURLを保存します。
さらに、これは情報とプライバシーのリスクを追加します。 visualデモで示します。
StackExchangeに画像をアップロードしようとすると、画像がimgur.comによってhostedを取得することがわかります。 SEサーバーは画像をフェッチし、そのコピーをprivateサーバーにアップロードします。
実験には人気のある無垢のミームを使用します。私たちのショーの次のURLから始めましょう：https://i.imgflip.com/2fv13j.jpg。このデモを機能させるには、ディープリンクを使用する必要があることに注意してください。
StackExchangeアップロードツールを使用してthis投稿に添付します。質問のシナリオとまったく同じです。
????こちらが新しくアップロードした画像です！
さらに深く調べて、さらに調査してみましょう。画像がsourced from imgur.comではなく from imgflip.comになっていることに注意してください。 2つのURLの名前が似ている場合は、しばらくお待ちください。開発者ツールを開くと、画像がポイントされている場所を確認できます
プライバシーの問題
Http（s）：//オンラインリソースのみをリンクすると、ブラウザはそのサーバーへの接続を開始し、多くの情報を送信します。トラフィックの多いWebサイトでは、Webサイトの所有者は、このSecurity SEページにアクセスするユーザーのIPアドレスに関する多くの情報、および（有効になっている場合）紹介リンクとサードパーティのCookieを取得します。サードパーティのCookieがデフォルトで有効になっていることを考慮すると、不正な方法で使用すると、ユーザーIDが漏洩する可能性があります。
StackExchangeは、投稿にアップロードする画像を所有することで、imgflip.comが誰が自分の写真を表示しているのかを認識できなくなります。
そして、2番目の部分で見るように、将来的にchangeに変更します。
欺瞞のリスク
static " Front-page-ish "シンプルなWebサイトをデプロイするための努力に関係なく、リモートリソースへのURLは常に解釈済みリクエストごとにサーバーによって。末尾が.jpgの場合もありますが、サーバーはスクリプト言語を使用してリクエストを解釈し、最終的には提供するコンテンツを選択するを使用している可能性があります。
これで訪問者のプロファイルを作成したので、訪問者にどのコンテンツを表示するかを選択できますlive。ライブ詐欺の例として ber-Greyballの場合 を考えます。人気の出会い系アプリTinderは、同様のソフト禁止またはグレーリスト技術を使用しています
当局には知られていない、彼らがアプリで見たデジタルカーのいくつかは実際の車を表していない。そして、彼らが呼ぶことができたUberドライバーもすぐにキャンセルされました。アプリから収集されたデータやその他の方法に基づいて、Uberが[...警察官...]タグを付けたためです。
例として、サーバーはそのようなロジックを実装できます。無害なミームまたは望ましくないコンテンツをどこに配信するかを決定します。ユーザーの要求に基づいた政治広告（一部の Cambridge Analytic-thing？ を思い出させます）。とにかく、URLが変わることはありません。
CAの公言された利点は、クライアントが広告の「サイコグラフィックターゲティング」に活用できる広範なパーソナリティプロファイルを構築するのに十分なデータポイントをすべてのアメリカ人に持つことです
request for https://Host.com/images/img1.png
if (request comes from any of
StackExchange moderator or
Automated content filter or
Government enforcer or
Anything you can imagine)
{
decide to serve innocuous content
}
else if (request comes from a user you want to decept)
{
decide to serve a targeted advertising or deceptive content somehow
}
この画像を見て、リアルタイムフィルタリングで何が起こるかを確認してください。同じURLでも、ユーザーごとに異なるコンテンツが表示されます。自分を政治的に中立に保ってくれたBuckethead卿に感謝します。
同じURLで、whoが要求しているコンテンツが異なるコンテンツを提供できるようになりました。
これらの理由により、帯域幅とディスク容量の制約に関して、リモートリソースの永続的なスナップショットを取得するために、リモートリソースをフェッチすることを検討する必要があります。
ここでは、1）EXIFタグを保持すること、および2）独自のコーデックで画像を再エンコードして、さらなるペイロード攻撃を防ぐことについては、ここでは説明しません。
画像をアップロードする代わりに、ユーザーは画像の（自己ホスト型）URLを提供できます。画像の代わりにURLを保存します。
つまり これらの種類のJPEG ？
それは悪い考えです。まず、画像を使用するたびに画像の有効性を確認する必要があります。それには時間がかかります。私はデータベースが他のユーザーによって使用されていると想定し、データベースのユーザーがどのような種類の悪意のあるJPEGを提供されるかを制御することはできません。悪意のある画像を取得することを懸念していますが、データベースを使用する他のユーザーにそのような悪意のある画像を取得させてもかまいません。
だから、今のところそれほど良いことではありません。
自分では、信頼できないソースからの入力を処理するのと同じように画像を処理します。つまり、画像が正しいことを確認します。いくつかの標準形式に変換することをお勧めします。確実に再エンコードすることをお勧めします。