content-type：imageはどのようにしてJARファイルに感染する可能性がありますか？
ノートンライフロックは、IE Javaエクスプロイト（既知の脆弱性）を持つユーザーを対象としたマルバタイジングキャンペーンに関するニュースを公開しました。ある時点で、ユーザーは悪意のあるユーザーにリダイレクトされると説明しています。次のGETを使用するドメイン：
ご覧のとおり、ユーザーはIlns0.gifを探しており、GZIPエンコーディングを受け入れます。
サーバーはContent-Type: image/gifで応答し、感染した.jarファイルを配信します。
間違ったタイプを使用しても、ユーザーがファイルをロードすることはどのように可能ですか？サーバーが予期しないコンテンツを配信したときにブラウザが警告を表示しないのはなぜですか？
間違ったタイプを使用しても、ユーザーがファイルをロードすることはどのように可能ですか？
それをロードしているブラウザの場合、それは実際にGIFとして処理され、一般に失敗します。 （Webブラウザーにはコンテンツスニッフィングの問題がありますが、ここでトリガーされる問題はありません。）
ただし、<applet src>/<object data>属性が指しているアプレットをインスタンス化すると、Javaプラグインは、それに関係なく、アドレスをアプレットクラス/ jarとしてロードします。あなたがそれを提供するContent-Typeの。
（これは良い動作ではありませんが、継続的なMIMEの倦怠感の症状です-非常に多くのサーバーが間違って設定されているため、ブラウザー/プラグインは正しいメディアタイプを要求することについて厳密にしたくありませんが、UAはメディアタイプについて寛容ですつまり、怠惰な管理者はサーバーを正しく設定する必要がありません...）
Javaの同一生成元ポリシーの奇妙なバージョンが、含まれているドキュメントページではなく、主にクラス/ jarのソースで動作することを考えると、これは特に有害です-アプレットファイルを誰かのサーバーに置くことができれば、ある程度クロスすることができます-その中にサイトスクリプト。ただし、攻撃がこれを利用したようには見えません。エクスプロイトはオリジンに関係なく機能します。
有効なGIFとJARであるポリグロットファイル（「GIFAR」）を同時に作成することが可能である（/可能であった）ため、これを見つけるのは難しいことがよくあります。ただし、ここでも、これは行われていません。攻撃者はアプレットに好きなファイル名/タイプを選択でき、明らかにGIFはJARよりも目立たないと思っていました。
Content-Typeを尊重するだけでなく、IE do Content Sniffing ）には長年の問題（機能？）があります。これは主に歴史的な理由でまだ存在しています。あなたには能力があります。無効にするには-- MIMEタイプ検出 参照 機能コントロール -マシンをより安全にしたい場合は、一般的な「修正」以来、まだわずかに役立ちます不明なバイナリファイルタイプのサーバー側は、application/octet-streamとしてサーバーに送信するため、期待どおりに動作しない可能性があります（たとえば、ビデオが再生されずにダウンロードされる場合があります）。
この特定のエクスプロイトは、たまたまgifを使用している可能性があります。これは、電子メールスキャナーなどを通過して、電子メールのタグに簡単に埋め込まれるためです。