CookieもIPアドレスもNGなケースのログイン機能実装

　ユーザーのログインを必要とするサイトでは、ログイン機能を実装する必要があります。しかし、1章で解説したように、iモードではCookieが使えません。しかも、IPアドレスで判別しようにも、IPアドレスはアクセスしてくるたびに変わるうえ、同じIPアドレスを利用して違う端末でアクセスされるので、判断情報になりません（PCサイトでも、同一アクセスか否かをIPアドレスで判断するのは投票サイトくらいですが……）。

　上で紹介したようなフレームワークを利用している場合、ログイン機能に対応していれば問題ありません。ただ、フレームワークがログイン機能に対応していなかったり、フレームワークを利用しなかったりする場合は、解決方法として、セッション情報をURLに常に持たせる方法と、機種固有IDで判別する2つの方法があります。

1. セッション情報をURLに常に持たせる場合

　これは、mixiのように、常にログインしているという情報をユーザーのケータイ端末が持ち続ける必要があるサイトで利用されている手法です。

　ログイン時にaタグのリンクで移動するとき、常にプログラムにより、このユーザーのセッションIDをURLの後ろにパラメータとして付加してあげます。

<a href="/home?session_id=de431a78b4efdaeab">ホームへ</a>

　全HTMLのaタグの後ろにユーザーのセッションIDをパラメータとして付けるので、多少手間は掛かりますが、このようにしてsession_idの情報を基に判断することで、ユーザーのログイン情報を区別できます。

　このとき、ログインのたびにセッションIDをランダムなユニークに長い文字列で割り当てる必要があるので気を付けてください。

　セッションIDが1、2、3……と増えていく形式であれば、次のセッションIDを推測してそのセッションIDを入力することでセッションハイジャック攻撃という、ログイン状態を乗っ取る攻撃を受けてしまいます。

　なお、セッションIDをランダムな値にしても、その値が、外部に分かるとセッションハイジャック攻撃を受けてしまうので、セッションIDを外部に漏れないようにする必要があります。

　例えば、session_idのパラメータを含んだURLから、別のサイトへアクセスさせると、AuやSoftbankのケータイではそのサイトのアクセスログの参照元URLにsession_idが残り、session_idが管理者に見えてしまいます。

　iモード以外でもセッションIDをパラメータに入れる場合は、別サイトに移動させるときに移動させる専用のページを一つ用意して、その移動専用ページへのリンクはsession_idを付けないように、リンクを設定する必要があります。

　SNSのようなサイトであれば、利用者がsession_idのパラメータを含んだURLを日記などに貼付けることで、そのsession_idが漏れるので、そのコンテンツを表示する際に、session_idのパラメータが無いかチェックし、存在すれば、そのパラメータを除去するような処理を設置しないと、危険です。

　また、未ログインの場合もセッションIDを付けていると、サーチエンジンがアクセスして来たときに、セッションIDが保存され、そのサーチエンジンからアクセスして来た人が全員同じセッションIDになることもあります。

　これらのセキュリティを上げる対策としては、基本的にCookieが使えるauやsoftbankは、セッションIDの手法ではなく、Cookieを利用する方法があります。

　docomoでもsession_idごとに機種情報を保存して、機種が違うと同じセッションと判断しないセッションIDに、有効期限を持たせます。そして、有効期限を過ぎたセッションは削除するなどすれば、いつの間にか別のユーザーでログインしていた、といった問題を回避できます（同じ機種のUseragentで同じsession_idを利用するとセッションハイジャック可能ですので、100％では無いですが）。

2. 機種固有IDで判別する

　コメントの投稿時のみログイン情報を判別すればいいサイトに向いている方法です。

　ログインユーザーの端末製造番号をあらかじめ会員情報として記録しておくことで、アクセス時に端末製造番号を確認してそれと一致するユーザーのログインと見なします。

　端末製造番号は、docomoの場合、aタグやformタグにutnという属性を付けることで取得できます（参考：iモード対応HTMLタグ一覧）。

<A href="URL" utn> <FROM method="メソッド" action="URL" utn>

