セッションIDの固定化に対処する方法としては、ログイン時にセッションIDを変更することが有効です。PHPの場合は、以下のようにしてセッションIDを変更することができます。
session_start(); session_regenerate_id(TRUE);
しかし、この方法では、ログインしていない状態でのセッションIDの固定化問題には対処できません。ログイン前のセッションIDの固定化に対処することは難しいのが現状です。以下にいくつかの方法を紹介します。
ログイン前にはセッション管理機構を使わずに、hiddenパラメータによりデータを引き回しする方法があります。ログイン前のセッションIDの固定化に対処する方法としては唯一の確実な方法です。
セッションIDをCookieに保持すると、ブラウザなどに脆弱性がない限り、セッションIDの固定化は発生しません。このため、Cookieが利用できる端末ではCookieにセッションIDを保持することにより、セッションIDの固定化を起こりにくくすることができます。
Cookieが使える端末ではCookieにセッションIDを保持し、Cookieが使えない場合のみセッションIDをURLに保持するためには、PHPの場合、以下の設定が有効です。
session.use_cookies = 1 session.use_only_cookies = 0 session.use_trans_sid = 1
将来、Cookie未対応の端末が少なくなったタイミングで、セッションIDをCookieのみに保持するようにするとよいでしょう。その場合は、php.iniの設定を以下のように変更するだけで対応できます。
session.use_cookies = 1 session.use_only_cookies = 1 session.use_trans_sid = 0
「検索サイトを起点としたセッションIDの固定化」で紹介したように、検索サイトを起点としてセッションIDの固定化が発生する可能性があります。
検索サイトでは、クローラと呼ばれるプログラムがサイトを巡回してサイトの情報を収集しています。そこで、クローラからのアクセスに対しては、セッションIDを出さないことにより、セッションID付きのURLが検索サイトに登録される事態をある程度防ぐことができます。
しかし、他のサイトからセッションID付きでリンクされている場合には、セッションID付きのURLが検索エンジンに登録される場合があるので、確実な方法とはいえません。
URLにセッションIDを埋め込むことによって起こる、RefererからのセッションID漏えいとセッションIDの固定化という2つの問題を紹介しました。
セッション管理はWebアプリケーションの基本ですが、一部の携帯電話向けブラウザがCookieをサポートしていないために、安全なWebアプリケーションの開発が難しくなってしまうのは残念なことです。
2年ほど前までは、携帯電話向けWebサイトのほとんどがCookieを使わずにサイト開発していたようです。しかし最近では、携帯電話向けWebアプリケーションでもCookieを利用するサイトが増えてきました。また、前回紹介したように、NTTドコモの携帯電話が2009年夏モデル以降でCookieに対応するなど、対応端末も増えてきています。まだ完全にCookieを必須とすることは難しいかもしれませんが、今のうちにCookie完全移行に向けた準備をしておくとよいでしょう。
京セラコミュニケーションシステム株式会社
プラットフォーム事業本部 技術顧問
HASHコンサルティング株式会社
代表取締役
徳丸 浩(とくまる ひろし)
1985年京セラ株式会社入社、1995年京セラコミュニケーションシステム株式会社(KCCS)転籍、2008年HASHコンサルティング株式会社設立。現在、京セラコミュニケーションシステム株式会社 プラットフォーム事業本部 技術顧問を兼務。システム開発の経験を経て、2004年からWebセキュリティのサービスを開始。特にケータイWebサイトのセキュリティについては早くから着眼し、多くの講演、寄稿を手がける。
HASHコンサルティングを立ち上げてからは、企業のWebサイト開発のコンサルティングなどにも幅広く携わる。
最近、特に注目されているWAFについては、多くの実証実験を手がけ、自身のブログでもWAFについての見解を述べている。
▼徳丸浩の日記
http://www.tokumaru.org/d/
▼KCCSセキュリティサイト
http://www.kccs.co.jp/security/index.html
Copyright © ITmedia, Inc. All Rights Reserved.