脆弱性コラム - 第5回

サイト脆弱性をチェックしよう! -- 第5回:XSSの脆弱性を検査する方法

前回までは安全なウェブアプリケーションを作成する手法をいくつか説明してきた。今回からは代表的な脆弱性についての検査方法を説明していきたい。まずは、クロスサイトスクリプティング(XSS)の脆弱性について、その検査方法を紹介する。

XSSとは、入力として受け取ったデータに含まれている「Javascript」などのスクリプトやタグが、それらが有効な形で出力(HTTPレスポンス)に含まれているために、ブラウザが意図しない動作や表示を行ってしまう脆弱性だ。

この脆弱性を使った攻撃の被害者はサイトを利用している利用者であり、サイトが直接的な被害に遭うことはない。この脆弱性を利用すると、攻撃者が意図した通りにブラウザをコントロールすること(たとえば、意図しないデータの送信や表示内容の変更)が可能になる。

これにより、利用者のログイン情報を他のサーバに送信したり、利用者のブラウザからサイトにある脆弱性を調査し、その結果を他のサーバに送信することも可能になる(図1)。また最近では、XSSの脆弱性を利用したワームもMcAfeeのウェブサイトなどで報告されている。

図1:XSSを利用した攻撃例

図1:XSSを利用した攻撃例

XSSの脆弱性を攻撃に用いるにはサイトの利用者に、悪意あるスクリプトを含んだリンクをクリックさせる必要がある。そのために攻撃者は、巧妙に仕組んだSpamメールや掲示板、自分が立ち上げたサイトなどのリンクを利用する。

これらのリンクは対象となるサイトが送信したメールに偽装されていたり、一見すると信頼できそうなサイトにそれらしい言葉でリンクが貼られていたりする。このようにして攻撃者は誰かが罠にかかるのをじっと待っているので注意が必要だ。

XSSの検査方法

XSSは比較的見つけやすい脆弱性といえる。これは、HTTPレスポンスに埋め込まれたJavascriptやタグにより、ブラウザ側に誤動作を行わせる脆弱性であるため、HTTPレスポンスを解析することで脆弱性の有無を判断できるためだ。従って、検査する際には以下のような方法で、脆弱性の有無を判断する。

  1. 入力データ(パラメータ値やCookie)にタグやJavascriptを示すデータを入力して、アプリケーションを呼び出す(HTTPリクエストを送信する)。
  2. HTTPレスポンスに入力データに使用したタグやJavascriptが有効な形で含まれているかを確認する。有効な形で存在している場合、XSSの脆弱性があると判断できる。
実際の検査に使用するデータには、以下のようなものがある。

実際の検査に使用するデータ例


XSSの脆弱性があるアプリケーションの場合、これらのデータをブラウザから入力してアプリケーションを呼び出すと「Test」と書かれたポップアップウィンドウが表示される(図2)。

図2:XSSの脆弱性があるアプリケーションを呼び出すと「Test」と書かれたポップアップウィンドウが表示される

図2:XSSの脆弱性があるアプリケーションを呼び出すと「Test」と書かれたポップアップウィンドウが表示される

たとえば、XSSの脆弱性のあるアプリケーションがダブルクォートを利用したケースを入力データに入れると、以下のようになる。

XSSの脆弱性のあるアプリケーションがダブルクォートを利用したケースを入力データ例

 この結果、INPUTタグが意図せず閉じられ、SCRIPTタグが有効になり、alert("Test")がスクリプトとして実行されてしまう。

このようにして、脆弱性の有無を確認できるが、ブラウザを使用するとラジオボタンや、Hiddenフィールド、またはJavascriptで入力データの確認を行っている場合には、これらの値を入力することが困難となる。


しかし、Hiddenフィールドやセレクトボックス、ラジオボタンなどのパラメータは開発者が変更できないと思い込んでいることが多いため、Textなどでは発見されない脆弱性が見つかることが多々ある。

そこで、検査の際にはHTTPリクエストを変更できるプロキシを使用する。そのようなツールのひとつに、AppScanに付属するHTTP Proxyがある。このツールは、旧 Watchfire(現 IBM)のウェブサイトからダウンロードできる。

こうしたツールには、他にもオープンソースの「Paros」や「WebScarab」などもある。

