2016-07-25 10 views
0

Webアプリケーションの脆弱性に関する資料を調べながら、いくつかの質問が出ました。ここに詳細があります。Content-TypeとX-Content-Type-Optionsヘッダーのセキュリティ

  • burpのようなツール、APPScanは、アプリケーションサーバーからの特定の応答ヘッダーに基づいて脆弱性を報告します。お互いを補完する特定のヘッダーがあることを理解しました。 Exの場合: - 'Content-type'と 'X-Content-Type-Options' secondが 'nosniff'に設定されている場合、ブラウザはレスポンスボディをまったくスニッフィングせず、 'Content-Type'ヘッダーに設定された値を尊重します。同様に、HTTPリクエストは、 'Accept'種類のヘッダーを使用して期待される応答のタイプを示すこともできます。このような場合、「X-Content-Type-Options」が「nosniff」に設定されていない場合、そのようなレスポンスのリクエストにtext/plainのみのメディアタイプを示す「Accept」パラメータが含まれている場合、

  • このクエリのもう1つの拡張は、応答ヘッダーに次のフィールドが設定されている場合です。 Content-Type=text/plain X-Content-Type-Options=nosinff。私の意見では、これは脆弱性ではないので、2番目のパラメータはブラウザがレスポンスボディを盗聴するのを制限します。私の理解はセキュリティの観点から正しいですか?

+0

ヘッダーが "nosinff"に設定されているだけで、すべての種類のヘッダーのようにクライアントを変更でき、セキュリティを保証する完全な方法ではなく、脆弱性を止めることはありません。 – user3750649

答えて

0

攻撃者の観点から見ると、サーバーへのHTTPリクエスト全体は文字列のブロックに過ぎません。攻撃者は、標準のブラウザを使用して攻撃を実行する可能性はほとんどありません。これは、HTTPリクエストや、リクエストを傍受し、任意の形式の変更を可能にするプロキシツールを突沸させるスクリプトに似ています。 "nosniff"フラグは、これらのタイプのリクエストの変更には関係ありません。 HTTP要求の内容は、ユーザー全体が指示できるので、決して信頼しないでください。

関連する問題