<前の日記(2010年04月25日) 次の日記(2010年04月28日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2094   昨日: 2485

2010年04月27日

まだまだ他でも破綻しているケータイID認証

前回の補足。以下は、私が気づいたことではなく、2009年夏に「かんたんログインが危うい」との話題で持ち切りだったときに、既に公に語られていたことである。

しかし、携帯電話会社がこの仕様について何ら公表していないせいで、「かんたんログイン」実装者らに周知されていないのではないかと危惧される。事実を検証の上、少なくとも避けなければならないことを以下に書いておく。

端末シリアル番号を認証に使ってはいけない

X-JPhone-UID: などの、キャリアのゲートウェイ(やProxyサーバ)で付与される契約者固有IDは、偽IDが送信されても、ゲートウェイが本物のIDに差し替えてサーバに渡す(オーバーライドする)ようになっているらしいが、User-Agent: 内に記載された端末シリアル番号(IMEI番号)のオーバーライドはなされていない。

画面キャプチャ 端末の写真
図1: 左: 偽の端末シリアル番号と偽の契約者固有IDを送信した*1ときの様子
右: 使用した端末のIMEI番号

図1のように、私の端末のIMEI番号は末尾3桁が「357」であるところ、最後を「8」に変えた「偽の」端末シリアル番号を User-Agent: に載せて送信したところ、Webサーバにその文字列がそのまま届いている。

(一方、私のSoftBankの契約者固有IDは末尾3文字が「Wc0」であるところ、「Wc1」に変えた「偽の」契約者固有IDを X-JPhone-UID: に載せて送信したところ、これは「Wc0」にオーバーライドされてサーバに届いている。)

そして、アクセス元のIPアドレスは、「Yahoo!ケータイにて利用するIPアドレス帯域」のものになっている。

したがって、端末シリアル番号を認証に使っているとなりすましログインされてしまう。端末シリアル番号を認証に使ってはいけない。

このように端末シリアル番号をオーバーライドしないのは、仕様なのだろう。なぜなら、X-JPhone-UID: はヘッダの値フィールド全体が値なので仕様が暗黙的に自明だが、User-Agent: の途中に埋め込まれた端末シリアル番号は、どの部分が当該IDなのかその仕様が明確に定義されていない。感覚的には「4つ目の『/』の次の文字から次の空白まで」なのだろうけども、仕様が明確に定義されなかったせいで、Webアプリケーション側の実装は、「『SN』で始まり次の空白の前までの文字列」など、それぞれ思い思いのテキトーなやりかたがされているだろう。そのため、いくら、偽の端末シリアル番号らしき文字列をオーバーライドしようとしても、すべてのWebアプリ実装に対応できるようなパターンマッチが不可能になっている。

ネットの評判を検索して見てまわると、比較的最近に発売されたSoftBankの機種では、この端末シリアル番号の送信がデフォルトでOFFに設定されているらしい。そのため「かんたんログイン」が動かないということで、この設定をONに変更するように促しているサイトがあるが、危険なので、端末シリアル番号での「かんたんログイン」をやめるべきだ。

デフォルトでOFFに変更したということは、ソフトバンクモバイルは、この問題を知っていて、使うのをやめさせる方向でデフォルトOFFにしたのではないのか。

どうしてソフトバンクモバイルはこの事実を周知しないのか。いまだに「ユーザエージェントについて」のページに「端末シリアル番号」の使い方が掲載されている。無責任極まりない。

SSL接続で得たX-JPhone-UIDを認証に使ってはいけない

sbwapproxy.softbank.ne.jp:8080 をProxyサーバとして、SSL接続で(直接の https:// アクセスで)WebサーバにHTTPリクエストを送信した場合、end-to-endのSSL接続なのだから、そのリクエストの内容がいかなる内容であれ、それがゲートウェイ(Proxyサーバ)で書き換えられることはない。

画面キャプチャ
図3: SSL接続で偽の契約者固有IDを送信した*2ときの様子

図3のように、私のSoftBankの契約者固有IDは末尾3文字が「Wc0」であるところ、それを「Wc1」に変えた「偽の」契約者固有IDを X-JPhone-UID: に載せて送信したところ、Webサーバにその文字列がそのまま届いている。

そして、アクセス元のIPアドレスは、「Yahoo!ケータイにて利用するIPアドレス帯域」のものになっている。

したがって、SSL接続で受信した X-JPhone-UID: の値を認証に使っていると、なりすましログインされてしまう。SSL接続で受信した X-JPhone-UID: の値を認証に使ってはいけない。

たとえそのつもりがなくても、結果的にそうなっている場合がありそうなので注意が必要。つまり、http:// のページしか提供していないつもりで、所定のIPアドレスから送られてきた X-JPhone-UID: の値を認証に使用しているときに、管理者の与り知らぬところで実はWebサーバが https:// でもアクセスできるようになっていて、同じWebアプリケーションプログラムにリクエストが渡るようになっている場合、https:// 経由でなりすましログインされてしまう。

これも仕様だろう。キャリア側ではどうしようもない。なぜ携帯電話会社はこの事実を周知しないのか。無責任極まりない。

同様に、ゲートウェイ付与型の契約者固有IDを提供しているdocomoの場合はどうなのか。これは私から言うことではない。NTTドコモが周知することだろう。

先日のサイボウズOfficeの件のように、パッケージ製品として「かんたんログイン」機能を提供する場合、これに該当するアクセスについて、https:// では動かないようにする必要がある。それを、製品購入者の責任で安全に設定せよというのはあまりにも無理な話すぎる。

そして他にも……

つづく。

*1 自分の管理下にあるサーバに対して送信。

*2 自分の管理下にあるサーバに対して送信。

本日のTrackBacks(全2件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20100427]

かんたんログインを提供しているサイト運営者の背筋を寒くするエントリ第2弾。例え、キャリアのGateway経由の場合、uidは正しい値に書き換えられる仕様なので安全だという今までの常識を覆されました。SoftBankで検証した結果、SSL通信の場合、上記書き換えは行われません..

検索

<前の日記(2010年04月25日) 次の日記(2010年04月28日)> 最新 編集

最近のタイトル

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|
<前の日記(2010年04月25日) 次の日記(2010年04月28日)> 最新 編集