Archive for the ‘JPMobile’ Category

『docomo ID認証が怪しげすぎる件』が怪しすぎる件

Wednesday, March 10th, 2010

なんというか、あきれる記事がまことしやかに信じられてて、げんなりなんだけど。
docomo ID認証が怪しげすぎる件 | [ bROOM.LOG ! ]
はてなブックマーク – docomo ID認証が怪しげすぎる件 | [ bROOM.LOG ! ]
本気でケータイサイト作ったことのある人間が読めば「ばっかじゃねーの」的レベルの記事です。
ところがブコメを見るとあまりに鵜呑みにしてるところが多いので、ちょいと軽くツッコミを入れておきます。

そのまえに、まずそれぞれの用語・機能について説明しないといけませんね。

●iモードID
端末（というよりは１契約単位）に与えられた固有のコード。
英数7文字、大文字/小文字の区別はあり。
ユーザ設定によって非通知にも設定可能（これはdocomo IDでの通知にも反映されます（後述））
なお、SSL通信では利用できません。
iモードIDについて（NTTドコモ）に説明があります。
英数7文字、大文字小文字区別ありということは、(10+26+26)^7通り、つまり3.52×10^12、unsignedで42bitで表せる情報(4.40×10^12)です。

●docomo ID
NTTドコモによるOpenID。OpenIDではOPに相当する。携帯電話との連携のために独自仕様が存在する。
なお、OP-local identifierはRP（OpenIDを利用する側）ごとに異なり、他のRPとの共用は出来ない。(仕様書3.7.2の(2)など)
docomo IDについて | NTTドコモ

●docomo ID の独自仕様
携帯電話との連携のために追加された独自仕様。
「ユーザ属性情報通知」（仕様書の3.8）、「ケータイ送信」（仕様書の4）の２つがある。
前者は、認証されたユーザのユーザーエージェント(User-Agentヘッダで送出される内容）とiモードIDを取得できる機能、後者は認証されたユーザに対して誘導先URLを（ユーザのメールアドレスを取得することなく）送信する機能。
正直、前者に関しては「これならSREGとか使えよ！」と思った程度にひどい（訂正）SREGだと「だだ漏れ」になっちゃうからマズいですよね。一応、OP-local identifierとresponse_nonceの両方が必要でなおかつ有効期限が設定されている（短い）ため、第三者から乗っ取りアクセスはほぼ不可能。
ケータイ送信は、OpenIDの機能を使ってない。docomo IDのサイトでログインセッションが有効なときのみ使用可能で、docomo IDのサイトでユーザーに対して「送信確認」を行わないと使用できない。

それでは、説明が終わったので、本題。

まずは私自身の持論。
iモードIDですが、そもそもこれをID+パスワードの代替として使うものではない、ってことです。だからこれを「かんたんログイン」として使うには危険ってこと。
「guid=ON」さえつければ取得できる情報なので、IPアドレスと同程度の情報、と考えてます。
ちなみに、iモードID送出をオフにした（iメニューから辿って設定できます)場合、docomo IDで取得しようとした場合、このようになります。
（１つ前の記事で書いたサンプルを利用しました。）
2010031021
GUIDに「9999999」など、本来と違う値がかえってきます。

まず、そもそもの「iモードID抜き放題」の話。
42bitくらいの情報だったら、ブルートフォースアタックしちゃえばいいじゃん！
IPアドレス制限してないとこだったら、（げふんげふん（自主規制））
まぁ、docomo ID使って取得じゃ！とかそんなセコいことしなくても得られるしー。

そして。
「危ない」という事例で示してる例は、よく読むといづれも「docomo ID」とは直接関係しない事例。
つまり、アクセス元のIPアドレスをチェックしてない（つまり、本当にケータイかどうかをチェックしてない）サイトに対して、突破攻撃できちゃうよん、ってこと。
それ、全然iモードIDともdocomo IDとも関係ないじゃん。
iモードIDの取得？docomo IDなんか使わないで、ケータイ向け勝手サイト作ってケータイで直接アクセスさせたほうがよっぽど効率的に取得できますよー。うふふ。

さらに大きな間違いが１つ。

docomoからすれば、これだけ世に広まっているケータイ認証や決済をPCの世界にも広めたい意図なのだというのは容易に想像できる。

「オフィシャルの」決済系はケータイからじゃないと行えないです。
単刀直入に言うと、決済処理に入るには、iモードIDだけではなにもできません。
いったん、決済の確認ページに飛ばされて、暗証番号を要求されます。

なんというか。
docomo IDのシステム「だけ」を責めるのは根本的に間違ってるよ、ってことが言いたかったんです。

Posted in JPMobile, OpenID | Comments Off on 『docomo ID認証が怪しげすぎる件』が怪しすぎる件

docomo ID の独自APIにアクセスする(1)

