Webセキュリティの小部屋

Twitter のフォローはこちらから Facebook ページはこちら Google+ページはこちら RSSフィードのご登録はこちらから
公開日:2013年3月14日
最終更新日:2013年3月15日

クロスサイト・スクリプティング(XSS)の具体例

クロスサイト・スクリプティング(以下、XSS)の脆弱性があるとスクリプトを注入されて、Cookie 等の情報が漏えいすると言われてもイメージがしにくいと思います。

ここでは、XSS が具体的にどのように攻撃されるのかを見ていきます。

以下のような画面遷移(入力→確認→結果)の簡単な Webアプリケーションを作成します。

pic01

コードは以下のようになります。

・xss.php

・xss_confirm.php

・xss_regist.php

通常のパラメーターを入力すれば、画面遷移図のように問題なく画面遷移しますが、名前欄に以下のように入力すると、Cookie の情報がダイアログで表示されてしまいます。

pic02

この罠リンクは以下のようになります。この罠リンクをクリックする人は少ないでしょうが、URL を圧縮されたら罠リンクだと気づくことは難しくなります。なお、ブラウザによっては、XSS の危険があるとしてブロックされます。

これが Webアプリケーションにスクリプトを注入して、XSS の攻撃が成功した状態です。

ですが、これだけだと Cookie の値を表示しているだけで何も攻撃者に情報は渡っていません。

今度は、名前欄に以下のように入力して実行してみましょう。

リダイレクト先のアドレスは存在しないものなので以下のようなエラー画面が表示されます。実際の XSS 攻撃では、攻撃サイトのページが表示されます。

pic03

アドレス欄をよく見ると、以下のようにセッション ID がアドレスに含まれてしまっていることが分かります。この時点で攻撃者にセッション ID が盗まれてしまいます。

罠リンクは以下のようになります。

攻撃者はセッション ID を入手したら自動でメールを送信しておくようにプログラムを用意しておけば、メールが届いたタイミングでセッション ID を利用して Webアプリケーションにアクセスし、なりすましが完成します。

このような形で XSS は Cookie の情報が漏えいします。XSS は JavaScript を自由に実行できるので、画面の書き換えをすることも可能です。ログイン画面で画面を書き換えれば、ユーザー ID とパスワードの入手すら可能です。

XSS のイメージはできたでしょうか?

XSS は対策の漏れにより作りこまれやすい脆弱性ですが、脅威は大きいです。ですので、XSS の対策はしっかりと行いましょう。


スポンサーリンク




カテゴリー:Webアプリケーションセキュリティ

Twitter でも、いろんな情報を発信しています。



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA