モバイル用GWのIPアドレスを気にしてた時代もあったなぁ
twitter始めたらすっかりブログ書かなくなってしまいましたがどうしても気になるエントリがあったので久しぶりに。
orangevtr いろいろ認識が甘すぎて唖然とする。IP制限してても今時はクローラーキャッシュからソース読めるし（ http://d.hatena.ne.jp/komoriya/20090122/1232619395 ）、HTTPヘッダは偽装できないとかいくらなんでも。PHP使いなのにcurl知らないの
はてなブックマーク - ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
はてブでは制限文字超えちゃったのとちょっと言い回しが不遜な感じになってしまったので改めて。
ソフトバンクの携帯用ゲートウェイを、PC経由で通る方法があるとのことです。
扱う情報にもよりますが、ケータイサイトではIPアドレス帯域を制限して、ケータイからのアクセスのみを許可するのが一般的です。
これが可能なのであれば色々と問題がありますね。
ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
サーバー側では端末からのアクセスしか想定せずに実装していたはずが、思いに反して端末以外からもアクセスが来ることがあるようなのでこれは問題だ！というエントリ。
この中で何点か認識に根本的な相違があるようなので、それを指摘したかったのが前述のブクマコメントです。まずこの部分↓
これらの方法をつかえば、例えばケータイからのみしかアクセスできないサイトにアクセスし、HTMLソースを見てデザインの参考にする、といったことが可能になります。
ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
GWのIP制限のみによってケータイからのアクセスしかできないようにしたサイトであっても、クローラーのキャッシュからHTMLのソースコードを確認することが可能です。
モバイルサイトのコーディングをする際、他サイトのコードを参考にしたいけど携帯端末以外のIP制限がかけられておりソースが参照できない場合があります。
そういったときはGoogleを使ってPCのブラウザなどから見る事ができます。
なので、HTMLのソースを見られてデザインの参考にされるということは大いにありえます。というか、PCのWebの世界では当たり前ですよね。
実は同様のロジックで、身近でも時たま「ソース見られないからセキュリティとか気遣わなくてOKとかいう」輩も見かけるのですが、これは完全に開発者の怠慢だと思っています。*1
ただ、契約ユーザID（x-jphone-uid）のヘッダ情報はネットワーク側で付与されるので、こちらは偽装が不可能とのことです。
ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
これについてですが、前段まででキャリア指定のIPアドレスからアクセスしてくる端末には携帯端末に限るという前提が既に崩れているわけなので、当然任意のHTTPヘッダを送信してくる場合もあるわけです。
特に「モデム接続した場合」とありますがその場合はリンク層での接続ですから、HTTPプロトコルであるx-jphone-uidヘッダの上書きが起こるのは考えにくいです。*2（2009/8/6訂正追記しました。こちらはGWを通りさえすれば付加されると考えても良さそうですね。）
なぜ対策が取られていないのでしょうか？
ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
この答えは明白です。なぜなら、
キャリアは対策をとる理由がない
からです。
端末IDというのは、本来広告配信とかクリック集計とかの、「ある程度は誤差が認められる程度の緩い」個体認識に利用されることを想定されて設けられている程度のもので、認証などに利用すべきではなく、あくまでWebアプリケーションですので、ID/パスワード認証＋セッション保持で行うというのが大原則です。
悪用方法としては、待ち受け画像などにアクセスしてPC上から保存してしまう（これが可能かどうかはプログラム側の作りにもよりますが）、他人の端末ID（製造番号）を騙ってログインしてしまう、などが考えられます。
ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
前述の前提から、キャリアとしては端末IDを認証に使うというのは想定外という訳です。*3
このあたりは高木浩光氏のブログなどでも幾度となく上っている話ですね。
ただし、ケータイサイトでは「かんたんログイン」などの手段が横行しており、ユーザー視点ではある程度の市民権を得てしまっているのは事実であるので、この方法を提供できないというのはユーザビリティ上劣ってしまうことになってしまい、受託開発の場合や、競合メディアで実装されている場合はどうしても実装せざるを得ない場合があることも確かです。
現場のエンジニアとしては、本来としては何が「本来正しくて」、かつあくまでその中で現実問題としてどういうソリューションを提供するのが妥当かを判断するのが重要ではないかと思います。
その上で、
- 受託開発の場合：現実装方法に伴うセキュリティリスクと利便性のトレードオフについて顧客に十分に説明する
- 自社サイト開発の場合：ユーザーにまつわるデータの重要性とセキュリティレベルを鑑みて、利便性とのトレードオフを十分に検討する。また、ユーザーは極力リスクを負わないようにし、どうしても必要な場合は十分に説明する
とするのが開発者としてあるべきスタイルではないかと考えます。
もちろん一方で、Webサイト開発環境として不備であるならば、多方面からキャリアにはたらきかけていくのも重要です。
実際の身の回りの仕事上では、実は認証の目的でGWのIPアドレスをベースにチェックする、ということはやめてしまいました。その代わり、通常のブラウザで閲覧された場合も十分問題ないように出力することを最初から想定してサイトを構築するようになっています。
どうしても「かんたんログイン」に相当する機能を実装しなくてはならない場合も、重要な情報は取り扱わないようにしたり、ワンタイムセッションと組み合わせるとかしてセキュリティを考慮するようにしています。
ブクマとかコメントいただいたので追記。（2009/8/6）
id:HiromitsuTakagi 氏のブクマ：
「キャリアとしては端末IDを認証に使うというのは想定外という訳です*3」< いやいやところがどっこい → http://bit.ly/Wgcdb「NTTドコモは、契約者固有IDが「簡単ログイン」のために使うものであることを公式に認めたのだ」
・・そうでした。該当のエントリは読んだことがあったのですが、「キャリアとしては公式に認めていないもの」と思い込んでいました。そうなると、本文の
前述の前提から、キャリアとしては端末IDを認証に使うというのは想定外という訳です。
というのは事実と反してしまいますね。すみません。
id:IwamotoTakashi 氏のブクマ：
元記事には偽装できなかったとの追記がある。
確かに元記事には
※追記 フォーラムから次のような報告がありました試してみたのですが、実際にSBのIPでパソコンから接続することが出来ました。
FireMobileSimulatorで指定してみたのですが、偽装出来ませんでした。ke-tai.org > Blog Archive > ソフトバンクの携帯用GatewayをPCで通る方法があるようです
とありましたが手順が曖昧だったのとソースが不明確だったので、該当の場合に偽装できなかった確認とは考えていませんでした。しかし、コメントで「匿名の臆病者」氏より
＞リンク層での接続ですから
透過プロクシという仕組みはご存じない? あ、ということは少なくともhttpsにx-jphone-uidが乗っていたら擬装の虞か。(端末はuidを吐かないので)
確かに透過プロキシ使えば任意に付加できますねー。DoCoMoのX-DCMGUIDヘッダもHTTPSでは付加されないし、も同じ仕組みなのかも。
となると、「キャリアのGWを通る限り端末IDは付加される」という仮定は成り立ちそうですね。この点については訂正させて頂きたいと思います。
＞端末IDを認証に使うというのは想定外
公式プロバイダの会員管理って、いわゆる端末 ID（docomo/SBMはuid、auはEZ番号）を使うしかないし、公式の仕様にもそう載っているし、IPアドレス制限をするように、と書いてあるんですが。docomoのuidなんてクエリ文字列に乗せるんですよ? 公式プロバイダ向けにはIPアドレスの変更情報は流れますけれど、それだけです。ただし、いわゆる端末IDと呼ばれるものでも、端末製造番号(docomo)、FOMAカード番号(docomo)、端末シリアル番号(sbm)は公式サイトでは使いません。
私も公式サイトは何度も構築したことがありますし、上記手段しかないことはよく理解しています。しかし、「公式CP向けの仕様にもそう書いてあるから」とか、「どこのサイトでもそうやっているから」という点で思考停止してしまってはいけないのでは、ということがこのエントリで言いたかったことです。
キャリアの仕様にどうしても乗っからなければならないの場合もありますが、そこに潜在するリスクを理解してやむなくそうしているのか、そういう仕様だからということで思考停止しているかは大きく違うと思うのです。
前者であれば顧客やユーザーのリスクをなるべく低減するアクションに出ると思うし、キャリアへの喚起も多方面からされていくはずだと思いますがいかがでしょうか。
逆にこういう環境でしか開発をしたことがない開発者がPC Webサイトを構築しようとすると・・どうなるか容易に想像できるでしょう。今どきセッションもまともに使えないようなエンジニアの出来上がり、です。これは夢物語ではなく、実際にそういうエンジニアには多々遭遇したことがあり、幾度となく唖然とさせられてきました。
そういった後継エンジニア育成の観点からも、「この仕様は本来としては非常にまずい仕様なんだけど現状は乗っからざるを得ないんだよ」と言い続けることは必要だと考えます。
