ケータイの簡単ログインについて

| コメント(1) | トラックバック(0) このエントリーを含むはてなブックマーク
 簡単ログインについて触れられているエントリーがありましたので、私なりの意見も。

高木浩光@自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
http://takagi-hiromitsu.jp/diary/20080727.html

契約者固有IDだけで認証するのは危ないというのは同感で、ケータイサイト作っている人なら実機よりも高速でデバッグしやすいエミュレータでガンガン作っていると思います。(それだけお手軽という意味)

この契約者固有IDは実機と特定する情報として公式サイトでは課金情報に利用されますが、ケータイサイト側ではユニークIDとして会員情報のキーとして使っているのは事実です。しかもケータイでログインIDとパスワード入力は極めて面倒な作業なので契約者固有IDだけで認証しているサイトが殆どです。

ただケータイサイト側に送られてくる契約者固有IDはHTTPヘッダです。これは簡単に偽装可能だから契約者固有IDだけで個人情報を提供するには大きなリスクがあります。

例えばdocomoの場合、公式サイトではuidを使いますがケータイ⇔キャリア間では固定文字で内容は分かりません。但しキャリアで公式サイトのドメインと判断されたら、キャリアからケータイサイトまでは平文で送られます。その設定場所はGET引数かPOST変数です。つまり公式サイトのサーバーでなくても途中経路ではuidバレバレです。SSLで暗号化すると今度はキャリアがリクエスト先ドメインを判定できなくてuidを提供できなくなります。guidについても同じ。GETやPOSTだとPCのブラウザを全く改造する必要が無いので簡単に偽装ログインできます。というかGETだった場合、実機だけで偽装できちゃいます。本当に本当にとても頭悪い仕様です。いい加減この仕様は廃止して欲しい。

次にauやsoftbankの場合、HTTPヘッダによって契約者固有IDが送られます。但しこれもFirefoxならFireMobileSimulatorを使えば一発で突破可能です。まだauにはキャリア認証があるので実機以外をブロックすることは可能ですがパフォーマンスが悪くよく認証がダウンするので限定的にしか使用できません。公表はできませんが認証ループしないように認証結果を受け取る仕様があるのですがそれを知っていると認証回避を簡単にできます。

契約者固有IDが簡単に偽装されるならIPフィルタが次の手になります。但し3キャリア共に公開情報が信用できないのは注意書きにも現れています。多分公表と実態のタイムラグが大きいのではないかと思ってしまいます。

IPフィルタで管理が大変なら逆引きで判別するという方法もいくつかのサーバーで見かけましたが、この方法も信用できないのは、キャリアのドメインは実機のみに割り当てているかどうかが全く信用できないという事です。つまりPCとケータイをケーブルに繋いでインターネットしたときにIPアドレスは変わってもドメインが同じならこの方法もアウトになります。ここまではキャリアも情報公開してなさそうだし、3キャリとも実際に試してはないので何とも言えません。これはソフトフォンからの接続では警戒したほうがいいかも知れません。

仕事なので仕方ないにしろ、トップページで自動的に会員認証してポイントやらニックネームやら表示するのはセキュリティ的に危険なだけでなくサーバーに対する負荷も大きいのであまりオススメしないです。(要は非会員分までサーバーリソース食うのはもったいない、非会員にはトップページと入会ページしか見せない完全会員サイトならありかも)

対策としては
  • 契約者固有IDをチェックする際に他のHTTPヘッダが全て実機によるものかを検証する。(殆どのエミュはこれで弾けるがやり過ぎは機種データの対応負担と相談)
  • IPフィルタと逆引きの検証をする(HTTPヘッダ偽装をある程度弾く)
  • DL課金のみのサイトの場合、契約者固有IDはキャリアでの課金以外に流用しない。
    (再ダウンロード補償期間をサイト側で処理する義務があると無理)
  • 契約者固有IDのみでセッション管理しない。Cookieが使えない端末向けには別途工夫が必要。
  • 月額会員サイトはキャリア側の認証かパスワード認証を設置する。リマインダーの設置も必要となるが必ず実機宛てのメアドに制限する。メアド変更のサポートを受付けているならメアド認証しても良い。メアド認証で失敗したら合言葉か一旦退会?
  • ユーザに不必要な情報登録を要求しない。(メルマガ配信や通知をしないのにメアド登録等)
  • 月額課金サイトで退会者の固有情報は次回課金日までに削除する。また差異の補正で会員→非会員となる場合も同様。SoftBankは月末締めでは無いことに注意。これは電話番号が同じ場合に契約者固有IDが重複するためで、ケータイ解約に伴う退会の場合は全く無関係の新規契約者が以前の契約者の情報を知りえてしまう危険があるため。勝手サイトしか作って無い人はこの辺の事情を知らないことがあるので十分注意。ちなみにドコモはある程度対策済み。
  • 検索クローラーを許可するなら、専用ダミーサイトを作って転送しろ。
とりあえずすぐに思いつくのでこんなトコかな。仕事上ではケータイサイトビジネスの常識(?)に負けて正直守れてませんが・・・orz。自前のケータイサイトを作るときにはひとつひとつ実践して行こうとおもいます。

最後に高木浩光さんのエントリーにあるタイトルで「退化してゆく日本のWeb開発者」が気になりますが本当に最近のWeb開発者はHTTPを知らない人が増えてきています。一切ライブラリを使用せずPerlでWebアプリ組んだ経験を持つ人が激減しているのが大きな原因と思います。PHPはGET/POSTが簡単に取得できるとPHPの実装ばかり自慢してその仕様を理解しようとしない後輩を見たとき、Webプログラマーの将来が危ないって感じましたが、本当にそうなってきているのかな・・・。他方Javaの世界でもフレームワークバカが増えて大変だという事を耳にします。

トラックバック(0)

トラックバックURL: http://blog.c-production.com/mt/mt-tb.cgi/1464

コメント(1)

大変参考になりました。

Webプログラマの端くれなのですが、この機会に HTTPをしっかり勉強してみたいと思います。
そこで、もし HTTPの学習に適した書籍などありましたら、ご紹介いただけると幸いです。

コメントする

アーカイブ