EC-CUBEは株式会社ロックオンが提供しているオープンソースのショッピングサイト構築ツールです。2018年11月28日にEC-CUBE のバージョン3.0.0から3.0.16にオープンリダイレクトの脆弱性が存在することが明らかになりました。

【参考】EC-CUBE におけるオープンリダイレクトの脆弱性

https://jvn.jp/jp/JVN25359688/index.html

脆弱性のあるページにアクセスすると任意のウェブサイトへとリダイレクトされ、フィッシングなどの被害にあう可能性があります。EC-CUBEの公式サイトより脆弱性の解決に必要なバージョンアップ手順が公開されています。

【参考】EC-CUBE 3.0系のオープンリダイレクト脆弱性について

https://www.ec-cube.net/info/weakness/20181113/

EC-CUBE 3.0.3以前のバージョンにはオープンリダイレクトの脆弱性の他にも複数の脆弱性が存在します。3.0.3以前のEC-CUBEを利用している場合は、いったんEC-CUBE 3.0.4以上にバージョンアップした状態で、今回の脆弱性の修正を行う必要があります。

オープンリダイレクトの発生のメカニズム

オープンリダイレクトの脆弱性の発生のメカニズムは非常にシンプルです。例えば、WebアプリケーションにおいてURLのパラメータとして別ページにリダイレクトする処理を考えます。

そのWebアプリケーションは「http://example.com」で運営されているとして、「http://example.com/goto?url=＜url＞」のように「＜url＞」にリダイレクトさせるページがあったとします。

本来、Webアプリケーションは「example.com」のドメイン上にて運営されていますが、リダイレクト先のURLに悪意のあるドメインのページ（例えば「http://evil.example.com/」など）を指定させることで、そのページへと遷移されてしまうことがあります。これがオープンリダイレクトの脆弱性です。

脆弱性を悪用されるケースとしてはWebアプリケーションのログインページが標的となるケースが考えられます。

ログインページは正規のWebアプリケーションのサイトでも、「ログインボタン」クリック後のリダイレクト先に不正なログインページが指定されているとどうでしょうか。

その不正なログインページは正規のログインページとそっくりに作られており、さらにページ内のメッセージに「ログインに失敗しました」などと記載されていれば、訪問者は「あぁちょっとパスワードの入力をミスったかな」と思い、不正なログインページ上で再びIDとパスワードを入力してしまうかもしれません。そのページに入力されたIDとパスワードを搾取されてしまうのが、オープンリダイレクトの脆弱性を悪用した一例です。

オープンリダイレクトへの対策はいくつかありますが、堅牢な防御方法の一つに、与えられたパラメータをそのままURLとして使うのではなく、ただのフラグとしてのみ使用する方法があげられます。

例えばURLとして「http://example.com/goto?url=foo」というURLを与えられた場合、Webアプリケーションは「foo」という文字列をそのままURLとして使うのではなく、プログラム中で処理させるフラグとして使うようにします。

プログラムでは「$_GET[‘url’]」の値を調べて「foo」だったら「http://example.com/page1.html」にリダイレクトさせる、「bar」だったら「http://example.com/page2.html」にリダイレクトさせるなどの方法を採用すれば、パラメータとして悪意のあるページが指定されても、悪用されることはありません。

Webアプリケーションの実運用上ではどうしてもパラメータをURLの一部として使わざるを得ないケースもあるでしょう。その時は指定されたパラメータを精査し安全性が確認された時のみリダイレクトさせるなどの工夫が必要です。