JVN#51325625の変種について::IEにみられるクロスサイトスクリプティングの脆弱性

この文書はなにか

JVN#51325625 が示めすように、Internet Explorer には、EUC-JP で記述された特定の文字列の処理に問題があり、クロスサイトスクリプティング脆弱性が存在する。この脆弱性の変種として、EUC-JP のみならず ISO-2022-JP においても同様な脆弱性が存在していることを示す。

断り書き

個人的な調査によるものであり、全面的な解析を含んでいないため、情報に欠落している部分や、間違っている部分もあるだろう。本記事を読まれた方々は、あらためて検討しなおして頂きたい。

影響を受けるシステム

InternetExplorer 6 ないし 7

概略

Internet Explorer には、ISO-2022-JP のHTML文書として解釈された文書の解析にあたり、そのファイルに記述された特定の文字列の処理に問題があり、クロスサイトスクリプティング脆弱性が存在する。但し、正しいISO-2022-JP文字集合(RFC1468相当)に即した文書ファイルには本脆弱性は存在しない。

インパク

ユーザのウェブブラウザ上で任意のスクリプトを実行される可能性ほか、一般の XSS 脆弱性にともなう攻撃をこうむる可能性がある。

サーバ側対策

ISO-2022-JP の規格に即した文字集合のみブラウザサイドに送出する。非標準的拡張使用や、そもそも規格に合致するかどうかチェックせずに自由なバイト列を送出することなどを許容するウェブアプリケーションでは、ブラウザに対する攻撃の足場になってしまうだろう。
※例示すれば、漢字については、第一水準およびに第二水準に限っているかどうかが検査のひとつの目安になるだろう。
※第一水準第二水準の外の漢字については、数値文字参照で送出すればよい。ISO-2022-JPから切り替えてUTF-8を採用することなども有効な手だ。
※「過激なエスケープ」「英数字以外の文字はエスケープ」というアイデアの採用は簡明かもしれない。数値文字参照やscript要素の中身におけるユニコードエスケープなど。

ブラウザ側対策

根本的な回避策はない。IE6 や IE7 は使わないほうがよい。最新のIEに乗り換えるか他の最新のブラウザに乗り換えるべきだろう。それでもIE6やIE7を使用したければ、危険を軽減するための簡明な処置として[インターネット ゾーン]のセキュリティ レベルを『高』に設定するなどの対処が考えられよう。

PoC例

脆弱性を発見した当時の環境のものをサンプルとして以下に例示する。IE6 on Windows XP SP3 の環境であった。

  • ESC $ B [0xE0 0xA5] ESC ( B ⇒ [0x20 0x22]
  • ESC $ B [0xE0 0xBF] ESC ( B ⇒ [0x20 0x3C]
  • ESC $ B [0xE0 0xC1] ESC ( B ⇒ [0x20 0x3E]
上記のように、不正なコードが文字化けするので、HTMLのマークアップに介入することが可能である。上記以外にも使えるバイト列があるので、ブラックリストで拾う対処策は効果が出にくい。筆者は確認しなかったが、偽物のバックスラッシュなどを作成することも考えうる。いずれにせよ、クロスサイトスクリプティング攻撃の可能性がある。

うっかりしやすいシナリオをいくつか

既知の UTF-7 でのXSS攻撃のシナリオが、形を変えて使用できる可能性がある。title要素の中身などは要注意ポイントだ。HTTPレスポンスにてきちんとcharset指定を行っているか、あるいは、次善の策だがtitle要素の出現以前にmeta要素でしっかりとcharsetを明示しているかなど注意しておきたい。また、サーバサイドではShift_JISのつもりでHTMLを出力していたはずでも、社会工学的なテクニックなどを利用してISO-2022-JPでのエンコーディングに切り替えさせる攻撃も成立するかもしれない。(IE6やIE7では手動でメニューから切り替えが可能だ。)「ISO-2022-JPのHTMLなんて作っていない」からといって油断はできない。OutlookExpressもIEのエンジンを積んでいる。メールではISO-2022-JPが使われることがあるのでくれぐれも慎重に。文字化けを人為的にひきおこすルートがたくさんありそうだ。

留意事項

筆者の知る限りIE8においては、本脆弱性が対処された。さらに、別の構造でISO-2022-JPに関するXSS脆弱性が発生した。MS10-090 はそのためのパッチであった。( http://jvndb.jvn.jp/ja/contents/2010/JVNDB-2010-000065.html ) このパッチに不十分なところがあり一部のサイトでISO-2022-JPによるページの閲覧ができなくなったことは記憶に新しい。MS10-090のパッチもしくはそれ以前のパッチによって本脆弱性がIE6ないしIE7において解消されたかどうかについては筆者は情報を持っていない。なお、未確認情報であるがMicroSoft社は当初、IE8における本脆弱性の解消のためにXSSフィルターの拡充を考えていた形跡がある。その計画はなくなった模様だ。
また、「先行バイトの埋め込み( http://gihyo.jp/admin/serial/01/charcode/0006 )」によるXSS攻撃とは原理が異なるので、比較した上でよく吟味していただきたい。

お願い

情報をお持ちでしたら、是非記事を作成してください。 本記事からリンクさせていただきます。また、コメントなど頂ければ記事の修正をいたします。よろしくお願い申し上げます。

個人的な思い

上記事項は本当にブラウザの脆弱性と言い切ってよいのかどうか躊躇がある。 そもそも標準規格にそってきちんとしたHTMLを吐き出していれば、ブラウザ側もきちんと文書をパース可能であってXSS脆弱性の入り込む余地はないからだ。まじめに作ってあるウェブアプリならば気にしなくてよいのだ。サーバ側ででたらめなHTMLを吐き出しておいてブラウザサイドでXSS発生…本当にブラウザの脆弱性なのだろうか?
そうは言っても、やはりIEの不具合である。この脆弱性の発見当初、いろいろなブラウザを調べていたが、Firefox は日本語処理において根本から相当に練っていたらしく、最も優秀であろうと筆者は感じた。敬意を表したい。