［無視できない］IEのContent-Type無視：教科書に載らないWebアプリケーションセキュリティ（2）（2/2 ページ）

[はせがわようすけ，ネットエージェント株式会社]

ファイルタイプ決定の例

　実際に、Content-TypeとURLからどのようなファイルタイプが決定されるか、いくつか例を示してみます。

●例1

　Content-Typeがtext/plainの場合、Content sniffingが有効であればContent sniffingに基づきファイルタイプが決定されます。

　Content sniffingが無効であればプレーンテキストとして表示されます。

URL	http://example.com/search.cgi?format=txt
Content-Type	text/plan

●例2

　Content-Typeが未登録のため、QUERY_STRINGの末尾の“.html”によって、ファイルタイプはHTMLとなります。

URL	http://example.com/search.cgi?abcd.html
Content-Type	application/x-unknown

●例3

　Content-Typeが未登録のため、URL拡張子“.pl”よりファイルタイプは“.pl”となりますが、一般的にはファイルタイプ“.pl”がレジストリに登録されていないため、ダウンロードダイアログが表示されます。

URL	http://example.com/search.pl?abcd.html
Content-Type	application/x-unknown

●例4

　Content-Typeが未登録のため、URL拡張子“.html”によって、ファイルタイプはHTMLとなります（PerlのようなCGI形式のWebアプリケーションでは、PATH_INFOとして余分な文字列を与えても動作します）。

URL	http://example.com/search.pl/a.html?abcd.html
Content-Type	application/x-unknown

Webアプリケーション側の対策

　これまで説明したように「HTMLでないものをHTMLと見なすことによるXSS」が発生する原因としては、

• Content sniffing
• 未登録のContent-TypeとURLの組み合わせ

の2種類による攻撃があるといえます。

　前者についてはこれまでも経験則として、「text/plainやimage/bmpは避ける」「（ユーザー側の対策として）『拡張子ではなく、内容によってファイルを開くこと』を無効に設定する」ことがいわれてきました 。

　これらに加え、後者の未登録のContent-TypeとURLの組み合わせによるXSSを防ぐためには、Webアプリケーション側で対象としているIEが対応しているContent-Typeのみを生成するというルールが必要となります（あるいはContent-Disposition:attachmentの付与などの回避策もありますが）。

　特に、IE6ではapplication/atom+xmlのような新しいメディアタイプに対応していないといったバージョン間の差異についても注意が必要です。

---

　このように、IEのContent-Type無視およびファイルタイプ決定の処理は非常に複雑怪奇なものとなっています。特に、IEやWindows自身のバージョンに依存する部分も多く、すべてを把握することは、もはや不可能なのかもしれません。

　「HTMLではないものをWebブラウザが独断でHTMLと判断してしまう」というのは、セキュリティ上の観点から考えれば、Webブラウザ側で真っ先に修正すべき点です。しかし、「互換性と利便性の確保」という点を優先するIEではなかなか修正の難しい問題のようです。それでも、IE8においては本稿で取り扱っている内容に関する処理が大きく改善されているようで、数年前に比べると少しずつではありますが前進していると感じます。

　IE8での変更点についてはまだ詳細を調べ切れていないのですが、今後機会があればIE 8での改善点などについても調査のうえ書いてみたいと思います。