ユーザーがシステムに履歴書をアップロードして、管理者がダウンロードできるアプリケーションを構築しています。アップロードできるファイルのコンテンツタイプの制限について議論しています。
どのような種類のコンテンツでもアップロードできるようにすることで、セキュリティ上の懸念を正確にまとめるのに苦労しています。
コンテンツタイプのアップロードを許可するセキュリティリスクはありますか?
ファイル自体には固有の「コンテンツタイプ」がないことに注意する必要があります。ファイルはバイトの集まりであり、名前があります。 Webサーバーからファイルをダウンロードするとき、サーバーはinfersコンテンツタイプ(「application/pdf」など)を見つけることができる手がかりから、主にいわゆる「拡張子」(ファイル名の最後の数文字、たとえば ".pdf
"はPDFファイル)を示し、ファイルの内容自体も示す場合があります。たとえば、WebサーバーがHTMLファイルを配布する場合、ファイルヘッダー内で"次のように、Content-typeのデフォルトの選択をオーバーライドするmeta "タグ:
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
</head>
したがって、サーバー上で2つの操作を行います。アップロードとダウンロードです。アップロードはほとんど安全です。ファイルが来て、保存されます。ダウンロードは心配になる可能性があります。管理者がファイルをダウンロードするときは、Webブラウザー内のリンクをクリックしてダウンロードします。前述のように、Webサーバーはコンテンツタイプを推測します。次に、Webブラウザーはcontent-typeを使用して、ダウンロードしたファイルをどうするかを決定します。これは、必ずしも「ユーザーにどこかに保存するように勧める」とは限りません。たとえば、誰かが.html
ファイル、WebブラウザーはそれをHTMLとして解釈し、それを表示し、おそらくその中にあるJavascriptを実行します。さらに、ファイルは独自のサーバーから取得されるため、管理者のWebブラウザーがデフォルトでそのファイルを信頼する可能性があります。その時点でさまざまな厄介なことが起こるかもしれません。
したがって、コンテンツタイプをフィルタリングする必要がありますその下ダウンロード時にファイルを提供します。また、ファイルが管理者システムに保存されたばかりの場合でも、.exe
ファイルをクリックすると、管理者が実行するファイル。
さらに、サーバーにあらゆる種類のファイルを表示させることは、攻撃を悪用する間接的なツールになる可能性があります。攻撃者がサーバー上の任意のファイルの実行を強制することができるいくつかのセキュリティホールがあります。フィルタリングされていないアップロードメカニズムにより、攻撃者は最初にサーバー上で実行させたい実行可能ファイルの種類を正確にプッシュできます。
通常、問題はアップロードが原因ではありませんが、hostingおよびsame-Origin/malwareの問題です。
次のシナリオを想像してみてください。
https://example.com/alice/foo
から提供されるファイルをアップロードします。https://example.com/bob/bar
から提供されるファイルをアップロードします。.../alice/foo
をダウンロードし、後で.../bob/bar
をダウンロードします。アリスとボブはオリジンhttps://example.com/
を共有しています。ファイルがブラウザーによって静的コンテンツとして扱われるだけであれば、問題は発生しません。しかし、ファイルにスクリプトを含めることができる場合、アリスはcookieを介して資格情報を保存し、ボブはそれらの資格情報を傍受することができます。
HTML、SVG、Flashなどの多くのファイルタイプでスクリプトを埋め込むことができます。アクティブコンテンツをホストすると、同じ種類の同じ問題が発生します。