Wednesday, March 10th, 2010

前回の続きです。
例によって？PHP OpenID Libraryのexampleを改造。

今回は、独自APIの１つ「ユーザ属性情報通知」(3.8)、これはiモードID(guid=ONにしたときにDCMGUIDヘッダで取得できる個体識別文字列)をとってくるAPIです。
なお、iモードIDに関しては以前書いたのでそちらを参照してください。

割と手抜きのコードですが、差分はだいたいこんなかんじ。

--- ../../../w/php-openid-2.1.3/examples/consumer/finish_auth.php       2009-04-22 03:31:20.000000000 +0900
+++ ./finish_auth.php   2010-03-10 18:29:39.000000000 +0900
@@ -38,6 +38,26 @@
             $success .= '  (XRI CanonicalID: '.$escaped_canonicalID.') ';
         }

+       // var_dump ($response->message->getArg('http://specs.openid.net/auth/2.0','response_nonce') ) ;
+       // var_dump ( $response->message ) ;
+       $response_nonce = $response->message->getArg('http://specs.openid.net/auth/2.0','response_nonce') ;
+
+       // call docomo original API
+       $success .= "<br />response_nonce:" . $response_nonce . "<br /><br />\n" ;
+       $apicall_url  = "https://i.mydocomo.com/api/imode/g-info?" ;
+       $apicall_url .= "ver=1.0&openid=" . urlencode( $openid ) ;
+       $apicall_url .= "&nonce=" . urlencode( $response_nonce ) ;
+       $apicall_url .= "&GUID=&UA=" ;
+       $cu = curl_init() ;
+       curl_setopt( $cu , CURLOPT_URL            , $apicall_url ) ;
+       curl_setopt( $cu , CURLOPT_RETURNTRANSFER , TRUE ) ;
+       $httpresult = curl_exec( $cu ) ;
+       $aline = explode( "\n" , $httpresult ) ;
+       $success .= "API RESULT:<br />\n" ;
+       foreach( $aline as $a ) {
+               $success .= $a . "<br />\n" ;
+       }
+
         $sreg_resp = Auth_OpenID_SRegResponse::fromSuccessResponse($response);

         $sreg = $sreg_resp->contents();

実行するとこんなかんじになります。
2010031011

追記：docomo IDの実装をはじめ、なぜiモードID等の取得のみこのようなことをしてるかについて興味深い考察をしてるサイトがありましたので紹介。
docomoのOpenIDの実装周りについて – 金利0無利息キャッシング – キャッシングできます – subtech

Posted in JPMobile, OpenID, PHP | 1 Comment »

PHP OpenID Library で RP Discovery要求対応の例

Wednesday, March 10th, 2010

具体的に言うとdocomo IDのことなんですが（笑）
とりあえずわかったことなんでメモ。

OpenIDそのに関しては前書いたメモがあるんでそっち参照。
で、今回の件。docomo IDの場合、RP Discoveryするんで、TrustRoot のaddressに、Accept: application/xrds+xmlで要求かけてるんですよね。
だから、index.php で、Acceptを判定して、XRDSドキュメントを返してあげればOKです。

PHP OpenID Libraryのexampleだと、追加するコードはこうなります。

--- ../../../w/php-openid-2.1.3/examples/consumer/index.php	2009-04-22 03:31:20.000000000 +0900
+++ ./index.php	2010-03-10 10:10:52.000000000 +0900
@@ -2,6 +2,17 @@
 require_once "common.php";
 
 global $pape_policy_uris;
+
+if ( $_SERVER['HTTP_ACCEPT'] == "application/xrds+xml" ) {
+	// returns XRDS
+	header ( "Content-type: application/xrds+xml" ) ;
+	$fh = fopen( "yadis.xrdf" , "r" ) ;
+	while( !feof( $fh ) ) {
+	 	print fgets( $fh ) ;
+	}
+	fclose( $fh ) ;
+	exit() ;
+}
 ?>
 <html>
   <head><title>PHP OpenID Authentication Example</title></head>

そして、読み込んでるyadis.xrdfはこう。

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/return_to</Type>
<URI>http://example.ne.jp:80/php-openid-2.1.3/examples/consumer/finish_auth.php</URI>
</Service>
</XRD>
</xrds:XRDS>

URIには、戻り先のURIを書いてねー。

もうちょっと、まともな書き方(XRDSを返す関数での書き方)があると思いますが、それはあとで調べて書くつもり。

なお、この件は、「docomo ID 認証　インターフェース仕様書」の「3.7.2 OP実装仕様」の表3.2にありるように、

RP Discoveryに失敗した場合、RPにはエラーは返却せず、エラー画面を返却し終了します。

と、なってます。だからいきなりこんな画面が出ます。
2010031001
無事成功するとこうなります。
2010031002
docomo ID 固有の実装・機能に関しては、のちほど書きたいと思います。

