8月11日の日記に書いた件がその後どうなったか確認してみた。
いくつかの図書館では、/robots.txt が修正されたことにより、検索サイトで正常に閲覧できるようになった。
以前は、8月11日の日記に書いたように、三菱電機ISの図書館システム採用の図書館の多くが、/robots.txt によってすべてのクローラを排除していたため、図1の「ビフォー」のように異常な検索結果になっていた。
なぜそんな設定をしていたのかは、このシステムでは以前からアクセス障害が発生していたためであり、朝日新聞が次のように伝えている。
MDISは06年、不具合を解消した新ソフトを開発。東京都渋谷区など全国約45カ所に納入した。しかし、一部では旧ソフトが更新されずに使われ続け、広島県府中市で08年末、石川県加賀市で09年夏、大阪府貝塚市で09年末に閲覧障害が起きた。
岡崎の図書館では、今年3月に閲覧できなくなった。取材によると、MDISMは直後にアクセス記録から原因を把握していたが、図書館側に他の図書館で同じような閲覧障害が起きていたことを伝えていなかった。
このうち、大阪府貝塚市のケースについては、取材した神田記者がTwitterで次のように補足している。
続いて、昨日ご質問をいただいた他図書館の状況について。まずは記録のしっかり残っている大阪・貝塚市についてです。市によると、図書館には数年前からホームページが閲覧できない、画面が表示されないといった苦情が利用者から寄せられていました。*
ところが09年12月初旬になると、「ホームページを表示しない」「検索の結果が出ない」「貸し出し記録が表示されない」といった苦情がかなり頻繁に寄せられるようになったそうです。*
図書館の話では、MDISは「ロボットが入った検索がセッションをつかんで離さない状態になっている」と説明し、「3分間程度つかんで離さなくなったら自動的に再起動」することにしたそうです。具体的にどんな対策なのかはわかりません。*
MDISはその後、2010年1月にかけて、断続的にいくつかの措置を取っています。同年2月5日付けのMDISから図書館への報告書に、その内容が明記されています。それによると、とられた対策は(1)「利用者からの同時接続数の制限と接続タイムアウトの調整」、*
(2)「クローラー対策 クローラー閲覧抑止対応の強化(新着案内に追加)」、(3)「インターネットサービス監視ツールの設定変更 監視対象のコンテンツ画面を変更しました」となっています。 *
貝塚市とMDISの説明では、一つはrobots.txtを置き、METAタグを改良したこと。もう一つはウェブサーバーへの「同時アクセス数」を制限したことだそうです。データベース接続数ではありません。 *
ここでの「同時アクセス数」とは、一度に貝塚図書館のホームページにアクセスできる利用者の数のことです。これを100に絞ったそうで、つまり100人までしか同時にはアクセスできなくなりました*1。しかし、これはDDoS攻撃などには効果がありますが、*
クローラー対策にはなりません。クローラーは一人の利用者でしかないからです。その点についても取材で問い合わせましたが、MDISは「様子見をするための対策だった」としています。もう一点、貝塚はこのときにセッションタイムアウトの時間を300秒に設定しています。*(略)
他の図書館に関しては、時期が古いことや図書館側に資料が残っていない(すぐ出てこない)こともあり、そこまで詳細はわかっていません。石川県加賀市の場合、09年夏ごろ、ホームページが閲覧できなくなったり、本の検索ができなくなったりしました。*
MDISからの指示で、加賀市は閲覧障害時に再起動をかけるようになりました。MDISからは「激しいユーザーがいるのでアクセスに制限をかける」という報告があったそうです。その後状況は改善されましたが、今でも閲覧障害が起きることはあるとか。*
あとは、広島県府中市。こちらは08年の12月に閲覧障害があり、MDISが「海外からの不正アクセスでサーバーが圧迫されている」という趣旨の報告があったそうです。取られた処置については詳細不明です。*
三菱電機IS(MDIS)は、/robots.txt の内容に「Googlebot」などを明示して排除しており、通常の検索エンジンのWebクローラを排除していた。
これは明らかに普通でないわけだが、今月になっても三菱電機ISは、日経コンピュータの取材に対して、次のように見解を示している。
Web蔵書検索システムをダウンさせたとして、悪意のない利用者が5月に逮捕された愛知県岡崎市立中央図書館をめぐり、新たな個人情報流出事件が発生した。同図書館は、三菱電機インフォメーションシステムズ(MDIS)の図書館向けパッケージ「MELIL(メリル)/CS」を採用する。MDISは(略)
MDISは本誌の問い合わせに、「個人情報の流出については、ライブラリ管理などに不十分な点があった」(広報)と責任を認める。一方で、処理性能については「2005年に想定した処理のピークに耐えられるように、設計・構築した。製品に欠陥があるとは考えていない」(同)と回答する。
別のところの話として、私が入手した情報でも、三菱電機ISは(10月の時点でも)次のように説明しているらしい。
5年前に納入したシステムであり、順調に稼働していた。それが今年の3月に、一部大量アクセスがあった。インターネットは日々進化しているもの。進化している現在において、古いシステムと不整合があったと認識している。図書館様とご相談して、現在のインターネット環境でも一般の利用者に快適にお使いいただけるよう、強化対策をした。
ところで、いくつかの図書館では /robots.txt が修正されたが、三菱電機ISのシステムが使われているすべての図書館で修正されたかというと、そうでもない。8月11日の日記で列挙したうち、以下の図書館が、いまだに /robots.txt で全クローラーを拒否している。
たとえば八幡市民図書館は、今も以下の図のように検索サイトで正常に表示されない。
/robots.txt の件は、8月25日の時点で朝日新聞が次のように伝えていた。
愛知県の図書館でホームページへの接続がサイバー攻撃のように見える不具合があった問題で、図書館のソフトを開発した会社が接続の集中を緩和させるため、一部の接続を排除し、国会図書館の情報収集ができなくなっていたことが分かった。国会図書館は法律に基づき、自治体などが提供するインターネット情報を集めている。(略)
国会図書館は取材に「自動収集の受け入れは法律上の義務で、例外はない。法に基づいて是正を依頼する」とコメント。岡崎市立図書館は「問題を把握しておらず、MDISに確認し、対応を検討したい」と話し、MDISは「各図書館に問題を報告し、対応したい」としている。
図書館ソフト不具合 接続障害の対抗策 国会図書館も排除, 朝日新聞名古屋本社版2010年8月25日朝刊25面
三菱電機ISは「各図書館に問題を報告し、対応したい」としていたようだが、その約束は果たされていない。
9月10日に、複数の図書館に私が電話取材したところ、「三菱電機ISからその件についての説明は来ていない」という話だった。その後、/robots.txt が修正されたので、図書館側から要求のあったところだけが対応されているのではないか。8月11日の日記の追記に書いているように、岡崎市でさえ、/robots.txt が修正されたのは9月10日のことだった。
ところで、この国立国会図書館法に違反しているという件、どういうわけか「違法じゃない」と独自見解を表明する人が少なからずいた*2ので、解説しておきたい。
違法じゃないと主張する人は、国立国会図書館法には例外規定があって「ネット以外での国会図書館からの資料請求に応じていれば免除される」などと言うのだが、国立国会図書館法第25条の3第2項の例外規定というのは、
の部分であり、その「館長の定めるもの」というのは、「国立国会図書館法によるインターネット資料の記録に関する規程」の第1条で定められていて、次の2つのケースである。
これらがどういうケースなのか、国立国会図書館の担当部署(電子図書館課ネットワーク情報第二係)に9月7日に電話で尋ねたところ、前者は要するに電子申請システム等のことを指しており、後者は要するにstaticなページのことを指しているとのことだった。
違法じゃないと主張する人が言う「ネット以外での国会図書館からの資料請求」というのがどこから出てきたかというのは、おそらく、国立国会図書館法第25条の3の第3項の以下の文からの連想だろう。
第二十五条の三
3 館長は、第二十四条及び第二十四条の二に規定する者に対し、当該者が公衆に利用可能とし、又は当該者がインターネットを通じて提供する役務により公衆に利用可能とされたインターネット資料のうち、第一項の目的を達成するため特に必要があるものとして館長が定めるものに該当するものについて、国立国会図書館に提供するよう求めることができる。この場合において、当該者は、正当な理由がある場合を除き、その求めに応じなければならない。
これは、第2項に加えて課せられる義務であって、この義務があるからといって「第2項の義務が免除される」という発想がそもそもおかしいのだが、この第3項の「館長が定めるものに該当するもの」というのは、平成22年国立国会図書館告示第一号「国立国会図書館法第二十五条の三第三項のインターネット資料等に関する件」の1で、次のように規定されている。
1 国立国会図書館法(略)第二十五条の三第三項のインターネット資料は、次の各号に掲げる出版物と同等の内容を有するものであって、国立国会図書館の館長が自動収集プログラム(略)によっては法第二十五条の三第一項の記録を行うことができないものをいう。
この、「自動収集プログラムでは記録ができない」というのが何を指しているのかについては、9月7日に国立国会図書館から説明を受けた。それによると、次などのケースを指しているとのことだった。
つまり、国会図書館の自動収集プログラムの技術的な都合で収集できないものについては、別の手段での提供を求めることがあって、それに応じる義務があるというのが、第25条の3第3項の意味であり、/robots.txtで拒否というサイト側の都合によって、第2項の義務が免除されるなどということはない。このことは、国立国会図書館電子図書館課ネットワーク情報第二係の担当者に、電話でしっかりと確認した。
8月11日の日記に書いた、国会図書館の説明スライドがわかりにくくて誤解を招くとした件も、9月に修正されて新しい版が公開されている。
これで誤解なく周知されることだろう。その他にも、以下などでこの件は周知されていたそうだ。
収集方法は,主として収集用プログラム(クローラー)による自動収集を想定している。対象となる機関は,NDLによる自動収集を妨げるような設定を行っている場合には,それを許可する設定に変更する義務を負う。具体的には,サイトに置かれているrobots.txtファイルの変更が想定されている。
一旦は「各図書館に問題を報告し、対応したい」とした三菱電機ISだったが、2か月経った今も違法状態が解消されていない図書館があるというのは、もしや三菱電機IS内に「あれは義務じゃない」と主張している人でもいるのだろうか。
ガラケーからiPhoneに乗り換えた人々が「ガラケーサイトが見れない!!」とご不満らしいという話は、聞いたことがあったし、そういう方々向けに「ガラケーサイトを閲覧できる」と謳うスマホ用の専用ソフトが提供されたというのも、どこかで見た記憶があった。
そんな10月9日の夜遅く、ある方から、「iPhone用のSBrowserというアプリで、クロネコヤマトのサイトを使ったら、知らない人の個人情報が出てきてびっくりした。どうしたらいいか」という相談が舞い込んできた。
早速、iTunes Appストアで「SBrowser」の商品説明ページを見に行ったところ、数々の雑言レビューが付いており(図1)、この種のアプリの需要とユーザ層が見えた。
このアプリの機能説明を見ると、「携帯サイトのテストにどうぞ」(図2)と冒頭で書かれているが、実際の利用者層は(レビューの内容からすると)どうもそういう人々ばかりではなさそうだった。
そして、最近のバージョンの新機能として「個体識別情報をランダムに自動設定できます」と書かれているのを見て、何が起こったのか、すぐにピンときた。
通報を頂いた方には、その設定のまま使い続けるのは中止するようアドバイスするとともに、設定画面のキャプチャを撮って送ってくださいとお願いした。送られてきた設定画面は、図3(左)のもの*1であった。
私もSBrowserを購入して、設定画面に行き、「ランダム設定」ボタンを押したところ、上の図3(右)のように、「識別番号」と「ユーザID」が設定された。両者を見比べると、同じ値になっていることがわかる。*2
ちなみに、この部分は、SBrowserの初期状態では以下の図4のように空欄になっている。
「ランダム設定」ボタンを何回か押すと、押す毎に別のランダムっぽいIDが生成されるけれども、プログラマならすぐに予想がつくように、電源を切って入れなおして、SBrowserを起動して最初に「ランダム設定」ボタンを押したときの結果は、必ず図3と同じ値になるという挙動を示した。
「ランダム設定」ボタンをもう一度押したとき(つまり電源を入れ直した後に2回に押したとき)に設定される値は必ず「E33F9A……」という値になるし、その次の値も必ず「B441E2……」という値になる。まあ、コンピュータの「ランダム」というのは基本はそういうもの(擬似乱数)だ。*3
この値が、HTTPリクエストの「X-JPhone-UID:」ヘッダに載せられて送信されるようになっているわけで、この値だけで「かんたんログイン」ができるサイトがあるならば、そもそもそのサイトに脆弱性があるということになる。それだけなら新しい話ではなかった。
しかし今回、意図した攻撃ではなく、不意に他人の情報が見えてしまう事故が発生したのは、SBrowser利用者の何割かが、「ランダム設定」ボタンをちょうど1回押した状態の設定で使用していて、かつ、謳われている「携帯サイトのテスト」用途ではなく、実用としてガラケーサイトで使っていたためだろう。
そうした人々が、同じガラケーサイトを使うと事故は起きる。つまり、Aさんが上記の設定でガラケーサイトで(パスワードで)ログインした後、Bさんが、同じ設定で同じガラケーサイトで、かんたんログインのボタンを押すと、Aさんとしてログインしてしまう事故が発生する。
今回事故が起きたのは「クロネコメンバーズ」というサービスで、携帯サイトは http://9625.jp/ にあり、PCから一般のインターネット回線でアクセスしても、普通に閲覧することができた(今もできる)(図5)。
そこで、「クロネコメンバーズ」に自分のアカウントを作成して、テストを行った。
テストでは、図3のIDを使用しないよう注意し、自分のSoftBank携帯のX-JPhone-UID:の値を手入力で設定(図6左)した。そして、自分のSoftBank携帯で「クロネコメンバーズ」携帯サイトに(クロネコIDとパスワードで)ログインし(図6中央、右)、「クイックログイン」ができる状態にした。
この状態で、iPod touch上のSBrowserで「クイックログイン」ボタンを押したところ、(SoftBank携帯で設定したはずの)私のアカウントにログインすることができた(図7)。
この状態で、「お客様情報の参照」のページに進んだところ、図8のように、登録していた個人情報が表示された。
報告書を書くにあたっては、「SBrowserの問題」と勘違いされないように、SBrowserを使わないテスト方法の画面を使用した。図9は、Firefoxでテストする様子を示した画面である。
報告書には、これらの脆弱性を示す証拠の他に、今回は、実際に事故が発生した事実を書き、SBrowserの挙動についても書いた。以下はその部分からの抜粋(図は省略)である。
「クロネコメンバーズ」携帯サイトにおける「クイックログイン」のセキュリティ欠陥について
携帯電話向けWebアプリケーションの「簡単ログイン」方式の危険性について調査する過程で、「クロネコメンバーズ」の「クイックログイン」機能を調べたところ、何ら、なりすまし対策がなされておらず、どこのIPアドレスからでもいつでも誰にでもなりすまして不正ログインされてしまう欠陥があることに気づきましたので、以下の通りお知らせします。
1.「クロネコメンバーズ」 の「クイックログイン」機能の挙動
(略)
2. セキュリティ上の問題点
(略)
3. 生じ得る被害
(略)
4. 事故による実際の被害の発生
10月9日に、ある個人の方から私のところへ、意図せず他人の個人情報を閲覧してしまったとの報告がありました。その方は、iPhoneで「SBrowser」というアプリ(図3左)を用いて、「クロネコメンバーズ」にアクセスしたそうです。
その際、「SBrowser」に契約者固有ID(ユーザID)を自由に設定して送信する機能があり、このIDを「SBrowser」の機能「ランダム設定」(図3右)によって設定したとのことです。
この「ランダム設定」は、タップする毎に異なる「ユーザID」を生成するようになっているものの、iPhoneの電源を入れた直後に「ランダム設定」をタップしたとき(つまり初回の乱数値)は、常に同じ値となるようです。図3の画面はその値を示しています。
このことから、次のシナリオによって事故が生じたと考えられます。過去に別の誰かが「SBrowser」を用いて「クロネコメンバーズ」に「クイックログイン」した際に、このユーザID「76931FAC……」が登録されたと考えられます。その後、別の方(事故の通報者の方)が「SBrowser」を用いて同様に「ランダム設定」をしたところ、同一のユーザID「76931FAC……」が設定され、それを用いて「クロネコメンバーズ」に「クイックログイン」したときに、前者の方のアカウントでログインした状態になったと考えられます。
意図せずその方法でログインしてしまったという通報者の方は、ログイン後の画面に、他人の名前が表示されたことから、驚いて「お客様情報参照」のページへ確認に行ったところ、他人のメールアドレスや住所が表示されたとのことです。
私は、このユーザID「76931FAC……」を用いた再現実験は行っていません。同様の事態を確認するため、自分のソフトバンク携帯電話の契約者固有IDを「SBrowser」にセットして、「クロネコメンバーズ」にアクセスしたところ、図4のように、自分の個人情報が表示されました。
これは、「SBrowser」に問題があるために起きたのではない点にご注意ください。仮に「SBrowser」が存在しなかったとしても、前記の第2節で述べたように、「クロネコメンバーズ」の携帯サイトは、 他人の携帯電話の契約者固有IDを用いて、一般のインターネット回線からPC等によってなりすましログインができてしまう状態にあり、問題の原因は、「クロネコメンバーズ」サイト側にあります。
5. ご参考
こうした欠陥は、これまでにいくつものサイトで存在が確認されており、何度も指摘されているところです。詳しくは以下のWebページをご覧ください。
- はてなのかんたんログインがオッピロゲだった件, 2010年2月21日
http://takagi-hiromitsu.jp/diary/20100221.html- ユニークIDがあれば認証ができるという幻想, 2010年4月11日
http://takagi-hiromitsu.jp/diary/20100411.html- ここまで破綻しているケータイID認証(簡単ログイン), 2010年4月25日
http://takagi-hiromitsu.jp/diary/20100425.html- 今こそケータイID問題の解決に向けて, 2010年6月19日
http://takagi-hiromitsu.jp/diary/20100619.html以上
この報告書を、12日の朝にヤマト運輸に送付し、夕方には「関係部署にて検証し、問題のある箇所については善処」という返事をもらった。同じ日に、IPAの脆弱性届出窓口にも届け出た。今回はいつもと違って、現に事故が起きているので、即座に対応されるかなと予想したが、そうでもなかったのは意外だった。
また、今回は現に事故が起きているので、報道機関にも通報した。ここ数年、白浜シンポジウムや越後湯沢ワークショップでしばしばお目にかかる読売新聞の方々にお伝えした。
その後いつ何があったのか、10月19日になって、「クイックログイン」機能が一時サービス停止になった(図10)。
そして、10月25日、読売新聞朝刊の社会面で報道された。
通報してくださった方、ご本人のブログでも、経緯が公表された。
そして、他のメディアからも続報が相次いだ。
ヤマト運輸からは、以下の告知が発表された。
2. 影響範囲
過去のデータを確認することで上記アプリケーションの影響調査は完了しており、1名のお客様が、2名のお客様からログインされたことが確認できました。該当のお客様については個別に対応いたしております。
「1名のお客様が、2名のお客様からログインされた」とのこと。私は図3のIDでのログインをしていないので、今回の通報者の方の他にも(意図せずに)同じように「クイックログイン」で他人のアカウントに入ってしまった事例があったということと思われる。気づかなかった可能性もあるし、びっくりしてスルーということもあるだろう。
類似の話として、携帯サイトで他人の情報が出たという事故は、これまでにも何度か起きており、事故が起きるとサイト運営者が事実関係を発表することが多いのか、ちゃんと表沙汰になっている。
ピーチ・ジョン側が問題に気付いたのは2月5日。ユーザーから「自分のものではなく他の顧客の履歴画面が表示されてしまう」という問い合わせがあって問題が発覚した。同社では2月5日に、au/Vodafone向け携帯サイトの機能向上のため、プログラム修正を行ったが、その中に不具合があったことが原因だという。(略)
本年6月22日20時37分から23日18時45分までの間、特定のリンク元サイトから「au Books」にアクセスしたお客様に対し、同じ時間帯にアクセスした他のお客様の登録情報 (氏名、住所、電話番号、生年月日、会員パスワード) が表示され、場合によっては、自分の情報が他のお客様の情報に書き換わってしまう事象が発生しました。(略)
2009年2月15日(日)18:00〜2月17日(火)10:00の期間、ページ内のリンクをクリックした時に、本来であれば移動しなければならないリンク先のページと異なるページへ遷移してしまうシステムの誤作動が発生いたしました。 その誤作動の中で、一部会員の方がマイページにログインした際、他の会員のマイページが誤って表示されるという不具合が発生し、他の会員のメールアドレスが閲覧できる状況が発生しておりました。(略)
■一休、携帯サイトで他人の予約情報が閲覧可能に
(略)は7月28日、7月7日午前0時から12日午後5時30分までの間、一休.com携帯サイトで他の顧客の氏名、住所、電話番号、メールアドレスを含む予約情報が閲覧可能となっていたと発表した。該当者は122名。NTTドコモの「iMENU」で検索を行い、検索結果から一休.comにログインして予約関連の操作を行った場合、アクセス後30分以内にiメニューサイト検索結果を経由して「Myページ」にアクセスした他の顧客から情報が閲覧可能となっていた。
・お客様情報の取扱いに関するお詫びとご報告[PDF](一休)
http://www.c-direct.ne.jp/public/japanese/uj/pdf/10102450/20100728187820.pdf■オーガスタファミリークラブ、他の顧客情報が閲覧可能に
(略)は7月21日、通販システムの不具合により、7月9日午後9時〜翌午前0時、または7月10日午後4時〜7月11日正午までに同サイトへ携帯電話でアクセスして注文情報確認画面表示を行った顧客の一部について、住所、氏名、電話番号、メールアドレス、クレジットカード情報が他の顧客から閲覧可能になっていたと発表した。同社によると、アクセス中の顧客を識別する管理情報が正常に発行されないケースがあり、別の顧客の個人情報が携帯電話の画面に一時表示される状態となっていた。
・【オーガスタファミリークラブ】個人情報流出のご報告とお詫び(オーガスタファミリークラブ)
https://www.augfc.net/webshop/apologize.html
これらは、今回のものとは原因が異なる。セッションIDをURLに載せている方式がひき起す障害(リバースプロキシにキャッシュされてしまう障害、あるいはsession fixation脆弱性による障害(2007年6月29日の日記)等)や、レースコンディションのバグが原因のものだろう。
今回の件が従来の事故と異なるのは、従来の事故は、意図してひき起そうとしてもそう簡単にはできない(偶然によって他人の個人情報が画面に出る)ものがほとんどだった思われるのに対し、今回のものは、犯意を持ってすれば任意のユーザの情報を引き出せてしまうという、致命的な脆弱性がある上での偶然の事故であった。その意味で従来の事故よりも深刻度が高いと言える。
今回の読売新聞の記事には、SBrowserの「ランダム設定」について、次の記述がある。
エスブラウザの販売元「さいこち」(大阪府)では、「本来、携帯サイトの開発者がアイフォーンを使ってサイトの機能を検証するためのソフトで、今回は想定外の使われ方だ」としているが、エスブラウザは既に約2万5000本を販売。実際には、多くの一般の利用者が携帯サイトを見るために購入しているとみられ、同社では今後、同じID番号を提供しないような対策をとるという。
この対策というのは、おそらく、疑似乱数生成器のseedを時刻などから決定するように変更という話(あるいは暗号論的擬似乱数生成器に変更)だろうと思うが、それで解決なのだろうか。
そもそも、テスト用途であるなら、その対策は無用である。テスト用途でなく、実用を認めるのでれば、その場合のID送信機能は、何のためのものなのか?
もし「かんたんログイン」を使うためだというのなら、そもそも、それはサイト側の致命的な脆弱性があるということであり、それを前提とした用途を提供するというのは不適切である。
それ以外に必要性があるのか。あるとすれば、ガラケーサイトが、ガラケー以外からアクセスされたときにPCサイトへジャンプさせる仕掛けを講じる際に、ガラケーか否かの判定に、User-Agent:だけでなくX-JPhone-UID:などのケータイID(契約者固有IDや端末固有ID)の有無を拠り所にしている場合に、そのガラケーサイトをスマホで閲覧する目的で、だろうか。
そのときに、「ランダム設定」の乱数をちゃんとすることは何の意味があるのか。何らかの事故の可能性に配慮して、他人と衝突しないようにということか。であるならば、衝突しないと言えるだけの、IDの長さが必要であろう。図3のIDは64ビットなので、微妙なところだ。最低でも80ビットは欲しいところであり、ちなみにUUID Version 4では、256ビットになっている。
しかし、IDを長くすると、上記の目的で使えなくなる可能性もある。docomoの場合、iモードIDは長さが固定長で規定されており、7文字の英数字とされている。Webサイト側が、iモードIDを取得する際に、「7文字の英数字」という形式のチェックをしているならば、上記の目的(iモードIDの有無をチェックしているガラケーサイトのスマホでの閲覧)をするには、この形式に沿ったIDを「ランダム設定」する必要に迫られるだろう。
7文字の英数字というのは、(26*2+10)^7 = 3,521,614,606,208 で、42ビットしかない。乱数で設定していると、偶然に他人のIDに一致してしまう確率は、無視できないほどに大きい。それどころか、docomoの本物の利用者のiモードIDに当たってしまう確率も無視できない。
docomoの利用者が5000万人で、1人が2つくらいのIDを消費すると仮定して、約1億個のiモードIDが実在するとする。7文字の英数字のID空間は、上記の通り3兆5千億なので、3万5千倍の余裕しかない。SBrowserの販売数が2万5000本というのだから、全員がそのような利用をしたとすれば、誰かが他人のIDと同じになってしまうことは十分にあり得る。*4
ということは、上記の目的の利用(ケータイIDの有無をチェックしているガラケーサイトのスマホでの閲覧)は広めてはいけないということになる。
結局、SBrowserは、テスト用であることを十分に告知した上で、利用者の責任でもってIDを入力するようにするほかないのではないか。
一方、SBrowserの作者の方のご認識は、事態発覚時のTwitterでの発言から推察できる。(以下は、10月19日のもの。)
お知らせ:SBrowserによる個体識別番号の衝突が原因の可能性がある個人情報流出の報告を受けています。重ねてご案内致しますが、個体識別番号を送出する設定で他者のサイトにアクセスを行なわない様お願い致します。*
Aさんが番号NNNNに設定してサイトXに登録。Bさんが同じく番号NNNNに設定してサイトXにアクセス。結果、BさんがAさんのサイトXに対する登録情報を見えてしまうケース。*
自社プロダクトが火種になった事はとても遺憾ではあるけれども、今回の件を鑑みて「携帯の識別番号だけで簡単ログイン」という機能が滅びてくれると嬉しい。*
むしろ、「識別番号だけのログインは非常に危険」と常々言っていた自分としては逆に悲願として喜ぶべきか。*
しかし、ランダム設定が正しく動作していないというバグを仕込んだ自分としては痛恨の極み。*
@sonk んと、公式サイト等であればキャリアのネットワーク網からアクセスされる事をキャリア側の責任で担保できてたと思うのですが、それならば簡単ログイン大いに結構なんです。*
@sonk ただ、勝手サイトではキャリアの公開するネットワーク帯域を常に確認しながらアクセス制御を行なう事が最低限必要であり、それすら行なっていない場合には簡単ログインはセキュリティホール以外の何者でもないのです。*
@sonk で、さらにキャリアの公開しているネットワーク帯域の情報もそれが必要十分であるかの担保が無いので、安全側に倒すならばその情報を信用しない事が必要であると考えてます。*
@sonk 要はIPアドレスの制御を組み込んでいるにせよ簡単ログインなんて脆弱な物を使うな!ということですw*
@sonk 乱れうち申し訳ないw このあたりを140文字で説明できないんですよねー。何年も前から言われてる事ですし、最近はcookieを喰える端末も増えてきたのでいい加減に他の方法に移行すべきと思ってるのですがなかなか難しいですね。*
@sonk 自分が直接関わるプロジェクトでは絶対に導入しないように説得してますw 違法コピーのアプリを使用するのと同様、とまで言うと言い過ぎなんですがユーザーを保護する為に脆弱性は埋め込んじゃ駄目!って。*
単純に、「ランダム設定」の固定seedはプログラムとしてバグであるということで、修正ということなのだろうとは思う。
一方で、テスト用と謳っているのだから勝手に実用に使うIT弱者が悪いのだと言えるのかどうか。iPhoneは、冒頭で紹介したレビューにあるように、ごく普通の携帯電話と同じ感覚で使われているものであるし、iTunes Appストアも一定の安心感を持って使われているため、提供するアプリの使われ方を限定しようとしても、実用に使いたいという需要の勢いがある限り、無理があると思う。SBrowserを紹介して「iPhone 3Gでケータイサイト見たいんです!」などという記事も出ていた。
このことは、iPhoneだけの話ではない。他のスマホであるAndroidケータイにおいても、同様の動きがあるようだ。Androidには「Galapagos Browser」というアプリがあるようで、「端末ID送信」機能があるとされている。
主に以下のような機能を搭載しております。
・携帯シミュレーター機能(UserAgent変更、端末ID送信)
(略)
iモードに対応しているようで、「端末ID送信」機能がどうなっているのかが問題となる。私はまだAndroid端末を持っておらず確認できないので、ググってみたところ、以下の掲示板に情報があった。
当方、仕事の連絡を携帯サイトにログインして行っており、この操作が必須なのです。
これまでの口コミで「galapagos blowser」というアプリで携帯サイトはみれるのはわかりましたが、固体識別番号登録と、ログイン時に携帯電話製造番号通知でログイン制限もしているのです。このアプリで
携帯電話製造番号通知と
固体識別番号の判別は
おこなえるのでしょうか?
当方ちなみにドコモユーザーです2010/10/13 21:16 [12055283]
ガラパゴスブラウザが送出する識別子を確認してみました(略)
・送信されていたUserAgentと個体識別子
DoCoMo/2.0 N905i(c100;TB;W24H16;serXXXXXXXXXXXXXXX;iccxxxxxxxxxxxxxxxxxxxx)UserAgentはN905iとして偽装
ser = FOMA端末個体識別子 = FOMA端末製造番号
icc = FOMA端末個体識別子 = FOMAカード製造番号 です"ser"部分(FOMA端末製造番号)、"icc"部分(FOMAカード製造番号)は、
iモード端末では数字のみでできた製造番号が送信されるのですが、
ガラパゴスブラウザではランダム風な半角英数字が送信されます
このランダム風な疑似識別子をどうやって決めているかは不明です
(略)2010/10/14 00:11 [12056471]
こういう利用形態が広まって、こういうことができて当たり前であるかのような認識が一般ユーザに広がっていくと、元に戻れなくなって、さらには、Webサイト運営者側で、こういう利用のためにIPアドレス制限をあえて外すという、愚かな措置をとる(新たに脆弱性を生み出す)ところさえ出てきかねない。そして、今回同様の事故が再び起きるだろう。
どうすればよいか。最も効果的な方法は、「かんたんログイン」というUI自体を撲滅して、愚かなサイト運営者に真似をさせないことである。そもそも(docomoの「utn」が要らなくなった)今日では「かんたんログイン」というUIは無用の長物である。
そして、ケータイIDを使わず、cookieを使うよう、一般のPCと同じ技術でWebアプリを構成するようにすればよい。それだけの話であって、いまさら議論する余地などない。
関連:
*1 画面左上に「SoftBank」でなく「Apple」と出ているのは、過去にjailbreakしたことのある端末からデータを引き継いだための名残で、この端末がjailbreakされているわけではないとのこと。
*2 左の設定画面と右の設定画面で「識別番号」と「ユーザID」が逆になっているのは、SBrowserのバグ。おそらくは右の画面の方が正しい。
*3 seedと呼ばれる初期値を、何らかの乱数で決めればこうはならないわけだが、時刻などから生成している限り、あまり根本的な解決にはならない。重複しないことを期待するならば、暗号論的擬似乱数生成器を用いるべき(iOSのAPIにもあるはず)だが、そもそも生成するIDの長さが、重複しないことを期待するにはやや短い。
*4 2万5千人のユーザのうちの誰一人実在iモードIDに一致しない確率は、(1-(1/35000))^25000 = 0.49 なので、約1/2の確率でそういう事態が起きる計算。
以前、NIKKEI NETに書かせて頂いていたコラムが、6月ごろから消失していたので、日経新聞社の承諾を得て転載しました。
レイアウトは後日調整予定。