【ネットセキュリティ】eoショッピングモールは大丈夫?/『セッションハイジャック』って何者?
【お知らせ】8/9 11:17追記
10時頃、eoショッピングモールの運営局よりお問い合わせフォームの方の返信があり、HTTPへのアクセスは、HTTPSにリダイレクトするように仕様変更を行ったそうです。
ご対応いただきありがとうございました。
今後、ユーザー様が何らかの対応を行って頂く必要はありません。
--------------------
※これに気がついたとき、ヒヤッとして、すぐにアイデアファームの方に投稿しました。
また、eoショッピングモールのお問い合わせや、スタッフブログへのコメントも行っています。
【至急】eoショッピングモールの常時SSL化(セッションハイジャック対策)
https://king.mineo.jp/my/Tsukikoh/ideas/23012
こちらに記載しましたが、これの何が危険なのかを簡単に説明します。
とあるサイト(今回の場合は、eoショッピングモール)で、アカウントにログインすると、「セッションID」という、いわば「入場券」のようなものが発効されます。
この入場券は、有効期間内であれば、いちいちログインしなくても持ち主をアカウントの本人だと判断して、適切なページを表示しています。
(これのおかげで、頻繁にログインをしなくて良くなります。)
この入場券は、他人にバレてしまうと、持ち主のなりすましをして、買い物をしたり、住所などの登録情報や、注文履歴などを見られてしまいます。
これを、「セッションID」という「入場券」を乗っ取るということで「セッションハイジャック」と呼びます。
これをバレないようにするには、そうです。
私の記事にたまに登場する「暗号化」というものです。
仕組みはともかくとして、「暗号化」されていれば、赤の他人に「入場券」をコピーされる可能性はかなり低くなります。
しかし、今回「eoショッピングモール」では、暗号化していなくても「入場券」が使える状況ができあがってしまいました。
「セッションハイジャック」のお話は、セキュリティ技術者であれば、常識だと思っていたんですが、しっかりと対策がされていなかったのは残念です。
【参考】セッションハイジャックとは - IT用語辞典
https://tki.jp/izkp
----------
これは、過去のものです。現在は運営による対応が完了しています。
下記の作業は不要ですのでご安心ください。
----------
【ユーザーの皆さんができる対策】
eoショッピングモールにアクセスするときは、URLが「https:// 」から始まっているかをご確認ください。
もし、「http:// 」から始まっているURLにアクセスしていたら、すぐにその部分を「https:// 」に書き換えてください。
刑法第233条(信用毀損及び業務妨害)
虚偽の風説を流布し、又は偽計を用いて、人の信用を毀損し、又はその業務を妨害した者は、3年以下の懲役又は50万円以下の罰金に処する。
刑法第234条(威力業務妨害)
威力を用いて人の業務を妨害した者も、前条の例による。
また、威力業務妨害は、過去の判例だと、物理的な妨害の他に、殺害予告や爆破予告または、嘘を流して妨害するなどがあげられます。
しかし、事実を公表した場合で、脅迫ではない場合、たとえ第三者が不安に感じてそれにより業務が妨害されたと主張したとしても、これが「威力業務妨害」に当てはまる可能性はほぼないと思います。
似たような物として、「名誉毀損」があげられます。
こちらについては、下記のサイトを引用させて頂きました。
https://woman.mynavi.jp/article/140618-25/
「不特定または多数人が認識できる状況下で、人の社会的評価を低下させるに足りる具体的事実を告げて、人の社会的評価を低下させる危険を生じさせること」
これには当てはまる可能性はあると思われますが、具体的な被害が確認できない場合において、刑事で有罪になる可能性はほぼないと思います。
そのため、民事裁判での訴訟になるかと思います。
民事裁判においては、該当する投稿は運営者がすぐに非表示または削除しなかったことは、賠償金額を下げる要因になると思いますが、ゼロにはならないでしょう。
犯罪である可能性は極めて低いですが、民事裁判で訴えてきたら企業としてどうなんだというところも問われるでしょうね。
常識的に考えればあり得ないだろうという個人的な判断で書いていますので、ご了承ください。
運営事務局が見せてはいけないと判断されるのであれば、どうぞ非表示なり削除なりして下さいというスタンスです。
しかし、その後に利用者に実害が出ても知りませんよ。ということです。
マイネ王の規約でこんな項目があります。
解釈によりますが、「不具合を第三者に伝える」が禁止ともとれますし、以前不具合のことで掲示板に書いたものが事務局によって非表示(or削除)になりました。
今回の話が実際に不具合なのか・悪用できるのかは私は知らないですが、セキュリティ上のリスクになるなら運営に報告するorしかるべき機関に報告するのかまず最初で、その後の対策を待つべきだと思っています。
対策される前に公表すれば、それを悪用することも可能になります。
セッションハイジャックというものは、ユーザーと、ショップの通信の間に入らなければ成立しません。
名前を借りますが、『今すぐにPhantomさんのeoショッピングモールを乗っ取ってやろう!』としてできるものじゃありません。
また、セッションハイジャックを実際に行うような人は公表ありなし関係なく、通信情報を常に盗み見て、隙があれば乗っ取ってやろうみたいな考えの人が多いです。(というかそういう不正なプログラムが働いていることが多いです)
そのため、公表したからと言って、ゼロデイ攻撃ができるものじゃないと考えています。
それよりも、ユーザーさんに最悪の事態から自らの身を守る対応策を伝える方が優先だと判断し、公表させていただいています。
今回の場合、ユーザー側は「http」から「https」に書き換えるだけで対応が完了しますから。
あまり詳細に調査できていないのですが、例えば商品紹介ページのみhttpで表示して、パスワード変更や決済画面に進む際にはhttpsにしてもう一度パスワード認証させる形式になっていれば問題ないです。
この場合、セッションIDが漏れてもカートの中身が見られるとか、知らない商品が追加される程度の被害です。
まあhttpsにしてサーバーの負荷を気にする時代ではないので全面httpsにしたらいいとは思いますけど。
パスワード変更や、決済画面は確かにHTTPS必須でした。
HTTPとHTTPSのセッションIDがそれぞれのアクセス時に別に割り振られていればそれでも大丈夫ということになるんでしょうけど、
Cookieを解析したところ、HTTPでアクセスしたときに生成されたセッションIDが、ログイン後もそのまま有効になっているようでした。
HTTPでの通信で受け渡されたものの中には、使用時はHTTPS専用のものがありました。
ということは、中間攻撃者が生成時のセッションIDの送信さえ受信してしまえば、ログイン後のマイページ等、HTTPSを必須とするページにもそのままアクセス出来てしまうのでは無いかと判断しました。
こちらの「JSESSIONID」は、「eoショッピングモール」に初めてアクセスしたときに与えられましたが、ログイン後、「JSESSIONID」をCookieから削除すると、強制的にログアウトされました。
初めて与えられた「JSESSIONID」は、削除するまで中身に変更はありませんでした。
もう一つ「CLOUDNLBA」も同様でした。
この2つは、HTTPでの通信で得たものです。
> したときに与えられましたが、ログイン後、「JSESSIONID」をCookieから
> 削除すると、強制的にログアウトされました。
> 初めて与えられた「JSESSIONID」は、削除するまで中身に変更は
> ありませんでした。
そりゃ当然です。そのための Cookie Persistent(Cookieによるセッション維持)ですから。ロードバランサやらが入っている環境や、複数の Webサーバーが存在する環境では当たり前のごとく使用されるテクニックです。
逆に Cookieに変な情報を突っ込まれればいくらでもハイジャックできますが、 Cookie IDはブラウザ側で生成するものではなくて情報を返すサーバー側から発行されるものなので、通常はハイジャックされるものではありません。
1.ブラウザ→Webサーバー等への通信開始(Cookie IDは空)
2.セッション確立時に Webサーバー側から Cookie IDとしてセッション情報を提供→セッションの特定が可能。
3.以降 Cookie削除までセッションが確定。
4.Cookie Expire、またはセッション終了時に Cookie削除を行いセッション削除。
いずれにせよ、スレッドタイトルが「xxは危険!?」と書くのはある意味どこかのスポーツ新聞のように見えますので「xxは大丈夫?」くらいで収めておいたほうが良いのかもしれませんね。
ユーザーと、サーバーの間にある中継サーバーが、始めにサーバーからユーザーに送信されるセッションIDを中継サーバーがそのまま不正に保持してしまい、
その後ユーザーが同じセッションIDを使ったままログインしたときに、不正にセッションIDを保持した中継サーバーがそのままマイページとかの、本来ログインが必要なページへとアクセスできてしまうのではないかと言うことです。
実際にそんなことはやったことはないので、もしかしたら言ってることが間違ってるかも知れません。
また、ばななめろんさんのご指摘のとおり「〜は大丈夫?」に変更させていただいています。ありがとうございました。
> ユーザーと、サーバーの間にある中継サーバーが、始めにサーバーから
> ユーザーに送信されるセッションIDを中継サーバーがそのまま不正に
> 保持してしまい
(以下略)
これがあるとすれば、プロキシキャッシュサーバー(Squidなど)、またはリバースプロキシサーバーで特定の Cookieを保持するといった特殊条件でないと成立しなくなります。
ちなみにキャッシュサーバーの主な役割はコンテンツキャッシュ、リバースプロキシの場合は主に代理応答や SSLカプセリング/解除で活躍しますので、通常はどちらも Cookieを保存はしていません。(セッションが切れると自動的に削除します。そうしないとデータが溢れてしまうので。)
基本的にセッション IDを保管している Cookieはブラウザ側で有効期限を管理していますし、正しい Cookieと異なるサーバーに転送されるようハイジャックされているのであれば『そのハイジャックされている状態を放置していることが問題』であって、今回の技術要素とは違う時限でのお話になります。(システム設計上の脆弱性であって、今回指摘されていることとは方向性も異なります)
httpsでアクセスするように、利用者への注意喚起にもなったと思いますので、公表した事は良かったと、私は思います。
認証後、httpに戻っても認証済が維持されてしまうなんて…なんちゅう(以下略)
と思ってしまいましたが、直って良かったです。
それよりも、Phantomさんの書いている
「以前不具合のことで掲示板に書いたものが事務局によって非表示(or削除)になりました。」
の方が気になって仕方ない…
そんなにバレると問題のある緊急性のある不具合だったんだろうか。