前文
したがって、IE はMime-Type スニッフィングを行います。その部分は古いニュースです。
これに対抗する方法の提案は、「コンテンツ タイプの IE トラストを提供する」(つまり、テキスト/プレーンまたはアプリケーション/オクテット ストリーム以外のもの) または「ファイルの先頭に余分なデータを追加する」という行に沿っている傾向があります。それは間違いなくあなたが提供しているタイプです。
現在、メッセージの添付ファイル (電子メールなど) を許可し、場合によってはインライン (電子メールなど) で表示できるようにする必要があるアプリケーションに取り組んでおり、XSS ベクトルをクローズアップしたいと考えています。IE の MIME スニッフィング (パッチを適用していない IE6 では、IE6/Win2000 などでサポートする必要があります) は、これらのベクトルの 1 つです。htmltext/plainコンテンツを含むファイルは html としてトリガーされます。この時点では、再コーディングはオプションではありません。ユーザーが提供した添付ファイルを変更できるのは、ファイルの悪意にまったく疑いがなく、誰かが HTML をテキストとして送信したい場合に限られます。
現在、Microsoft の MSDN の記事は、宣伝されているよりも状況を修正する方が簡単である可能性があることを示唆しています。
Internet Explorer が 指定され たContent-Typeを認識していて、Content -Dispositionデータがない場合、Internet Explorer は「MIME スニフ」を実行します [...]
すごい！
IEも、それを確実にインストールするための現在の手段も持っていないことを除いて（これはWeb開発者にとってかなり悲しい状態であることを認識しています。これをすぐに修正したいと思っています）、これは灰色の理論であり、私にはまったく見えませんいずれかの方法で確認します。地元の情報筋によると、行はごちゃごちゃしているとのことです - IE は、 Content-Disposition: inline /であり、 <default>-Typeの好みに十分に具体的でないものは何でもスニッフィングします。
しかし、x-* ( RFC の 'extension-token' ) はどうでしょうか?
ブラウザーがContent-Disposition:<extension-token>を処理する方法をグーグルで検索しようとしても、何も得られませんでした (私のやり方が間違っているだけかもしれませんが、最近、グーグルに対する私の理解が著しく低下しています)。有望に見える質問を 1 つ見つけましたが、スレッド作成者側の誤解であることが判明しました。
質問
Content-Disposition: inlineを明示的に渡すと、IE は本当に Mime を盗聴しますか?
もしそうなら: ブラウザがContent-Disposition: を<extension-token>処理する方法を知っている人はいますか?
彼らが私の目的のために無害な方法でこれを行う場合、それがデフォルトと同義であると推定することによって（事実上「インライン」ですが、どこにも定義されていないと聞きましたか？）、IEがMime sniffしないようにするのに十分具体的ですか？それとも、この道を追求することを考えて、実際に自分の足を撃っていますか?