EC-CubeのXSSとセッション固定の脆弱性について   12 comments

Posted at 2:31 pm in Security,XSS

こんにちは。暑いですね。相変わらずゴロゴロしておりますが、ゴロゴロしててもお腹も空くし、お金も減っていくんですよ。不思議ですね。

暑くてぐったりですね

暑くてぐったりですね

 

さて、昨日のことですが、EC-Cubeがアップデートされ、5つの脆弱性に関する修正がありました。

その中で「カート画面でのXSS脆弱性、及びセッション固定の脆弱性」という脆弱性について、報告者の立場から追加となる情報をいくつか書いておこうと思います。報告したのは今年の1月ですから4ヶ月でかけての修正となります。

なお、他の「パスワードリマインド機能における不適切な入力確認の脆弱性」、「一部環境における、管理画面の不適切な認証に関する脆弱性」、「お届け先複数指定画面でのXSS脆弱性」という脆弱性についての情報はありませんのであしからずご了承ください。つか誰か詳細を教えてください。

で、「カート画面でのXSS脆弱性、及びセッション固定の脆弱性」となってますが、これは独立した問題です。
正確には、「EC-CUBEにおけるカート画面でのXSS脆弱性」、と「EC-CUBEにおけるセッション固定の脆弱性」ですね。

JVNではこんなかんじです。

EC-CUBE におけるクロスサイトスクリプティングの脆弱性
http://jvn.jp/jp/JVN52552792/index.html

EC-CUBE におけるセッション固定の脆弱性
http://jvn.jp/jp/JVN00985872/index.html

それでは個々の説明に入ります。
 

・カート画面のXSSについて

まず、XSSですが、カートの個数指定のところで数字以外の値も受け取ってそのまま表示してしまうことが問題で、XSSが発生します。2.11.xのモバイルサイトだと個数を数値入力で設定するので、”><script>alert(0)</script>みたいなのを入力すればわかりやすいかと思います。2.12系になって、+-で増減させるようになったのですが、関数自体はそのまま使えたので、どうようのXSSが残ってしまっています。

とはいえ実行させるのにユーザーによる入力が必要となるので、これだけでは脆弱性じゃない気もします。
が、いろいろ触っていると細工したURLにアクセスさせるとXSSを発動させることが可能となりました。なんでGETリクエスト認めてるんですかね。

でも、この脆弱性ですが、発動させるのにはカートに商品が入っている必要があります。
なので、それほど危険はないんじゃないかなと思っていましたが、いろいろ見ていくと、URLに細工することによって、アクセスすると強制的にカゴに商品を入れることが可能となりあした。

なので、
強制カゴ投入のURL→XSSのURLにアクセスさせることで、XSS発動というコンボになります。

ec-cube-01

こんなかんじ

なお、サーバーや環境によっては予防的にGETによるパラメータを取得していないサイトがありますが、EC-CubeってPOSTのリクエストをゴニョゴニョするとすぐに遷移エラーみたいなのが発生するので(自分の環境だけかもしれませんが)それらのサイトはこのXSSに関してだけは安全度が高いんじゃないかなあと思ってます。

 

・セッション固定の脆弱性

そして、もう1つは単純なセッション固定の脆弱性です。
なんでまた、と思う人もたくさんいるかもしれませんが、あるんだから仕方ありません。

EC-CubeはセッションをCookieに持たせたセッションIDで管理しているのですが(ID名はバージョンによって異なります)、別のアプリケーションなどによって、同じ名前のセッションが設定されていた場合、それが更新されません。

例えば同じドメインにある別のアプリがセッションIDを
phpsessid=1
と設定していたとします。

EC-CubeのセッションIDとして同じphpsessidが使用されていた場合はそのまま
phpsessid=1
が使い回されます。

で、ユーザーがログインしてもセッションIDは変更されることなく
phpsessid=1
のまま使われていきます。
困ったものですね。

ここで、悪意のあるユーザーが先ほどの別のアプリのように、EC-Cubeより先にセッションIDを設定できたらどうなるでしょう。ユーザーは攻撃者指定したの任意のセッションIDでEC-Cubeを使うことになりますね。

そんなことができるのか?ということですが、先ほどのXSSを使うことで任意のセッションIDを書き込み可能ですね。
また、都道府県型JPドメインのようなドメインを使っていた場合クッキーモンスター脆弱性があるとセッションIDを外部から書き込まれますね。

最終的に、誰かになりすまされて乗っ取られるわけでございます。

そして、この脆弱性のさしあたっての危険度ですが、URLによるセッションIDの指定はできませんので、潜在的な危険度は高いけど、XSSを突かれなかったらそんなに心配しなくてもいいかなあというかんじです。都道府県型JPドメインを使って運用している場合は緊急度は上がる気がします。

 

とざっくりとした説明でした。EC-Cubeをお使いの皆様は、他の脆弱性もありますので、早めのアップデートをオススメいたします。見てみると前回修正時の2012年2月の脆弱性が残ってるサイトもたくさんありますね(;´Д`)

日本には思ったよりもたくさんのEC-Cubeを使ったWebサイトがあります。EC-CubeによるECサイトを構築の方、もし不明な点があればお問い合わせください。具体的な手法などわかる範囲でお答えいたします。

Written by bogus on 5月 24th, 2013