y-kawazの日記 このページをアンテナに追加 RSSフィード Twitter

Google

2007-02-28 携帯業界の認証事情 Part2

先日の日記で携帯の認証に関しての考察をして、とりあえずキャリア毎のIP制限を行っていれば端末IDやユーザID認証を信用していいのでは無いか?と書いたのだが、更に調べた結果どうも怪しい実態が見えてきたので危険度と合わせて再度纏めてみようと思う。

とりあえず指摘があったので前回のテストに加えて以下を試してみました。

NOuidに指定した値実際に送信されてくる値
8%30%31%32%33%34%35%36%37%38%39%61%62*11234567890ab

うわ弱っ、駄目じゃん。見事にuidの詐称が成功してしまった…。

DoCoMoのユーザIDの信頼性が地に落ちた瞬間です。

2007-03-01追記)DoCoMoスゲー!昨日は確かに上記の方法で詐称できたのに、今日はもう既に対策されとるし(^^;

今、同じことを試すと以下のメッセージが出るのみでした。

IPサイトの記述に誤りがあるためアクセスできません。

Your request cannot be processed due to a wrong description on the contents provider's site.

しかしこのタイミングで対策されたってのは何なんだろうか、この記事でDoCoMoが動いたとは到底考えにくいので、ホントに偶然に今日この対策が行われる計画でもあったんかな…?


以下に「キャリア毎にIP制限がされている上でのIDの詐称可能性」について一覧します。

キャリアID種別実装方法詐称可能性コメント
DoCoMo端末IDUser-Agentに付加無し?任意のUser-Agentを送信できるブラウザが無い為*2
DoCoMoユーザIDuidパラメータ無し2007-02-28までは脆弱だったが2007-03-01には対策された*3
DoCoMoiモードID*4X-DCMGUIDヘッダ無し任意のX-DCMGUIDヘッダを送信できるブラウザが無い為*5
SoftBank端末User-Agent有りスマートフォンのブラウザを使うことで詐称可能らしい
SoftBankユーザx-jphone-uidヘッダ無し任意のx-jphone-uidヘッダを送信できるブラウザが無い為*6
AUユーザx-up-subnoヘッダ無し任意のx-up-subnoヘッダを送信できるブラウザが無い為*7

現状、過度に楽観視はできなさそうですが、それも今後の各キャリアの対応によることでしょう。

ただ、この表で詐称可能性が「無し?」となっているものは、現在僕が検証できた範囲で「無し」としているのみなので、今後誰かの手による確認で突破されるんじゃないか、という予感は個人的にはとてもします…。

もしそんなことになったらクッキーが使えない以上、最悪の場合、殆ど全ての携帯サイトの認証に脆弱性があるということになってしまいます。それを水際で食い止める為にも判明している脆弱性に関して各キャリアはID認証の信頼性を保つために偽装対策を早急に行う必要があるでしょう*8。出来ればIP制限の元ではこのIDは信頼して良いですよ、という言葉をキャリア側から頂けると嬉しいですね。

とりええずサイト開発側で行えることは、上記表で詐称可能性が「有り」の認証方法しか使っていない場合はそれたよらず「無し」の方法やパスワード等による再認証を併用するなどの対策をおこなうということですかね。

2007-03-02追記)先日の日記のコメントに以下のように書いたんですが、

ユーザIDに関しては各キャリアのゲートウェイが行うもので、その正統性の保証も各キャリアが各種対策を施し続けて維持するモノだと思っています。

http://d.hatena.ne.jp/y-kawaz/20070224#c1172772767

思うに、携帯キャリアの姿勢としては脆弱性が発見される度に、例えそれがアドホックな対策と言われようとも今回のDoCoMoの様にひたすら対策し続けていく、というのは一つの正しい在り方だと思う。

  • キャリアはコンテンツサイトに対して課金可能な認証手段を提供する。
  • コンテンツサイトはキャリアに提供してもらった認証手段を信頼する。
  • キャリアは信頼された以上、それが信頼に足るものであるよう努力する。

そういうことでいいのかもな、と思った。*9

追記)2008/03/31より「iモードID」が解禁されたのでその情報を追記

*1:1234567890ab をURLエンコードしたもの

*2:今後SIMフリーが始まったりしてドコモの管理が届かないスマートフォンの勝手アプリのようなものが溢れ出したらゲートウェイ側で端末IDの正当性を保証することは難しく(ぶっちゃけ不可能に)なるんじゃないかと思う。

*3:URLエンコードでuidの値の見た目を12桁で無くすことによりDoCoMoが行っている偽装対策の回避が可能だった

*4:ユーザIDと同等にiモード契約毎にユニークなID。詳しくはこちら

*5:仮にあったとしても詐称を許さない仕組みがあると信じたいし、それはキャリアの義務だと思う。

*6:仮にあったとしても詐称を許さない仕組みがあると信じたいし、それはキャリアの義務だと思う。

*7:仮にあったとしても詐称を許さない仕組みがあると信じたいし、それはキャリアの義務だと思う。

*8:DoCoMoは速やかに対応したので見直した。

*9:勿論キャリアが信頼を裏切って要の脆弱性を放置するようなことがあれば、ユーザからもコンテンツ提供側からも見限られて消滅する運命になるでしょう。

y-kawazy-kawaz 2007/03/02 14:14 はてぶのコメントで高木さんに再現した時の手順を示せと言われているようですが、このテストは http://d.hatena.ne.jp/y-kawaz/20070224 の続きとしてかいているのでそっちを読んでもらえば説明は不要かと思ったんですが確認の為に書くと、<a href=”test.php?uid=%30%31%32%33%34%35%36%37%38%39%61%62”>test</a> などというリンクを作ってアクセスしたら $_GET[’uid’] で 1234567890ab が取れてしまった(詐称したuidを送れてしまった)というのが手順です。で、今はこのようなURLのアクセス自体がゲートウェイで止められるようになったようだ、という話。

ockeghemockeghem 2007/03/02 15:13 公式コンテンツを使ってこのような実験が出来る人は限られていると思うので貴重な情報ですが、そもそもこういうことを公式サイトを使って実験し、かつその内容を公開しても問題ないのでしょうか?

y-kawazy-kawaz 2007/03/02 15:43 自分でphpを設置せずとも、ユーザサポート用やデバッグ用なのか知らないけれどパラメータや環境変数を確認できるCGIを置いている公式サイトがどことはいいませんが結構存在するのでそういうところを利用することで誰でも今回のような検証は可能です。ただそういうサイトを目的外のこのような実験でつかってよいのか?という点では微妙かもですが。

ockeghemockeghem 2007/03/02 16:01 さっそくありがとうございます。「ただそういうサイトを目的外のこのような実験でつかってよいのか?という点では微妙かもですが」かなり”微妙”でしょう:-(