参考：RP Discovery対策 – Web Life!!! – Yahoo!ブログ

Posted in JPMobile, OpenID, PHP | 1 Comment »

ケータイサイトのデザインで「はじめに」注意すべきこと

Wednesday, December 2nd, 2009

現在、お仕事ですごく絡んでいて泣かされております（苦笑）。

そんななか、いいまとめがあったので、紹介したいと思います（自分用メモも兼ねて）
携帯サイト（html）の制作に入る前に確認しておきたいチェック項目 │ これからゆっくり考L +α
ケータイデザインで出来ること出来ないことがまとめられた記事「携帯サイト（html）の制作に入る前に確認しておきたいチェック項目」 | ke-tai.org

制約が多いので、どうしても「できないこと」があります。
その点は、開発者もデザイナーも企画さんも頭に入れておくべきです。

引用すると、チェックすべき項目は以下のとおり。

  • tableの使用はOKか
  • 背景色を複数色使っていないか
  • 枠線を使っていないか
  • サムネイル画像の横にテキストが来るパターン
  • リストアイコンの下に文字が回り込んでくるかどうか
  • ページの左右に微妙な余白が空いていないか
  • フォントサイズは2段階ないし1段階か
  • 太字を使っていないか

あと「tableが使用可能」という条件がついた場合の注意すべきところはこちら。
携帯サイト（html,table使用可）の制作に入る前に確認しておきたいチェック項目 │ これからゆっくり考L +α

余談ですが、table使いまくりって、ネスケ４の頃を思い出しますねー。あははー。

Posted in JPMobile, SiteDesign | Comments Off on ケータイサイトのデザインで「はじめに」注意すべきこと

コメントつきRTが非常に鬱陶しくてしかたがないのでいい表示方法を考えてみた。

Tuesday, December 1st, 2009

未だ公開する気のない(主に実装がきたないのと、動きがおかしいのと、OAuth使ってないので怖いのというのが理由で・・・）ぷちつい(petitTwitter)でのはなし。
コメントつきRTが鬱陶しくてうざいので、きれいに表示する方法を考えてみました。

      // コメントつきRT(QT)対応
      if ( mb_ereg( "RT @" , $text ) && ( ! mb_ereg( "^RT @" , $text ) ) ) {
        mb_ereg( "(RT @.+)$" , $text , $gettext0 ) ;
        $srctext = $gettext0[1] ;
        $gettext1 = explode( "RT @" , $text , 2 ) ;
        $desttext = $gettext1[0] ;
        $desttext .= "<blockquote>" ;
        $destexp = explode( "RT @" , $srctext ) ;
        foreach( $destexp as $destout ) {
          if ( $destout == "" ) continue ;
          $desttext .= "<font color=\"#40c040\">↑</font><font color=\"#808080\">RT @" . $destout . "</font><br />" ;
        }
        $desttext .= "</blockquote>" ;
        $text = $desttext ;
      }
      $text = "<font size=\"2\">" . $text . "</font>" ;

ただこれは、『RT @〜』って表記にしか対応してません。
よく代替案としてあげられてる『QT @〜』にはまだ対応しておらず。
explodeでは正規表現使えないので、preg_split するしかないですね。

preg_split( "/[RQ]T @/" , $srctext ) ;

みたいなかんじなるのかなー。

こんなかんじになります。

タイムラインで。勝手に使ってごめんなさい＞＜
2009120101
自分自身のpostはこんなかんじ。
2009120102

Posted in JPMobile, PHP, Twitter | Comments Off on コメントつきRTが非常に鬱陶しくてしかたがないのでいい表示方法を考えてみた。

ケータイアクセスのみに限る方法(IPアドレスで見る方法)

Thursday, November 26th, 2009

手っ取り早く？、IPアドレスを32bit intにして比較する、って方法にしました。
長くなるんでー。
(more…)

Posted in JPMobile, PHP | Comments Off on ケータイアクセスのみに限る方法(IPアドレスで見る方法)

ケータイサイトを作る上でのリンクとか情報とか

Thursday, November 26th, 2009

自分用リファレンスとして。

●公式TOP ・・・ ここからすべてたどれます。

●ブラウジング、タグ

●ユーザーエージェント

●絵文字

●IPアドレスブロック
すべて、 IPアドレス/ネットマスク(ビット)で書かれています。(例：172.16.20.0/24)

●端末固有情報(2010/04/02追加)

●その他参考にしたいところ(2009/12/02追加)

●最後にひとこと。
正直言って・・・クソ仕様と戦いながら、バッドノウハウの塊がないとやっていけないケータイサイト運営ですが、個人的には（ここしばらくは）大きな市場だとは思ってます。もはや、避けては通れない何かですね。

Posted in JPMobile, References | 1 Comment »