17

ASP.NET Web アプリを開発していますが、ユーザーがローカル システムから画像をアップロードするか、URL を画像に渡すことができるようにしたいと考えています。画像はJPGまたはPNGのいずれかです。これを行う際に、どのようなセキュリティ問題を考慮する必要がありますか? JPG ファイル内にコードを埋め込むさまざまな方法を見てきました。C# (または外部ライブラリ) に、ファイルが JPG/PNG であることを確認できるメソッドはありますか?そうでない場合、エラーがスローされますか? せめて、アップロードした画像を格納するディレクトリを閲覧不可にして最大サイズを1MBに制限しているのですが、さらなるチェックを実装したいと思います。

アドバイスをありがとう。

4

4 に答える 4

14

C# (または外部ライブラリ) に、ファイルが JPG/PNG であることを確認できるメソッドはありますか?そうでない場合、エラーがスローされますか?

かもしれませんが、それ自体はあまり役に立ちません。有効な画像形式であり、IE のコンテンツ スニッフィングが遭遇するアクティブな HTML/スクリプト コンテンツを含むファイルを簡単に作成できます。または、懸念すべき壊れた Java および Flash オリジン ポリシーがあります。これは、サーバーのセキュリティ コンテキストへのスクリプト作成と同じ影響を与える可能性があります。

  1. 画像を処理 (切り抜き、サイズ変更など) して再保存すると、コンテンツ密輸攻撃を実行することが非常に困難になります。ただし、画像処理ライブラリの脆弱性によりサーバー側の悪用にさらされる可能性があるため、サーバー側のツールが常に最新であることを確認する必要があります。

  2. それができない場合、すべてのコンテンツ インジェクションの問題を緩和するための最善の策は、機密性の高い資格情報 (Cookie、基本認証) のいずれにもアクセスできない別の [サブ] ドメインから画像を提供することです。メインサイトの.

  3. この目的で などのサブドメインを使用している場合images.example.com、メイン サイトには からのみwww.example.comアクセスでき、からはアクセスできません example.com。そうしないと、挿入されたコンテンツが IEimages.example.comの Cookie にアクセスできます。一般に、望ましくない Cookie の漏えいを防ぐために 301 リダイレクトする必要があります。example.comexample.comwww.example.com

  4. 応答にヘッダーX-Content-Type-Options: nosniffを追加して、IE8 からのコンテンツ スマグリング攻撃をブロックします。（残念ながら、以前のバージョンでは役に立ちません。）

また：

  1. ユーザーが指定したファイル名をサニタイズするのは困難です。特に、使用可能なファイル名に関するルールが実際に複雑な Windows サーバーでアプリが実行されている可能性がある場合はなおさらです。開始するのに適した場所は、英数字のみを許可し、独自のファイル拡張子とプレフィックスを追加することです。(Windows で予約されているファイル名と空のファイル名を避けるために、プレフィックスが必要です。)

  2. より良い: 実際のファイル名として使用する代わりに、ユーザーが指定したファイル名をデータベースに保存します。

ファイルアップロードのセキュリティ問題の詳細については、この質問を参照してください。

于 2010-04-07T22:14:35.827 に答える
5

これは絶対的な地雷原です。考慮すべき事項 (必ずしも完全なリストではなく、保証がないなど)。

  • 一部の人々は解析に正規表現を使用しているため、ファイルにコードが含まれているかどうかを知る方法はありません。ZIP ファイルのディレクトリは最後にあります。Sun/Oracle Java PlugIn/WebStart は、「GIFAR」攻撃を回避するために、ファイルが ZIP ローカル ヘッダー/エントリ マジック番号で始まることをチェックするようになりました。
  • 同じオリジンの問題を回避するために、別のドメインからサービスを提供します。
  • 同じオリジンの問題を回避するために、別の IP アドレスからサービスを提供します。
  • ファイルがゼロデイ バッファ オーバーフローなどを悪用しているかどうかを確認するのは少し難しいです。無限ループを悪用して DoS を作成することさえあります。
  • 画像を再エンコードすることをお勧めします。
  • URL/ファイル パス名には注意してください。オプションを指定する場合は、ホワイトリスト チェックを使用します。特に NUL 文字は「楽しい」ものです。ディレクトリ トラバーサル攻撃も参照してください。一般に、特定のコンテンツのファイルを既知の場所に配置できることは、少なくとも非常に危険です。
  • または、サイズが適切であることを確認したい画像。巨大なイメージを解凍すると、DoS 攻撃につながる可能性があります。また、圧縮アルゴリズムでは、多くの場合、些細なデータを大きな係数で圧縮できることに注意してください。
于 2010-04-07T21:29:28.630 に答える
4

サーバーで使用されるファイル名をユーザーに決定させないでください。[生成された guid].jpg を代わりに使用し、必要に応じてデータベース テーブルに使用したファイル名を入力します。

#12 を参照してください: http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html

ファイル名またはパスの外部制御 ファイル名を作成する際に部外者の入力を使用すると、結果のパスが意図したディレクトリの外を指している可能性があります。攻撃者は、複数の「..」または同様のシーケンスを組み合わせて、オペレーティング システムを制限されたディレクトリの外に移動させる可能性があります。その他のファイル関連の攻撃は、ファイル名の外部制御 (シンボリック リンクの追跡など) によって単純化されます。これにより、アプリケーションは、攻撃者が直接アクセスできないファイルを読み取ったり変更したりします。プログラムが昇格された特権で実行されており、ファイル名を入力として受け入れる場合も同じことが当てはまります。URL にも同様のルールが適用され、部外者が任意の URL を指定できるようになります。

URL にも注意してください。絶対的な外部 URL であることを確認してください。そうすることで、独自の Web サーバーを使用して機密ファイルを LAN からアクセス可能な領域にコピーすることができなくなります。 Web サーバーで実行されているコード。

于 2010-04-07T21:18:16.377 に答える
0

画像を処理するためのサービスとしてのインフラストラクチャを使用できます。たとえば、当社のソリューション - Uploadcare:

https://uploadcare.com

アップロードされた画像に画像操作のいずれかを適用すると、画像が変更されるため、ファイル内に埋め込まれている可能性のあるコードは破棄されます。

于 2014-12-04T22:10:20.207 に答える