スクリプトやマルウェアが埋め込まれていないかどうかを確認するために、画像をどのように分析しますか?使用するツール/方法は?
ユーザーがアップロードした画像ファイルを受け入れ、Webアプリケーションを介して他のユーザーに提供することを想定しています。その場合、ここには2つの異なる攻撃ベクトルがあります。
(1)画像と別のタイプの両方として解釈できるファイル。
これも:
(1a)HTMLタグが埋め込まれたファイル。これは、コンテンツの傍受を行うブラウザーによってHTMLとしてロードされ、ドメインのセキュリティコンテキストで実行される内部スクリプトコンテンツにより、従来のJavaScript XSSを引き起こします。
(1b)プラグインデータとして解釈できるファイル、特にJava(GIFAR攻撃)。これらをホストするだけで、JavaおよびFlashは、インクルードページではなく、ファイルをホストする場所に基づいています。
このようなファイルは通常、予想されるタイプの有効なイメージである可能性がありますおよび脆弱なターゲットタイプとして機能します。
送信された画像を処理し、ロードして再保存することにより、これらの攻撃を困難にすることができます。とにかく、トリミング、サイズ変更、または品質レベルの変更を行うためにこれを行っている可能性があります。
原則として、誰かが画像を送信することは可能です。これは、使用しているアルゴリズムによって圧縮されたときに、<script>
またはその他の悪いコンテンツが含まれていますが、これはおそらく実際には非常に実用的ではありません。
どちらの方法でも、スクリプトを実行したり、CookieをメインのWebサイトドメインと共有したりできない別のドメインからユーザーが送信したファイルを提供することにより、この攻撃を緩和する必要があります。 (共有の祖先ドメインで何も処理されない限り、サブドメインにすることができます。)
(2)ブラウザの画像デコーダのバグを悪用して不正な画像を実行し、任意のコードを実行させる。これらは今日では一般的ではありませんが、過去にイメージデコーダーのバグがあり、さらに発生する可能性があります。
これは、イメージをロードして再保存することでも無効にできます。ロード時にエラーが発生しないだけでも、通常は良い兆候です。ただし、独自のイメージデコーダーにバグがあり、サーバー側がまったく同じ問題に対して脆弱になる可能性があると考えられます。
したがって、サーバー側の画像処理コンポーネントが最新であることを確認し、可能な場合は、受け入れられる入力形式の数を制限して、攻撃対象領域を減らします。これがアプリの脅威である可能性がある場合は、より低い特権のプロセス(privsep)で画像処理を実行することも検討してください。
処理のために画像をロードすると、非常に大きな画像(サイズや圧縮爆弾)によるサーバー側のサービス拒否攻撃のリスクも伴います。ロードする前に、画像ファイルのヘッダーからファイルサイズと解像度を確認してください。
アプリの内容によっては、不正な画像のエクスプロイトを検出することのメリットが限られている可能性があります(希少性は別として)攻撃者は通常、他の場所でホストし、画像または画像へのリンクを他のユーザーが送信したコンテンツに投稿するのが簡単です。 。
@bobinceの回答に加えて、画像メタデータに埋め込まれたスクリプトにも注意する必要があります。これは、たとえばユーザーが送信した画像のEXIFデータを表示している場合にリスクとなります。 (私は、この注入方法に基づいた人気のある画像ギャラリーでXSSの脆弱性をいくつか見つけました。)
多くのツール/ライブラリが画像のメタデータを表示します。 Exiv2 は、EXIFおよびIPTC画像のメタデータを表示および操作するための便利なツールです。
Internet Explorer> = 8が宣言されたcontent-typeから離れてMIMEスニッフィングを行わないようにするには、X-Content-Type-Optionsを追加しますヘッダーに値nosniff。 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx を参照してください