　このとき、ユーザーに対して確認画面が出ます。ユーザーが端末製造番号を送ることに同意した場合にユーザー・エージェントに含まれるので、ライブラリ等の機能や正規表現を使って、端末製造番号を取得できます。

　なお、EZweb、SoftBankは、utnを付加することなく、ユーザー・エージェントに端末製造番号が登録されています。ただし、こちらも、ユーザーの設定により端末製造番号を送らないように設定することも可能です。その場合、ケータイの端末製造番号は取得できません。

　取れない場合は設定の関係でログイン情報を認識できないと返すプログムを実装する必要があります。

　PC端末からアクセスしてきた場合、ツール類の使用により好きなユーザー・エージェントでアクセスされることに注意してください。

　アクセス元のIPアドレスがケータイ用のIPアドレスかを判断しない場合、ユーザー・エージェントの偽装により、なりすましが行えます。

　また、最近はスマートフォンも普及して来ているため、ケータイからのIPアドレスからアクセスしてきても、ユーザー・エージェントを偽装することが可能と考えられます。

　上記2つの方法のどちらも、100％安全ではありません。重要な情報へのアクセスや、情報の変更は、変更にあわせてパスワード認証を行うなどの設計にする必要があります。

ケータイ対応Webサイト開発Tipsのまとめ

　ここまで、ケータイ電話への対応サイトの作り方として、初めて開発するときに想定するべき9つの注意点、開発前に決定すべき対応機種、共通基盤のフレームワーク、ログイン状態の維持の方法について開発者である私の経験を基に説明しました。いかがでしたでしょうか？ 以下の3点がケータイ対応サイトの基本事項のまとめとなります。

PCとケータイで違う点によるトラブルに注意 対応機種や検証方法は事前に定義 フレームワークやライブラリを使って機種判別や絵文字表示を楽に実装

　ケータイ対応のサイトも、今後iPhoneの登場やGoogleのAndroidの登場で、PCサイトのようになっていくと思われますが、まだまだケータイのために特殊な処理を行う必要があります。

参照記事： Android→Androidは雇い主の分身として仕事をするエージェント iPhone→iPhone向けWebアプリを作ろう

　本記事の注意点に留意してサイト開発に頑張ってください。

著者プロフィール 高瀬　裕一(たかせ　ゆういち) KBMJに勤務するプログラマ。主にRuby on Railsを利用したシステム開発を行っており、小江戸らぐというコミュニティでのRuby on Rails勉強会の講師や、開発方法を中心に扱うDoRubyへの投稿やzenpouの日記の運営を行っている

3/3

INDEX
ケータイ対応Webサイト開発Tips
	Page1ケータイ向けとPC向けのWebページの相違点│絵文字の有無と文字コード│Cookieが使えない│外部スタイルシートが使えない│アクセスのたびにIPアドレスが変わる│画面のサイズが機種ごとに違う│メールアドレスのチェック方法│画像の表示│動画の表示│SSLが不正な場合利用できない
	Page2開発前に対応する機種の範囲を決めておこう！│キャリアによって異なるユーザー・エージェントの仕様│ 共通基盤として、フレームワークを利用しよう
	Page3CookieもIPアドレスもNGなケースのログイン機能実装│ 1. セッション情報をURLに常に持たせる場合│2. 機種固有IDで判別する

関連記事

iPhone向けWebアプリを作ろう Safari Web Content Guide for iPhoneを読み解く iPhone／iPod touch上のWebブラウザのSafariで動くWebアプリを作成し、UIを最適化するコツを紹介します 「リッチクライアント ＆ 帳票」フ ォーラム 2008/5/29

Androidは雇い主の分身として仕事をするエージェント Google Developer Day 2008特集（1）　Androidの生みの親、アンディ・ルｰビン氏が、Androidに込めた思いと展望を語る。「Google Android入門」の著者の嶋氏が聞く 「リッチクライアント ＆ 帳票」フ ォーラム 2008/6/13

あなたのサイトはiPhoneで見られますか？ 安藤幸央のランダウン（36）　携帯電話と違い、PC用のサイトも見られる小さな画面の端末が普及してきている。そんな時代のWebページはどうあるべきかを解説しよう 「Java Solution」フォーラム 2007/9/14

Smart＆Social フォーラム トップページへ