簡単ログインについて触れられているエントリーがありましたので、私なりの意見も。
高木浩光＠自宅の日記 - 無責任なキャリア様に群がる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フィルタが次の手になります。但し３キャリア共に公開情報が信用できないのは注意書きにも現れています。多分公表と実態のタイムラグが大きいのではないかと思ってしまいます。
IPフィルタで管理が大変なら逆引きで判別するという方法もいくつかのサーバーで見かけましたが、この方法も信用できないのは、キャリアのドメインは実機のみに割り当てているかどうかが全く信用できないという事です。つまりPCとケータイをケーブルに繋いでインターネットしたときにIPアドレスは変わってもドメインが同じならこの方法もアウトになります。ここまではキャリアも情報公開してなさそうだし、３キャリとも実際に試してはないので何とも言えません。これはソフトフォンからの接続では警戒したほうがいいかも知れません。
仕事なので仕方ないにしろ、トップページで自動的に会員認証してポイントやらニックネームやら表示するのはセキュリティ的に危険なだけでなくサーバーに対する負荷も大きいのであまりオススメしないです。（要は非会員分までサーバーリソース食うのはもったいない、非会員にはトップページと入会ページしか見せない完全会員サイトならありかも）
対策としては
最後に高木浩光さんのエントリーにあるタイトルで「退化してゆく日本のWeb開発者」が気になりますが本当に最近のWeb開発者はHTTPを知らない人が増えてきています。一切ライブラリを使用せずPerlでWebアプリ組んだ経験を持つ人が激減しているのが大きな原因と思います。PHPはGET/POSTが簡単に取得できるとPHPの実装ばかり自慢してその仕様を理解しようとしない後輩を見たとき、Webプログラマーの将来が危ないって感じましたが、本当にそうなってきているのかな・・・。他方Javaの世界でもフレームワークバカが増えて大変だという事を耳にします。
高木浩光＠自宅の日記 - 無責任なキャリア様に群がる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フィルタが次の手になります。但し３キャリア共に公開情報が信用できないのは注意書きにも現れています。多分公表と実態のタイムラグが大きいのではないかと思ってしまいます。
IPフィルタで管理が大変なら逆引きで判別するという方法もいくつかのサーバーで見かけましたが、この方法も信用できないのは、キャリアのドメインは実機のみに割り当てているかどうかが全く信用できないという事です。つまりPCとケータイをケーブルに繋いでインターネットしたときにIPアドレスは変わってもドメインが同じならこの方法もアウトになります。ここまではキャリアも情報公開してなさそうだし、３キャリとも実際に試してはないので何とも言えません。これはソフトフォンからの接続では警戒したほうがいいかも知れません。
仕事なので仕方ないにしろ、トップページで自動的に会員認証してポイントやらニックネームやら表示するのはセキュリティ的に危険なだけでなくサーバーに対する負荷も大きいのであまりオススメしないです。（要は非会員分までサーバーリソース食うのはもったいない、非会員にはトップページと入会ページしか見せない完全会員サイトならありかも）
対策としては
- 契約者固有IDをチェックする際に他のHTTPヘッダが全て実機によるものかを検証する。（殆どのエミュはこれで弾けるがやり過ぎは機種データの対応負担と相談）
- IPフィルタと逆引きの検証をする(HTTPヘッダ偽装をある程度弾く)
- DL課金のみのサイトの場合、契約者固有IDはキャリアでの課金以外に流用しない。
（再ダウンロード補償期間をサイト側で処理する義務があると無理） - 契約者固有IDのみでセッション管理しない。Cookieが使えない端末向けには別途工夫が必要。
- 月額会員サイトはキャリア側の認証かパスワード認証を設置する。リマインダーの設置も必要となるが必ず実機宛てのメアドに制限する。メアド変更のサポートを受付けているならメアド認証しても良い。メアド認証で失敗したら合言葉か一旦退会？
- ユーザに不必要な情報登録を要求しない。（メルマガ配信や通知をしないのにメアド登録等）
- 月額課金サイトで退会者の固有情報は次回課金日までに削除する。また差異の補正で会員→非会員となる場合も同様。SoftBankは月末締めでは無いことに注意。これは電話番号が同じ場合に契約者固有IDが重複するためで、ケータイ解約に伴う退会の場合は全く無関係の新規契約者が以前の契約者の情報を知りえてしまう危険があるため。勝手サイトしか作って無い人はこの辺の事情を知らないことがあるので十分注意。ちなみにドコモはある程度対策済み。
- 検索クローラーを許可するなら、専用ダミーサイトを作って転送しろ。
最後に高木浩光さんのエントリーにあるタイトルで「退化してゆく日本のWeb開発者」が気になりますが本当に最近のWeb開発者はHTTPを知らない人が増えてきています。一切ライブラリを使用せずPerlでWebアプリ組んだ経験を持つ人が激減しているのが大きな原因と思います。PHPはGET/POSTが簡単に取得できるとPHPの実装ばかり自慢してその仕様を理解しようとしない後輩を見たとき、Webプログラマーの将来が危ないって感じましたが、本当にそうなってきているのかな・・・。他方Javaの世界でもフレームワークバカが増えて大変だという事を耳にします。
追記：5月7日
沢山のブックマーク頂き正直驚いています。はてなでのコメントから抜粋して回答したいと思います。
> 契約者固有ID
ここでは引用元の記事からこの呼び名を持ってきましたが普段はUIDとかユーザIDまたは端末IDなんて呼んでいます。もしかしたらユニークIDって呼んでいる人もいるかも。キャリアでもそれぞれ呼び名が違うので名称そのものに深い意味は無いです。
> フレームワークバカ
フレームワーク依存が激しすぎてフレームワークなしでは全く開発できない人の事をこう呼んでみました。
> 簡単ログインはやめたとしても、課金情報管理は端末ID
そうですね。。。契約者固有IDを利用しないとなるとユーザを特定するために別途メールアドレスかアカウント登録が必要になり、そのユーザ負担の手間を嫌うのではないかなと思います。
> HTTP知らないとかいうなら、アセンブラも知らないやつが言うな
アセンブリ言語やアセンブラの動作やマシン語知っててもHTTPの理解には役立ちません。Web開発もネットワークプログラミングの一部なので TCP/IPネットワークの基礎からWebシステムで利用するプロトコルの仕様を学習すればWebプログラミングの理解がより深くなるものと思っています。またバグが発生したときに原因を特定する知識として大変役立ちます。流石にネットワーク技術者のような通信知識(IPより下の階層の通信仕様)は特になくても大丈夫だと思います。
> 「対策」のうち1つ目の項目は無意味。7つ目が興味深い。
1つ目はメンテナンス費用対効果が低すぎるので実環境には入れたことありません・・・。正直仕様を追うのが大変です。これは各々でやるよりもオープンなライブラリ等で実装が進めば良いのですがそれでもタイムラグが発生する場合を考えると意味無いかも。エミュでハックする側は１機種の仕様を実装すれば良いしエミュが無ければtelnetでの方法ですぐマネされますね・・・すみませんでした。
7つ目、クローラーをダミーサイトに転送する理由は「メンテ中でもメンテナンス画面をキャッシュされなように分けておく」のと「エラーメッセージなど想定外のキャッシュを簡単に防ぐ」、そして「会員システムにアクセスさせない」です。ダミーサイトと呼んでますが「綺麗なハリボテ」みたいな物です。
このエントリーを見てケータイサイト自身について心配されている方も多いと思いますが、公式サイトについてはキャリアからの検証もありますのでエミュでアクセスし放題なサイトは無いと信じています。またキャリアで回収代行を行っている場合は課金情報管理の所在はキャリアになり、サイト側はキャリアに照会できないケースが発生した時のバックアップなのでエミュでアクセスされて勝手に課金されるといったことはありません。ただキャリアもサイトももっと詰めが必要なのは実感しています。
沢山のブックマーク頂き正直驚いています。はてなでのコメントから抜粋して回答したいと思います。
> 契約者固有ID
ここでは引用元の記事からこの呼び名を持ってきましたが普段はUIDとかユーザIDまたは端末IDなんて呼んでいます。もしかしたらユニークIDって呼んでいる人もいるかも。キャリアでもそれぞれ呼び名が違うので名称そのものに深い意味は無いです。
> フレームワークバカ
フレームワーク依存が激しすぎてフレームワークなしでは全く開発できない人の事をこう呼んでみました。
> 簡単ログインはやめたとしても、課金情報管理は端末ID
そうですね。。。契約者固有IDを利用しないとなるとユーザを特定するために別途メールアドレスかアカウント登録が必要になり、そのユーザ負担の手間を嫌うのではないかなと思います。
> HTTP知らないとかいうなら、アセンブラも知らないやつが言うな
アセンブリ言語やアセンブラの動作やマシン語知っててもHTTPの理解には役立ちません。Web開発もネットワークプログラミングの一部なので TCP/IPネットワークの基礎からWebシステムで利用するプロトコルの仕様を学習すればWebプログラミングの理解がより深くなるものと思っています。またバグが発生したときに原因を特定する知識として大変役立ちます。流石にネットワーク技術者のような通信知識(IPより下の階層の通信仕様)は特になくても大丈夫だと思います。
> 「対策」のうち1つ目の項目は無意味。7つ目が興味深い。
1つ目はメンテナンス費用対効果が低すぎるので実環境には入れたことありません・・・。正直仕様を追うのが大変です。これは各々でやるよりもオープンなライブラリ等で実装が進めば良いのですがそれでもタイムラグが発生する場合を考えると意味無いかも。エミュでハックする側は１機種の仕様を実装すれば良いしエミュが無ければtelnetでの方法ですぐマネされますね・・・すみませんでした。
7つ目、クローラーをダミーサイトに転送する理由は「メンテ中でもメンテナンス画面をキャッシュされなように分けておく」のと「エラーメッセージなど想定外のキャッシュを簡単に防ぐ」、そして「会員システムにアクセスさせない」です。ダミーサイトと呼んでますが「綺麗なハリボテ」みたいな物です。
このエントリーを見てケータイサイト自身について心配されている方も多いと思いますが、公式サイトについてはキャリアからの検証もありますのでエミュでアクセスし放題なサイトは無いと信じています。またキャリアで回収代行を行っている場合は課金情報管理の所在はキャリアになり、サイト側はキャリアに照会できないケースが発生した時のバックアップなのでエミュでアクセスされて勝手に課金されるといったことはありません。ただキャリアもサイトももっと詰めが必要なのは実感しています。
大変参考になりました。
Webプログラマの端くれなのですが、この機会に HTTPをしっかり勉強してみたいと思います。
そこで、もし HTTPの学習に適した書籍などありましたら、ご紹介いただけると幸いです。
コメントありがとうございます。HTTPの学習についてですがWeb言語関連の本で見たことはないし、私が学習したときは雑誌と実際の通信をハックする事ぐらいでしたので現在Web関連通信の良書を把握できてなくて申し訳ありません。昔参考にしていた雑誌ではCマガジン2000年12月号に「インターネットプログラムの基礎知識」というのがあり、そこではHTTP/POP3/SMTP/FTPプロトコルの実装が取り上げられていて必死に勉強しました。ただしこれはC言語の雑誌のためソースはC言語ですしかなり古い為、手に入らないかと思います。その他ではネットで参考になるサイトを探すことになったのですが、そこで出会ったサイトで「ネットワークプログラミングの基礎知識（http://x68000.q-e-d.net/~68user/net/）」があり大変参考になりました。こちらはPerlのサンプルもあります。他にはHTTPでのデータ処理については「Perl/CGI 300の技（http://www.tohoho-web.com/perl/encode.htm）」を参考にしています。その他Web開発者なら「とほほのwww入門」はネットバイブルって呼んでも良いと自分で思ってたりします。