ホワイトリストに記載されたMIMEコンテンツタイプのみでユーザーがアップロードしたファイルを配信しても安全ですか？
アプリケーションを開発するとしましょう。
- すべてのユーザーが、ホワイトリストのMIMEコンテンツタイプと拡張子（Wordおよびpdf）のみのファイルをアップロードできるようにします。
- 許可された拡張子とコンテンツタイプを持つファイルを提供します。
これはセキュリティリスクですか？どうして？
（マジックヘッダーを使用して）ファイルバイトからコンテンツタイプを推測し、ヘッダーで指定しているコンテンツタイプを破棄するブラウザーはありますか？
これを安全にするための解決策は何ですか？アップロードするファイルに、クライアントが提供するMIMEタイプと一致するマジックバイトがあることを確認する必要がありますか？
この質問は ユーザー提供のMIMEタイプを保存して再生しても安全ですか？ に似ていることは知っていますが、重複しているとは思わないでください。
Krzysztofで概説されているHTMLコンテンツの傍受。 IEのみでなく、主に。
jar：URLの脆弱性 古いFirefoxで
JARファイルに似たコンテンツ（ [〜＃〜] gifar [〜＃〜] et al）-Javaアーカイブとして解釈される可能性のある何かをホストすることは、XSSを意味するため、 Javaによって適用される別の同一生成元ポリシーの。
Crossdomain.xmlコンテンツのように見える何かを含むファイルは、loadPolicyFile呼び出しのターゲットにして、Flash呼び出し元のXSSを取得できます。
アップロードするファイルに、クライアントが提供するMIMEタイプと一致するマジックバイトがあることを確認する必要がありますか？
カメレオン（どちらのタイプでも同等に有効なファイル）に対して不十分です。
これを安全にするための解決策は何ですか？
唯一の強力な緩和策は、信頼されていないアップロードされたコンテンツをメインサイトとは異なるホスト名から提供することです。
直接のJavaScript XSS/Same Origin Policyだけが心配な場合は、その異なるホスト名をメインサイトのサブドメインにすることができます。
Cookie（セッションIDなど）を読み取らないようにする必要がある場合は、独立したサブドメインである必要があります。つまり、www.example.comにメインサイトがある場合はinsecure.example.comになる可能性がありますが、その場合、サイトが裸の「example.com」で応答することを許可してはいけません。 example.comのCookieがIEのinsecure.example.comに継承されるのを防ぐことはできません。ベストプラクティス：example.comへのすべてのアクセスをwww.example.comにリダイレクトします。
Cookieの強制を防ぐ必要がある場合は、完全に異なるドメインである必要があります。つまり、insecure.example.comはwww.example.comが読み取るCookieを書き込み、www.example.comが設定したCookieを上書きする可能性があります。これはそれほど深刻ではない脆弱性です。Cookieを読み取る機能は通常、セッションのハイジャックにつながりますが、Cookieの強制はサービス拒否のみにつながります（www.example.comはCookieなしでは機能しないため）。
古いJavaプラグインの脆弱性を使用してCookieを盗むことを懸念している場合、または他のサービスをポートで実行している場合は、別のIPアドレスで提供する必要があります。アプレットにアクセスできるようにしたくない。
それらの間で、ブラウザとプラグインはアップロードされたファイルを安全にホストすることをひどい試練にしています。
残念ながら、あなたの例では、Internet Explorerはファイルコンテンツの最初の256バイトからMIMEタイプを検出しようとします（これはMIMEスニッフィングと呼ばれます）。主題に関する MSDNドキュメントからの引用 ：
2。サーバーから提供されたMIMEタイプが既知またはあいまいな場合（私のメモ：application/pdfは既知）、バッファーがスキャンされます実際のコンテンツからMIMEタイプを確認または取得します。 正の一致が見つかった場合（ハードコードされたテストの1つが成功）、このMIMEタイプがすぐに返されます最終決定として、サーバー提供のMIMEタイプをオーバーライドします（このタイプの動作は、を識別するために必要です。 text/htmlとして送信されるgifファイル）。スキャン中に、バッファが主にテキストかバイナリかが判断されます。
次のPHPファイルを使用して、この動作を確認しました：
<?php header('Content-Type: application/pdf'); ?>
<html>
<p>Hello, <b>world</b></p>
これはIE8/WinでHTMLコンテンツを表示しますXP SP2。
このプロセスは、レスポンスでX-Content-Type-Options: nosniff HTTPヘッダーを指定することで変更できますが、 IE8 + でサポートされています。幸いなことに、他のブラウザーはHTTPヘッダーを信頼しており、MIMEスニッフィングははるかに軽量です。 Firefox docs 。さまざまなブラウザで非常に優れた whitepaperドキュメントMIMEスニッフィング があります。
可能であれば、ファイルの内容からマジックバイトを確認することもお勧めします。 Content-disposition: attachmentヘッダーを使用することもお勧めします。
コンテンツスニッフィング。提案は十分ではありません。コンテンツスニッフィング攻撃に対して脆弱です。 コンテンツスニッフィング攻撃を防ぐ の戦略については、他の場所で書いています。さまざまな防御があります。主なものは次のとおりです。
応答に
Content-Type:ヘッダーを含めます。有効なMIMEタイプが含まれていることを確認してください（無効なMIMEタイプは避けてください）。応答に
X-Content-Type-Options: nosniffヘッダーを含めます。これにより、IEの最新バージョンでは、IEのコンテンツスニッフィングアルゴリズムがオフになります。ブラウザーでコンテンツを表示する予定がない場合は、
Content-Disposition: attachmentを設定して、ブラウザーにコンテンツをファイルのダウンロードとして処理させることができます。
これらの手順でも十分であるとは限りません。たとえば、ユーザーがIE6を使用している場合でも、脆弱性が存在します。
（これが煩わしいように聞こえる場合は、間違いありません。長年Web標準に違反し、それについて何かをするための嘆願を無視した不必要なデフォルト設定を含めたことで、Apacheの人々を非難します。残念ながら、今では手遅れです。危険なことを行うブラウザの大規模な展開ベースで。）
個別のドメイン。より良い防御策は、ユーザーが提供したコンテンツをユーザーがアップロードしたコンテンツにのみ使用される個別のドメインでホストすることです。このようにして、コンテンツ盗聴攻撃が成功しても、サイトのコンテンツを攻撃することはできません。 1人のユーザーのアップロードが他のユーザーのアップロードを攻撃する可能性はありますが、これは許容できる場合があります。
ホワイトリストを確認してください。PDFおよびWordファイルは無害であると想定しているようです。しかし、これらは2つの強力な機能であり、危険なファイル形式。PDFはベクターであることで悪名高い。悪意のあるPDFファイルがたくさんあり、多くの古いファイルを正常に侵入できるPDF =閲覧者。PDFリスクが非常に高いため、Chromeは、PDF PDFビューア内のドキュメント。Wordも強力で危険なファイル形式であり、攻撃のホストになる可能性があります。このため、WordやPDF無害。
ユーザーをGoogleドキュメントにリダイレクトして、Googleドキュメントを介してブラウザでWord/PDFファイルを表示できる場合があります。 GoogleはWord/PDFファイルをHTMLに変換してから、閲覧者のブラウザに送信します。これは、状況によっては許容できない場合があります。
ウイルスのファイルアップロードをスキャンします。ウイルスまたはマルウェアスキャナーを使用して、ユーザーがアップロードしたすべてのコンテンツのウイルスをスキャンすることをお勧めします。 PDFファイルについては、次も参照してください マルウェアのスキャン方法PDF？）を参照 。アップロードが完了したらすぐにスキャンすることもできます。古いファイルを定期的に再スキャンすることも検討してください（アンチウイルス/マルウェアの定義が更新されているため、これにより、以前は検出されなかったマルウェアが検出される場合があります）。
詳細情報。安全なコーディング標準の ファイルのアップロードに関するMozillaのチェックリスト も参照してください。これは、優れたセキュリティプラクティスのかなり良いリストです。
要約。要約すると、使用できる最も強力で効果的な防御策は、ユーザーがアップロードしたコンテンツを別のドメインに配置することです。次に、追加の保護として、ここに記載されている他の防御策を検討することをお勧めします。
更新：私はあなたのスキームのもう一つの問題について学びました。どうやら FlashはContent-Typeヘッダーを無視します 。これにより、悪意のあるSWFをロードできるようになり、XSSで行うすべてのことを実行できるようになります。 （ため息、愚かなフラッシュ。）残念ながら、ホワイトリストの量はこの攻撃を止めることができません。したがって、ユーザーがアップロードしたコンテンツを別のドメインでホストすることが安全な解決策であると思われます。
他の2つの答えは良いと思います。しかし、ここでもう1つ検討する必要があります。提供するコンテンツの種類を完全に制限できたとしても、WordドキュメントとPDFドキュメントは、それ自体が悪意のあるものである可能性があります。
A PDF docは、古いバージョンのAdobe Readerに存在する数百の脆弱性のいずれかを悪用する可能性があります。これに対する最善の緩和策は、アップロードされた各ファイルをウイルス対策/マルウェア検出でスキャンすることです（ただし、それでもまだウイルスシグネチャの猫とマウスの性質による制限付きの軽減策。