web-dev-qa-db-ja.com

X-Content-Type-Optionsは本当にコンテンツスニッフィング攻撃を防ぎますか？

もつれたウェブでミハル・ザレフスキーは言う：

特に不明なドキュメントタイプの場合は、Content-Type：application/octet-streamを使用せず、代わりにapplication/binaryを使用してください。 Content-Type：text/plainを返さないでください。

たとえば、実行可能ファイルまたはソースアーカイブをapplication/octet-streamとして返す場合、コードホスティングプラットフォームは注意が必要です。HTMLとして誤って解釈され、インラインで表示される可能性があるためです。

このような場合にHTMLを検出するためにInternet ExplorerとSafariに後で実装されたtext/plainロジックは、本当に悪いニュースです。このMIMEタイプを安全に使用してユーザー固有のプレーンテキストドキュメントを生成する機能をWeb開発者から奪い、代替案を提供しません。 。これにより、多くのWebアプリケーションの脆弱性が発生しましたが、今日まで、Internet Explorer開発者は後悔がなく、コードのデフォルトの動作を変更していません。

サイトはX-Content-Type-Options:nosniffを使用しています。著者はこのヘッダーについて次のように述べています。

このヘッダー[X-Content-Type-Options]の使用を強くお勧めします。残念ながら、そのサポート[...]は、他のブラウザでは限られたサポートしかありません。言い換えれば、コンテンツの盗聴に対する唯一の防御策としてそれを信頼することはできません。

どのようなコンテンツスニッフィング攻撃X-Content-Type-Options:nosniffでは防げませんか？ Content-Typeではなく、text/plainをユーザーに返す必要がありますか？

appsecweb-applicationattacksfile-upload
19
Andrei Botalov

背景。X-Content-Type-Options:は MIME content-sniffing attack に対して defend に対して設計されたヘッダーです。 MIMEコンテンツスニッフィング攻撃は、ユーザーがコンテンツ（画像、ドキュメント、その他のファイルなど）をWebサイトにアップロードすることを許可した場合のリスクであり、他のユーザーがダウンロードできます。

@Rookが言うように、これはネットワークトラフィックの盗聴/捕捉とは関係ありません。

それによって防げないのはどのような攻撃ですか？X-Content-Type-Options:は一部のブラウザーでのみサポートされており、他のブラウザーを使用するユーザーに対する攻撃を保護しません。特に、IE、Chrome、および Firefox 5 で想定されています。参照 ユーザーがコンテンツを自分のサイトにアップロードできるようにすることのセキュリティリスクは何ですか？ マルウェアまたは不快なコンテンツのアップロード、脆弱性を悪用するコンテンツのアップロードなど、他の攻撃では防止できません。ユーザーのブラウザなどで.

どのコンテンツタイプを返す必要がありますか？そのファイルに適切なコンテンツタイプを返す必要があります。危険なコンテンツタイプの信頼できないコンテンツをユーザーがアップロードできないようにする必要があります。詳細については、次の質問に対する回答をご覧ください。

  1. ホワイトリストに記載されたMIMEコンテンツタイプのみでユーザーがアップロードしたファイルを提供しても安全ですか？

  2. ユーザー提供のMIMEタイプを保存して再生しても安全ですか？

  3. MIMEスニッフィング保護

  4. サイトにアップロードするファイルのコンテンツタイプを制限する必要があるのはなぜですか？

  5. ユーザーにコンテンツを自分のサイトにアップロードさせることによるセキュリティ上のリスクは何ですか？

  6. 画像の脆弱性からどのように保護できますか？

  7. ファイル拡張子とMIMEタイプ（ファイル-i -bの出力として）の組み合わせを使用して安全でないファイルを特定しますか？

このトピックは、このサイトの他の場所で広範囲に議論および文書化されているので、そこにある有用なアドバイスをすべて繰り返すことはしません。

更新：Content-TypeおよびX-Content-Type-Optionsヘッダーは、セキュリティ上適切ではありません。どうやら FlashはContent-Typeヘッダーを無視します 。これにより、悪意のあるSWFをロードできるようになり、XSSで行うすべてのことを実行できるようになります。 （ため息、愚かなフラッシュ。）残念ながら、この攻撃を阻止できるファイルコンテンツタイプのホワイトリストはありません。したがって、安全な唯一の解決策は、ユーザーがアップロードしたコンテンツを別のドメインでホストすることです。

23
D.W.

これは、メールで受け取ったMichal Zalewskiの回答です。

簡単に言えば、それはMSIEで機能し、一部の特定のケースでのみ機能するということです。他のほとんどのブラウザでの（非常に熱心な）スニッフィングから保護することはできません。しかし、より重要なのは、プラグインが上で概説したcrossdomain.xmlリスクなどのことをやめさせないことです。また、MIMEタイプが一致しないサブリソースの読み込みを必ずしも防ぐわけではありません（つまり、<embed>を介してapplication/x-shockwave-flashとして画像を読み込む）。

6
Andrei Botalov

X-Content-Type-Options：nosniffで防げないスニッフィング攻撃は何ですか？

X-Content-Type-Optionsを知らないツールによるスニッフィング：一部のブラウザ、およびネットワークリソースを取得できるプラグイン。 （たとえば、歴史的にJava GIFAR、Flash loadPolicyFile ...）

Text/plainではなく、どのContent-Typeをユーザーに返す必要がありますか？

良い答えはありません。信頼できないテキストファイルをホストする必要がある場合は、通常の緩和策を講じて別のホスト名（理想的にはIPアドレス）でホストする必要があります。

代替：HTMLエンコード、<pre>を追加し、text/htmlとして機能します。

3
bobince