実は厄介、ケータイWebのセッション管理：再考・ケータイWebのセキュリティ（3）（2/3 ページ）
“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部）
クッションページを使った対策法
この問題に対処するため、A社は、セキュリティ専門家からの報告書に掲載されていた「クッションページ」を使う方法を採用することにしました。
クッションページとは、外部サイトにリンクする際に直接リンクするのではなく、「中間のページ」を挟む方法のことです。図2にクッションページを用いた画面遷移例を示します。真ん中のページがクッションページであり、このページのURLにはセッションIDが付かないようにします。
この遷移の場合、外部サイトに送信されるRefererはクッションページのURLを指すことになります。クッションページにはセッションIDが付かないので、外部サイトにはRefererヘッダを介しても情報が漏れなくなります。
php.iniにsession.use_trans_sid = 1を指定してセッションIDを自動的に付与している場合には、クッションページのURLにもセッションIDが付与されます。これを防ぐ方法はいくつかありますが、簡単に実現するには、クッションページを絶対URLで指定する方法があります。絶対URLで指定されたURLに対しては、PHPはセッションIDを付けないからです（下記のhref属性の指定）。
<a href="http://example.jp/redirect?url=http://trap.example.com/">〜</a>
クッションページの導入は、RefererからのセッションID漏えい防止以外にも効果があります。それは、利用者に「外部のサイトに遷移する」という事実を明確に示せることです。
携帯電話のブラウザではアドレスバーが表示されません。このため、利用者が外部サイトに遷移したかどうかを確認しにくい場合があります。
この特性を悪用すると、実際には外部サイトに遷移しているのに、画面デザインを元のサイトに似せることでフィッシングに悪用できる可能性があります。フィッシングとは、正規サイトそっくりの画面を別サイトで用意することにより、利用者にユーザーIDやパスワード、その他の個人情報などを入力させる詐欺手口のことです。
これに対しクッションページを用いると、「これから先は外部のサイトである」ことを利用者に明確に伝え、フィッシング被害に遭う可能性を減らすことができます。
「別人のプロフィール情報が表示されるけど、大丈夫？」
A社は外部リンクをクッションページ経由にすることにより、Referer経由でのセッションID漏えいに対策しました。これで一件落着、グダクダSNSは、しばらく特に問題なく運用されていました……が、今度は利用者から、「プロフィール画面に別人の情報が表示される」という問い合わせが時々くるようになりました。
別人の情報が表示される手順を詳しく問い合わせたところ、いずれも検索サイト経由でSNSを閲覧していることが分かりました。セキュリティ専門家にも入ってもらって解析したところ、以下のシナリオで情報が漏えいしていることが分かりました。
検索サイトを起点としたセッションIDの固定化
別人の情報が表示された利用者へのヒアリングの結果、この利用者たちは検索サイト経由で「グダグダSNS」にアクセスしていることが分かりました。何らかの原因により「グダグダSNS」のセッションID付きURLが検索サイトに登録され、それにアクセスした複数の利用者が同じセッションIDの状態で「グダグダSNS」にアクセスしていたのです。
セッションIDは利用者ごとにユニークであることを前提としています。当然、同一のセッションIDを複数のユーザーが利用すると不具合が発生します。具体的なシナリオは以下のとおりです。
図3のように、「グダグダSNS」のURLがセッションID付きで検索サイトに登録されています。利用者XさんがこのリンクをたどってSNSに個人情報を登録する【1】と、セッションに個人情報が保存されます【2】。
次に、利用者Yさんが検索サイトのリンクをたどってSNSを閲覧し、そこから個人情報表示の画面を閲覧します【3】。XさんとYさんは同じセッションIDを共有しているので、セッション上の個人情報が表示された場合、YさんはXさんの個人情報を閲覧することになります【4】。
この種の問題は「セッションIDの固定化」（Session Fixation）と呼ばれる脆弱性です。現実に、この脆弱性が原因となって発生した個人情報漏えい事故が発生しています。
セッションIDの固定化は、CookieにセッションIDを保存する場合にもブラウザの脆弱性により発生する場合があります。しかし、セッションIDをURLに埋め込んだ場合は、ブラウザに脆弱性がなくても、簡単に発生してしまうことがより問題です。
【関連記事】
安全なセッション管理を実現するために
http://www.atmarkit.co.jp/fsecurity/rensai/struts04/struts01.html
Copyright © ITmedia, Inc. All Rights Reserved.