今回は、AppScan付属のHTTP Proxyを使った検査方法を紹介する。このツールはAppScanに付属するものだが、自由に使用できる。
HTTP Proxyの使い方は、以下のとおり。

  1. ブラウザのプロキシ設定で、プロキシサーバを「localhost」に、ポート番号を「8080(デフォルト値)」に設定する。HTTP Proxyの待ちうけポート番号は、HTTP Proxyのメニュー「Edit」「Preferences」で変更できる。
  2. HTTP Proxyが転送するHTTPリクエスト/HTTPレスポンスの処理方法を「Manual」に設定する。これにより、受け取ったHTTPリクエストをHTTP Proxyで受けて、その内容を変更してからサーバに送信することが可能となる(図3)。

図3:HTTP Proxyが転送するHTTPリクエスト/HTTPレスポンスの処理方法を「Manual」に設定する

図3:HTTP Proxyが転送するHTTPリクエスト/HTTPレスポンスの処理方法を「Manual」に設定する

3. 受け取ったHTTPリクエスト/HTTPレスポンスを変更し、ボタンをクリックして、HTTPリクエスト/HTTPレスポンスを送信する。このときパラメータ値などに前述のデータを入力する(図4)。

図4: 3)受け取ったHTTPリクエスト/HTTPレスポンスを変更し送信する

図4: 3)受け取ったHTTPリクエスト/HTTPレスポンスを変更し送信する

実際に手動によるセキュリティ検査では、このようなツールを使用するのが有効になる。

XSSの対策

XSSの対策は、一言でいうと、入力データをHTTPレスポンスとして返すときに、適切にエスケープ処理することだ。エスケープ処理とは、特別な意味を持つデータを一定のルールに従って、データの内容を変えないように変換することだ(危険なデータを削除することではない)。

XSS対策の基本は、HTMLで特別な意味を持つデータである「<」「>」「"」「'」「&」をそれぞれ、「<」「>」「"」「'」「&」に変換すること。正しく変換を行っているアプリケーションで先の例のように入力データが利用されている場合、ダブルクォートを利用したケースのデータを入力されると、以下のようなHTTPレスポンスが得られる。

ダブルクォートを利用したケースのデータを入力例

この結果、INPUTタグが意図せず閉じられないため、alert("Test")が実行されることはない。

しかし、残念ながらこの対策だけでは、すべてのXSSの脆弱性に対応することはできない。入力データを出力する場所に応じて、異なる対応が必要であることがXSSの脆弱性対策の難しいところだ。

たとえば、Aタグのリンクに入力データを使用したい場合、URLを絶対パスで記述するといった対策などが必要となる。また、スクリプトのコード内に入力データを使用している場合は、対策が非常に困難になる。従って、このような作りになるべくならないように設計する必要がある。

特殊なケース

このようなアプリケーションのHTTPレスポンスによるXSS以外にも、IEなどブラウザの仕様に依存して、XSSが発生するケースがある。たとえば、IEのデフォルト設定では拡張子ではなく、ファイルの内容によってファイルタイプを決定する。

HTTPレスポンスのContent-Typeがimage/bmpであり、かつ拡張子がbmpであっても、ファイルの内容がHTMLであれば、HTMLと判断し、スクリプトが実行される。

本来であれば、このような脆弱性は、ブラウザの開発元が修正すべきだが、ブラウザの仕様として開発元が認識していると修正されないことがある。このためアプリケーション側で対策を行ったほうがより安全なアプリケーションを作成することができる。

先の例であれば、ファイルのアップロードが可能なアプリケーションでは、ファイルの内容にHTMLタグが含まれていないことなどアップロードしても安全なファイルであることを確認する必要がある。

このように、ブラウザの仕様や脆弱性に依存して脆弱性が発生するケースがあるのでブラウザの脆弱性についても常に確認し、対策を行うことが必要になる。

今回は、XSSの脆弱性について検査手法を具体的に説明した。次回以降も脆弱性の具体的な検査手法について説明していきたいと思う。

AppScanに
関するお問い合わせ

  • テクマトリックス株式会社
    東京本社

    ネットワークセキュリティ事業部
    第3営業部
    セキュリティプロダクツ営業2課

    03-4405-7814

メールでのお問い合わせ
watchfire@techmatrix.co.jp

お問い合わせ

製品についてやテクマトリックスについてなど、
こちらよりお気軽にお問い合わせいただけます。