最新 追記

高木浩光@自宅の日記

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

2010年02月06日

Winnyネットワーク観測クローラの接続成功率が低下

2月1日ごろより、Winnyの観測クローラの接続成功率*1が慢性的に低下する現象が発生し、現在も続いている(図1)。観測されたノード数が微増しているが、この微増が、実際に利用者が増えたことによるものか、架空ノードによるものかは現時点では判明していない。

グラフ
図1: 上から順に、観測クローラ接続成功率(右軸目盛り)、
キーから得た過去24時間のノード数(左軸目盛り)、
その補正値(1回しか現れなかったものを除去)、
クローラの巡回あたりのノード数(左軸目盛り)

接続成功率の低下は、過去にも、ランダムIPアドレスの偽キーが散布されていた時期に起きている(図2)。

グラフ
図2: 過去の接続成功率と観測ノード数

現在の観測ノード数は以下の通り。

グラフ
図3: 現在の観測ノード数

*1 前の巡回で収集されたノードリストに基づいて、各ノードに1回ずつ接続を試みたときの、接続が成功した割合。前回の日記で参照した、中央大学のクローラで接続失敗率が上昇した(成功率が減少した)現象がこちらでは起きていないのは、私のところの新型クローラ(2009年4月末以降使用)では、受信した隣接ノード情報を使用せず、受信したキーのみを元にアクセス先ノードリストを作成しているため、大阪市立大学の実験の影響を受けなかったことによるもの。


2010年02月13日

なぜGoogleストリートビューカメラ問題は嘘がまかりとおるのか

先月、日本弁護士連合会(日弁連)が、ストリートビューに関する意見書を発表しており、これについての記者会見が先日あったようで、ちらほら報道があった。

  • 多数の人物・家屋等を映し出すインターネット上の地図検索 システムに関する意見書, 日本弁護士連合会, 2010年1月22日

    第1 意見の趣旨

    1 (略)行政機関から独立した第三者機関によるプライバシー影響評価手続を経ることがない現状において,新たな地域への拡大は控えられるべきである。すでに公開されている地域においては,当該自治体の個人情報保護審議会において,下記の2(2)と同様の事後調査がなされるべきであり,その判断は尊重されるべきである。

    2 個人情報保護法,個人情報保護条例において,以下の改正がなされるべきであり,その改正までの間も,以下の運用改善がなされるべきである。

    (1) プライバシー保護の状況を調査監督し,プライバシー侵害のおそれのある行為については,当該行為者に対して是正勧告ができる,行政機関から独立性を持った第三者機関を設置すること。

    (2) 地図検索システムと連動させ,公表することを前提として,公道などの公共の場所において一定数以上の多数の人物の肖像や家屋等を網羅的に撮影しようとする者は,事前に第三者機関の意見を求めることとし,このような申請を受けた第三者機関は,プライバシー影響評価手続を実施し,肖像権・プライバシー権の制約の程度よりも,撮影・公表行為の必要性・社会的有用性の方が大きいかどうかについて事前に調査すること。

    (3) 第三者機関が設置されるまでの間,国が設置する消費者委員会や,地方自治体が設置する個人情報保護審議会等において,本件について対処すること。

    第2 意見の理由

    (略)

これについてどんな反応が出ているだろうかと、Twitter検索してみたところ、あまり反応がないなかで、以下の発言が目立っていた。

これは、密室でコントロールしたいということだろうか。

今回の日弁連の意見書の内容が、「開かれた公正な機関と手続きによってプライバシー影響評価を行うべき」という趣旨のものであるところ、それを真っ向から否定して、「日弁連に適うようコントロールするのが政策面でも有効」という。

この発言には続きがあり、

という。なるほど、たしかに、日弁連コンピュータ委員会が2008年の段階でグーグル株式会社に対して聴き取り調査をしたというのは、私もあるルートから耳にしていた。

しかし、日弁連コンピュータ委員会は、その聞き取り調査の結果を公表していないし、聞き取り調査を行った事実さえ表沙汰にしていない。やむを得ず内容を公表できない理由があったなら、その理由を公表すればよいはずなのに、それができないのだろうか。

「削除要請の対応状況とか……ちゃんと聞かないと」と言うけれども、実態を把握するうえで最も重要な、削除要請の件数と削除した件数、これさえいまだに明らかにされていないわけだけども、コンピュータ委員会では、それを内々に把握して問題なしと判断したというのだろうか。日弁連コンピュータ委員会が判断すれば国民に知らせる必要はないと?

続いて、もうひとつ似たような発言があった。

ハァ? 解像度を下げた? そんな発表はされていないし、私の見た限りでも解像度は下げられていない。

それどころか、以下の写真にあるように、昨年5月以降の新たな撮影では、欧州で使用されたのと同型のカメラで、これまでより数段高い解像度の写真が撮影されている*1。近々、このカメラで撮影された写真が掲載され始めるわけだが、どんな写真になるのかも公表されていない。

画面キャプチャ
この車にピンときたら・・・・・・, 王子印刷ブログ, 2009年9月17日

「グーグルは総務省の要請を受けて解像度を下げた」と、いったいどういう人が言っているのかとよく見ると、その総務省の「利用者視点を踏まえたICTサービスに係る諸問題に関する研究会」の第一次提言で、ストリートビュー関係をとりまとめた「インターネット地図情報サービスWG」主査の森亮二弁護士だった。*2

インターネット地図情報サービスWG 構成員一覧

主査 森 亮二 英知法律事務所 弁護士
主査代理 上沼 紫野 虎ノ門南法律事務所 弁護士
構成員 石井 夏生利 情報セキュリティ大学院大学准教授
構成員 藤田 一夫 グーグル株式会社 ポリシーカウンシル
構成員 楠 正憲 マイクロソフト株式会社
構成員 島本 学 NTTレゾナント株式会社 企画部法務考査部門長
構成員 中川 譲 一般社団法人インターネットユーザー協会 理事

ということは、この新型カメラで撮影された写真は、解像度を下げて掲載することが秘密裏に約束されているのだろうか?

そういう約束を取り付けることができたとすれば、それは功績だと思うけれども、そういう交渉事を国民の前で行うのでなしに、密室で行い、公表もしないというのは、日弁連のいまどきの方向性とは真逆なのではないか?

今回の日弁連の意見書が提唱する、法に基づいたプライバシー影響評価手続きが、日本にも存在していたなら、事前に防げたことはあっただろうし、未だGoogleが回答を拒否して明らかにしていない、いくつもの点*3について開示させることもできたのではないか。

実際、東京都の個人情報保護審議会の席で講演したグーグル株式会社の藤田一夫ポリシーカウンシルは、諸外国のプライバシー(あるいはデータ)コミッショナーの一覧表をスライドに出して、「日本にはプライバシーコミッショナーが無いので事前調整しなかった」と発言している(2009年2月4日の日記)。

2008年にストリートビューがスタートし、2ちゃんねる掲示板等で不満の声が爆発したころ、グーグル社員は次のようにうそぶいていたという。

プライバシーに対するグーグル的感覚とは

ところで、高木さんが怒っているのは、(中略)この問題に関してグーグルの側がきちんと説明せず、まともな広報対応もおこなっていないことだ。(中略)

実際、私がグーグル社内の何人かの知人に聞いてみると、彼ら彼女らはこんなふうに話した。「プライバシーの感覚は、時代や国や世代によってどんどん変わっていくでしょう?」「たぶん今は受け入れられなくても、ストリートビューの利便性は絶対に受け入れられるし、現在の批判は一過性のもの」

プライバシー侵害?便利ツール?賛否両論のグーグル「ストリートビュー」, 佐々木俊尚のITインサイド・レポート, サイゾー 2008年10月号

グーグル株式会社は2008年夏、このケースであきらかに配慮を欠きすぎていた。初めから一定の配慮をしていればこんなことにはならなかったろう。

日本はいつも「全否定 vs 全肯定」のような言い合いしかしない。問題とされているのはどこなのか、事実を見ることもしないで、「否定する奴がおかしい」のような圧力をかけて全肯定する輩が湧いてくる

たしかにプライバシーの問題は難しい。明確に法で定めてしまえば融通のきかない規制になってしまいかねない。どこに妥当な落とし所があるか、個別の事案ごとに検討するしかないのかもしれない。だからこそ、法に基づいた権限でもって妥協点を探っていけるようにするべきで、それは国民に開かれた手順ですることではないのか。

今ではストリートビューに対して不満の声が少なくなっているが、これは、新たに公開された地域について問題のある写真があまり発見されなかったためだと思う。おそらく、掲載前に手作業でまずい写真を探して取り除いたのではないか*4。また、昨年9月に掲載開始された名古屋と新潟を見たところでは、東京や横浜と違って、非常に狭い道の写真は掲載しないように配慮されているように見受けられた。

日本社会は、今回もまた、結果オーライでよしとするのか。今後ふたたび別のことで同様の事態が起きるかもしれないのに。

昨日参加した教育関係の研究会で、帰りがけに参加者の一人から次のように話しかけられた。「ストリートビュー、ナンバープレートが見えている画像を削除要請しているのに、何回やっても処置してくれません。」

私は、「そういうことはちゃんと表沙汰にしてください」と答えた。弁護士の人らはこういう事実をちゃんと把握しているのだろうか。

関連

追記(20日)森亮二弁護士は解説記事でも言っていることがおかしい

「森亮二 ストリートビュー」でWeb検索したところ、昨年11月に書かれた次の記事が出てきた。

5ページに渡って書かれたこの記事、最終ページの結びの言葉は以下のようになっている。

このような状況で、ストリートビューのサービス全体を止めてしまうことが正しい選択とは到底いえないであろう。もちろん第一次提案にもあるとおり、道路周辺映像サービス事業者には、今後も社会に受け入れるための努力が求められる。法的に見て、それほど問題があるわけではないこのサービスが、これほどの大きな議論を呼んだのは、事前の説明が少し不足していたからかもしれない。

(終)

グーグル・ストリートビューの法的問題を考える, p.5, 森亮二, Computerworld.jp

事前の説明が不足していたから? 少し? 事前の説明さえあれば大きな議論にならなかったというのか? それはどんな説明のことか? 言っていることが全くおかしい。ストリートビューの問題点は、この記事自身が、2ページ目、4ページ目でちゃんと以下のように指摘している。

道路周辺映像サービスでは、公道周辺の建物や風景を撮影することが目的であり、人物はその“前景”として写り込んでいるにすぎない。もっとも、画像を大量に撮影していくうえでは、自宅内でくつろぐ人の姿が塀越しに写ってしまうようなこともあるだろうし、その場合は肖像権侵害に当たるおそれもある。だが、それは全体のごく一部であり、それほどひんぱんに生じるわけではない。したがって、これを理由にサービスを全面的にやめさせるほどのことではないものと考えられる。

グーグル・ストリートビューの法的問題を考える, p.2, 森亮二, Computerworld.jp

表札や車のナンバープレート、塀越しに見える屋内の様子などもプライバシー権の対象となりうる。屋内の様子については、一般的な大人の目線よりも高い位置から撮影されたものについては問題が大きい。「他人に見られることはない」という期待があるものを公開されることのほうが苦痛は大きく、プライバシー権侵害の度合いも高くなる。(略)

道路周辺映像サービス事業によって、プライバシー権を侵害する画像が公開されてしまう危険性は否定しがたい。その場合、プライバシー権を侵害された人は、事業者に対してその画像の非表示化の要請と損害賠償請求ができる。だが、サービス提供そのものをやめさせる必要があるほど、プライバシー権侵害が頻発しているとは思われない。

グーグル・ストリートビューの法的問題を考える, p.4, 森亮二, Computerworld.jp

「サービスを全面的にやめさせるほどではない」と言いたいのはわかるが、問題点は確実に存在していたわけで、それを示しておきながら「事前の説明が少し不足していただけ」というのは、いったいどういう理屈なんだ?

さらに言えば、以下の部分のロジックもそうとうおかしい。

例えば、深夜にこっそりと風俗店などから出てくる自分の姿を撮影され、公開されたならば、プライバシー権侵害を主張することが可能だろう。(略)

逆に言えば(略)(c)撮影時間も日中に限定すれば、そうそう頻繁にプライバシー権の侵害が起こるわけではないはずだ。(略)

(c)については日中、公道で立ち小便やキスをしている姿を公開され、抗議したとしても、「何も昼日中から天下の公道でそんなことしなくても……」と感じる人が多いだろう。裁判所とて同じだ。

グーグル・ストリートビューの法的問題を考える, p.4, 森亮二, Computerworld.jp

最も問題になったのは、昼間のラブホテルに出入りするカップルが暴露されたことだ。私が把握しているだけで4件あった。なぜそこに触れずに、「深夜にこっそり風俗店」という話にすげ替えるの? (いくらなんでも知らなかったわけがないので、わざとやっているとしか思えない。)

この弁護士のロジックは、「深夜だと問題」⇒「日中に撮影すればよい」⇒「日中に路上で小便やキスしている方が悪い」というのだが、昼間にラブホテルに入るのが悪いというの? 昼間にラブホテルに入る人はその瞬間を撮影されて無断公開される可能性を踏まえないといけないと? 日本はそういう社会なんですか?

まだある。この弁護士の記事は一貫して「公道から撮影されている」ことを前提にしているが、実際のグーグル株式会社のストリートビューでは、道ですらない私有地に入って撮影された写真が大量に公開されていた。このことについてのグーグル株式会社からの説明が、今現在に至っても、全くない。

その点に全く触れずに、「事前の説明が少し不足していたから」という。

どう見てもこの弁護士は客観的な立場で仕事をしていない。困ったことだ。*5

*1 昨年5月に、カメラの高さを40センチ下げるとグーグル株式会社が発表したときは、以下の写真を示して、従来の解像度の低いカメラを使うかのような発表をしていたが、それは違う。

画面キャプチャ

*2 Twitter発言が単なる書き間違いだとすれば、頭がバイアスで充満しているのではないか。

*3 削除要請件数の他にも、たとえば、私有地には入らないと言いながら私有地に入っていた件について、その後どのように対処しているのかが明らかにされていない。

*4 昨年2月の東京都個人情報保護審議会に二人のグーグル担当者が出席した際、NHKニュースでグーグル社広報部長のコメントが放送されており、その発言は次のものだった。「プライバシーに対して懸念があるという意見は真摯に受けとめなければいけないと思っています。技術的に解決できるものは技術的に解決して、それからまた、人手で解決できるようなものは人手でやっていきたい。」これが実行されたのではないか。しかし、何が実行されたのかは明らかにされていない。

*5 弁護士という職業が、日ごろから、依頼人のためならどんな虚構のロジックであってもそれを作り上げるのが仕事なんだというのはわかるけれども、官庁のWGの仕事においてまでそうやり方をするのはやめてもらいたい。何のための専門家なのか。


2010年02月17日

iTunesストアの不正アクセス被害で問題にすべきポイントは何か

iTunesストアで不正アクセス行為が横行しており、身に覚えのない高額な請求をされて困ったという話は、昨年の秋くらいからチラホラとブログ界隈に出ていた。たとえば以下の報告では、中国語の商品等が不正に購入された被害を示している。

  • iTunesのアカウント不正利用に関する一例, 2009年10月31日〜11月4日

    お問い合わせいただいたアカウントロック解除のお願いについてご案内します。

    アカウント名 xxxxxxxxxxx は、お客さまの事前承諾なしに商品が購入されたというお問い合わせをいただきました。不正使用で、アカウント名 xxxxxxxxxxx は、変更されていますので、○○様のアカウントを有効かする事はできません。 アカウントロック解除はできませんご了承下さい。

    ○○様のもう一つのアカウント名  yyyyyyyyyyyyy の方は、最近購入した曲やアプリケーションの名前:不正利用だと書いてあるでしょう との事でしたので、こちらのアカウントも有効かする事はできませんご了承下さい。

    誠に残念ながら、この購入の金額を返金させていただくことはできません。 iTunes Store サービス規約により、アップルではお客さまのアカウントの不正使用により生じる損失について一切の責任を負いかねます。 サービス規約は次のページでご確認いただくことができます。

  • iTunesアカウントが乗っ取られた!その4, isiの日記, 2010年1月27日

    カード会社に電話
    →書類が無事に届いたことを確認。
    iTunes株式会社に連絡を入れているが応答がないとのこと。

この問題に消費者庁が対応するとのことで、NHKニュースにもなったようだ(テレビのニュースは見逃した)。

  • 配信請求トラブル 実態を調査, NHKニュース, 2010年2月17日

    アメリカのアップル社が運営するインターネットの配信サービスの利用者が、購入した覚えのないソフトの料金を請求されるトラブルが相次いでいる問題で、消費者庁は17日、アップル社側の担当者を呼んで、トラブルの実態について回答を求めるなど本格的な調査をはじめました。

    (略)相次ぐトラブルについてアップル社は、NHKの取材に対し、「iTunesから情報は流出していない」としていますが、一方で消費者庁には、アップル社側のサポート体制が不十分だとする利用者からの声も寄せられており(略)

この種の事案をマスコミが扱う場合に注意しなければならないのは、「iTunesがパスワードを流出させたんじゃないのか」という素人丸出しの安直な発想で追求して、話をアサッテの方角に向けてしまわないようにすることだ。

案の定、この問題を最初にニュースにした1月25日の朝日新聞の記事は、この過ちを犯した。

  • iTunesで不正請求被害 アップル社、ID流出否定, 朝日新聞, 2010年1月25日

    (略)同社からは購入契約の解約を断られた。クレジット会社に事情を説明したところ、自ら購入していないと認められ、請求を撤回してもらうことができた。

    (略)相談した消費生活センターからは、IDとパスワードの管理責任は消費者側にあり、iTSのコンピューターが不正操作されて情報が流出したのでなければアップル社の責任は問えない、と説明されたという。

    (略)アップル社の日本法人は「現時点では、管理しているコンピューターからIDが盗まれた事実はない」と同社からの流出を否定している。米国でも同様の被害が報告されているが、同社は、考えられる原因として、偽メールなどで偽サイトに誘い込み、IDやパスワードを入力させて盗む「フィッシング詐欺」に遭ったか、他人にパスワードなどを教えたり見られたりした可能性を挙げる。

この記事が不適切なのは、最初にiTunesストアからのパスワード流出を疑い、それをアップルに否定されると、アップルが主張するがままに、利用者の責任にしてしまっている。

この種の不正アクセス行為が起きる原因として、検討するべき重要な可能性は、他のサイトで流出したIDとパスワードが用いられたのではないか(流出パスワードを売買する中国語の闇市場があると聞く)、という点である。この可能性について、朝日新聞の記事は触れていないし、続報として書かれた1月29日の朝日新聞記事も、この点に触れていない。

設定していたのが弱いパスワードだったとか、フィッシングによってパスワードを盗まれたのだとすれば、利用者の責任だと言うこともできるかもしれない。しかし、他のサイトに登録していた同じパスワードが流出したのが原因だとすれば、それを利用者の責任として問うべきではない。

利用者の自己防衛の手段として、「サイトごとに異なるパスワードを設定しましょう」と呼びかけるのはよいとしても、それを実行できていない利用者を責めるべきではない。

結局のところ、この種の不正アクセスはいくらかの確率で発生し、利用者の責任で完全に防ぐことはできないものと考えるべきであり、サイト運営者は、それを踏まえた運営をするべきである。パスワード認証という脆弱なユーザ認証方式を、利便性と低コストを優先して採用している、サイト側の責任とみなすべきである。

iTunesストアの場合、支払いを拒否してアカウントを凍結された場合、過去に購入したiPhone OSの有料アプリのアップデートを受けられない等の問題が生ずるのであるから、支払いの義務がないというだけで決着する話ではない。iTunesストアと交渉する力を持たない一般消費者が泣き寝入りすれば、購入済みの財産を放棄させられるという損害が生ずる。

  • iTunesアカウントが乗っ取られた!その2 - isi の日記,

    ●iTunesの対応

    「一旦買ったら後は一切返品は受け付けません」嗚呼。オンラインコンテンツの性質上やむを得ないのでしょうが、これでは不正使用の被害者はどうしようもありません… 不正購入の事実がはっきりした時点でDRMの再認証を出来なくするとか、購入履歴から削除するとか、対応をお願いしたいところですが、inyavaさんのコメントからすると無理そうですね…

この点を問題視すべきであるのに、これまでにどの報道もその点を追求していない。

消費者庁がこの点を含めて処置することが期待されるが、グーグル株式会社のストリートビューへの対応と同様に、アップル社には極めて不適切な対応をされるおそれがあると思う。


2010年02月20日

警察庁は子供にハッキングを唆すのを止めるべき(パスワードを玩具にするな)

  • 小6・中3 サイト侵入で補導, 朝日新聞 マイタウン徳島, 2010年2月19日

    女児は「アバター」と呼ばれる自分の分身に、現金と交換する疑似通貨で服やペットを買って楽しむ会員制ゲームをしていて、他人のアバターの服(2200円相当)を盗もうと計画。昨年10月、徳島市の中学3年の女子生徒に「疑似通貨を増やすいい方法を教えてあげる」とネットを通じて持ちかけてIDとパスワードを聞き出し、不正にゲームに入ったとされる。

    (略)女児は「いろんなアイテムがほしくて悪いことをした」と話しているという。

小学6年生の女子児童が不正アクセス禁止法違反で補導されたというニュースだが、今もこういう事件が起きているらしい。子供達は、何が悪いこととされたのか、本当にわかっているのだろうか。同じことは6年前にも書いたが、もう一度書いておく。

初等中等教育の現状と新学習指導要領への期待

先週の金曜日、久野さん(久野靖筑波大学教授)の取り計らいで、「プログラミング・情報教育研究会」の場で「小中学校から教えるべき情報セキュリティの要点」と題して講演する機会を頂いた。そこで「教えるべき」としたのは以下の点。

  1. Web利用の基本中の基本「アドレスバーは単なる入力欄じゃなくて現在の場所を示すところ」
    太古の昔、アドレスバーが入力欄でなかったのを知ってるかい?」, 2004年4月26日の日記
  2. Webサイトに入力させるなら「入力前にアドレスバーでSSLと場所を確認する」
    SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも」, 2005年11月30日の日記
  3. 開いてよい種類のファイルなのか、拡張子の概念
    アンチウイルスベンダが消費者のリテラシー向上を期待しないという構図」, 2005年12月23日の日記
  4. 他人のパスワードを無断で使用することは法律で禁止されている(これはルールだ)
    警察庁と警視庁は子供に不正アクセスをどう教えているか」, 2004年4月10日の日記

いずれも、だいぶ前にこの日記に書いていた内容であるが、講演では、中学校、高等学校の検定済教科書を入手して、現状がどうなっているのかを調べて報告した。

中学校の技術・家庭の教科書2冊と高等学校情報Aの教科書12冊を調べたところ、上記のいずれの点についても、ほとんどで触れられていないか、言うべきことが書かれていなかった。(たとえば、上記1.の点は、第一学習社の三訂版情報Aにしか記述がなかった。)

もっとも、これらの教科書は平成18年検定のものなので、いささか古くなっている。現行の学習指導要領も古いので、何を教えるべきかがほとんど明確に書かれていない。

講演に際して、新学習指導要領(数年後に施行される)についても調べたところ、変更点は、大変興味深いものになっていた。

  • 新しい学習指導要領 中学校学習指導要領 第2章第8節 技術・家庭, 文部科学省

    D 情報に関する技術
    (1)情報通信ネットワークと情報モラルについて,次の事項を指導する。
    ア コンピュータの構成と基本的な情報処理の仕組みを知ること。
    情報通信ネットワークにおける基本的な情報利用の仕組みを知ること。
    ウ 著作権や発信した情報に対する責任を知り,情報モラルについて考えること。
    エ 情報に関する技術の適切な評価・活用について考えること。

上記引用の強調部は、現行の学習指導要領にはない記述で、「基本的な情報利用の仕組み」とは何だろうかと、「中学校学習指導要領解説」を確かめたところ、次のように書かれており、情報セキュリティの観点が明確に記載されていた。

  • 新しい学習指導要領 中学校学習指導要領解説 技術・家庭, 文部科学省

    イ 情報通信ネットワークにおける基本的な情報利用の仕組みを知ること。

    インターネットなどの情報通信ネットワークの構成と,安全に情報を利用するための基本的な仕組みについて知ることができるようにする。この学習では,情報通信ネットワークの仕組みの観点から,情報セキュリティの確保のために対策・対応がとれるよう,D(1)のウと関連させて指導するよう配慮する。
    
(略)安全に情報を利用するための基本的な仕組みについては,ID・パスワードなどの個人認証とともに,フィルタリング,ウイルスチェック,情報の暗号化などについて知ることができるようにすることが考えられる。

すばらしい。想像していたより抜群に良い方向に向かっていた。あとは、この期待に答えられる教科書作りがなされなければならない。

と、講演ではそういう話をしたのだけども、ここでは、以下、パスワードの件についてだけ書く。

不正アクセス禁止についての教育の現状

言いたいことは6年前の日記「警察庁と警視庁は子供に不正アクセスをどう教えているか」(とそれに続く「不正アクセス禁止法 立法者の意図(推定)」)にほとんど書いているが、改めて今の理解で書き直してみる。

他人のパスワードを無断で使う行為は、必ずしも自然犯ではない。その行為自体に必ずしも反道徳性があるわけではないところ、不正アクセス禁止法(不正アクセス行為の禁止等に関する法律)によって、2000年2月以降(罰則付きで)禁止されているにすぎない。*1(しかも、電気通信回線を通じて行うものに限定されている。保護法益がそういうものだから。)

子供が自然に育つ中で、他人のパスワードを無断で使うことが反道徳的なものであるとの感覚を持つとは限らない。それどころか、パスワード破りはゲームのように扱われることが少なくない。

だから、初等教育のかなり早い段階(少なくとも、学校でパソコンを使わせる最初の時点で)、「他人のパスワードを無断で使うことは法律で禁止されています。これはルール。やってはだめ。」ということを単純に、明確に教えるべきである。

では、現状の検定済教科書がどうなっているかというと、中学校の技術・家庭の教科書では、「パスワードは他人に知られないように」という記述はあるが、他人のものを無断で使ってはいけないという記述がない。

また、高等学校の情報Aの検定済教科書を調べてみたところ、次のようになっていた。

第一学習社 三訂版 情報A
p.136の記述:「サイバー犯罪の1つに、不正アクセスによって、重要な情報を盗み出す行為がある。不正アクセスには、他人のユーザIDやパスワードを不正取得してなされる場合(なりすまし)と、……セキュリティホール)をついて、他人のコンピュータに侵入する場合がある。こうしたことへの対策として、1999年に不正アクセス禁止法が制定された。」
善良な児童からすれば他人事に聞こえる書き方。「悪い人がいるから、困るね」と思うような善良な児童が、ふとしたきっかけて他人のパスワードを無断で使ってしまいかねない。
日本文教出版 新・情報A
p.38「不正アクセス」の用語説明しかない。まるで他人事。
数研出版 三訂版情報A
p.98「不正アクセス」の用語説明しかない。まるで他人事。
東京書籍 情報A
p.138「ユーザIDとパスワード」という半ページを費やしたコラムがあるが、「侵入されないようパスワードはしっかり管理しよう」「もし他人があなたのパスワードを知ってしまったら」という観点の記述はあるが、「あなたが他人のパスワードを知ったとしても○○してはいけない」という記述がない。
啓林館 情報A最新版
一番最初にパスワードのことを教えている。この点は良い。しかし、他人のパスワードを無断で使ってはいけないとの説明はない。「第三者には絶対教えない」といった記述から、それを類推できるだろうか?
p.134に法律の条文が掲載されているが、条文を読んでわかるとは到底思えない。
教育出版 新版情報A
p.86に1ページでパスワード管理の大切さを書いているが、他人のパスワードを無断で使ってはいけないとの説明はない。
p.119に、「他人のユーザIDやパスワードを盗用するなどしてコンピュータに侵入する不正アクセスが行われると、情報の改ざんや盗み出しの危険にさらされる。」という記述があるが、この文から、パスワードを無断使用することそれ自体が「悪いことなんだ」と類推されるだろうか? 「改竄や盗み出しをするわけでなく、ログインするだけなんだからかまわない」という、誤った理解を阻止できる記述だろうか?
実教出版 高校情報A 及び 最新情報A
冒頭の口絵3に「本人に無断で他人のユーザIDとパスワードでログインした場合は、不正アクセス行為になる」と書かれている。

最後の実教出版の情報の教科書は、(シェアが高いわりにプロの間では評判が悪い様子だったが、)不正アクセス禁止については、他のどの教科書よりも言うべきことを最初に言っていて良い出来だった。(もっとも、説明文が雑で正確性を欠いている*2のだが。)

他の教科書に見られるように、不正アクセスの攻撃から防衛することに力点を置くあまりに、不正アクセスの脅威をおどろおどろしく書くパターンが多いが、そういう書き方をすればするほど、善良な児童生徒は、自分がそれを犯す可能性に想像が及ばなくなってしまうのではないか。

不正アクセス禁止法違反で子供が補導される事件は、以前から度々起きていて報道されていた。

相手からアイテムを奪うというのはゲーム内では日常であり、まったくの合法行為で、それ自体が目標となるなわけだが、その手段として、ゲームのアカウントのパスワードを奪う(無断で使う)のは、ゲームの外の話であって、罰則付きの違法行為なわけだけども、はたしてそのことが、子供達に区別がついているのかどうか。

これが以前から心配していたことで、これまでにも何度か、シンポジウム等でお目にかかった警察の方に「ちゃんと教育してください」と意見を述べたことがあった。

毎年発表される「不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況」によると、平成20年においても、10代による犯行が最も多かったという。

被疑者の年齢についてみると、10歳代(48人)が最も多く、20歳代(42人)、 30歳代(35人)、40歳代(11人)、50歳代(1人)の順となっている。なお、最年少の者は14歳、最年長の者は52歳であった。

不正アクセス行為の発生状況及びアクセス制御機能に関する技術の研究開発の状況, 国家公安委員会・総務大臣・経済産業大臣

パスワードといえば「破るゲーム」という発想

そして今回、講演のために古い日記を読み返していたところ、以前、問題視して書いていた、警察庁の児童向けの教育コンテンツ「キッズ・パトロール」が現在も修正されておらず、当時のまま公開され続けていることに気づいた。

以前に示したときはリンクと文字で説明しただけだったので、今回はわかりやすいように、実物の画面を引用して示す。

画面キャプチャ
図1: 警察庁の児童向け教育コンテンツ「キッズ・パトロール」より

「ハッピィちゃん」の家に遊びに行く途中で、「合言葉を見つけて」というのだが、この「合言葉」の利用権者が誰なのかは説明されていない。

画面キャプチャ
図2: パズルを解いて合言葉を見抜けというシーン

しかも、これで完成した「合言葉」は、インターネットにおけるIDとパスワードのことなんだという(図3)。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図3: この「合言葉」がインターネットにおけるID、パスワードに相当すると説明

画面キャプチャ
図4: 人に教えてはいけないとは説くが……

人に教えてはいけないとは説くが、他人のパスワードはいかなる目的であっても無断で使ってはならないことについては、何も言っていない。

画面キャプチャ 画面キャプチャ
図5: 「家にはいる」ために、拾ったパスワードを入力せよという

さきほどのパズルで見つけ出したパスワードを入力せよというのだが、これがアクセス管理者(ハッピィちゃん)から主人公に対して発行されたパスワードなのかは、どこにも説明されていない。

もう一つ、同様に問題のあるコンテンツがある。(2005年11月18日の日記に書いた件。)

画面キャプチャ 画面キャプチャ
図6: 送ってしまったメールを奪還するという

「あんなメール出さなければよかった」という状況で、「なんとかメールを取り戻してみよう」という。どうやってやるのかというと、次の図だ。

画面キャプチャ 画面キャプチャ
図7: ISPにハッキングしてメールを奪還するゲーム

メールの転送経路上にある複数のISPに対して、それぞれに異なるパスワードを入力して、メールを奪還せよという。パスワードの利用権者が誰なのかは全く説明されていない。

画面キャプチャ
図8: いったい何を教えたいのか

これが、現実ではなくて虚構のお話なんだとネタばらしするのはよいが、図8のように、「本当は……ゲームみたいに取り戻すことはできない」と言っているだけで、自分のパスワードじゃないものを、パスワードとして使ってはいけないということについて、何も言っていない。

これは笑い事ではない。こうやって普段からゲーム感覚でパスワードを扱っているから、子供たちに、ゲーム内の世界と、ゲームと現実との境界線(つまりパスワード)を混同させてしまっているのではないのか。

このコンテンツがじつは全く使われていないというのなら、まあいいだろうけども、調べてみると、国立教育政策研究所の「教育情報ナショナルセンター」が、小学校向けの教育コンテンツとして、このキッズ・パトロールを推奨している。

こういう不適切なコンテンツは、修正するか、削除するべきである。

子供の前で食べ物を玩具にしてはいけないというのと同様に、パスワードを玩具にしてはいけない。

*1 この点について、警察庁不正アクセス対策法制研究会著「逐条 不正アクセス行為の禁止等に関する法律」(立花書房)は p.68 で次のように説明している。

いわゆる自然犯は行為それ自体が法律で定められるまでもなく社会的に悪とされる行為であり、法令においては、特にその行為をしないように命ずるまでもなく、その行為を処罰する規定を設ければ足りるものであり、他方、法定犯は行為それ自体の当罰性は法令の規定による義務履行違反に求められるため、法令においては、義務を課する規定と義務違反を処罰する規定とを設けることが必要であるとの理解に基づくものであると考えられる。

このように解する場合、不正アクセス行為については、処罰することとすることが適当な行為であると認められるにしても((略)アンケート調査結果でも回答の約八十五パーセントが不正アクセスを法律で取り締まる必要があると回答している。)、前法律的に反規範性を有する行為であるとまではいえないと考えられる。そこで、本法においては、不正アクセス行為の処罰については、犯罪の防止及び電気通信の維持という本法の目的を達成するために、本条第一項において「何人も、不正アクセス行為をしてはならない」との規定を置いた上で、第八条で同項の規定に違反した者を処罰する旨の規定を置くこととし、不正アクセス罪が法定犯(行政犯)であることを明らかにしたところである。

*2  以下の図のように書かれているが、3つの点で正しくない。 (1)「電子メールのなりすまし送信」は、不正アクセス禁止法の不正アクセス行為ではないのに、そのように読まれかねない不適切な記述になっている。 (2)「無断で他人のパスワードでログインした場合は不正アクセス行為になる」と書かれているのは良いが、それが違法だという記述が欠けているし、罰則があることも書かれていない。直前の文脈からして、「倫理上ゆるされない」話と混同される。 (3)「パスワードの入手」は不正アクセス行為ではないのに、入手することが不正アクセスであるかのような誤った記述になっている。 (4)右側の説明文と矢印で結ばれた生徒のフキダシの内容が、対応していない。

教科書に記載の絵
実教出版 高校情報A(平成18年検定済) 口絵3 より引用


2010年02月21日

はてなのかんたんログインがオッピロゲだった件

といった問題が指摘されているところだが、それ以前の話があるので書いておかねばならない。

昨年夏の話。

2009年8月初め、はてなブックマーク界隈では、ケータイサイトの「iモードID」などの契約者固有IDを用いた、いわゆる「かんたんログイン」機能の実装が危ういという話題で持ち切りだった。かんたんログイン実装のために必須の、IPアドレス制限*1を突破できてしまうのではないかという話だ。

「実際に動いてすぐ使える」などと無責任なライブラリを出した ke-tai.org の著者に対して、「絶望的にわかってない」といったコメントが寄せられていた。

この一連の流れを読んで、私はやっと理解した。ここで指摘されていた方法で突破されてしまう実装は少ないのではないかと思ったのと同時に、何がいけないのかを理解し、ここには出てこなかったもっと別の方法(X)で、IPアドレス制限を突破できてしまう駄目な実装があり得ると思った。ならば、その実例を探して(修正を促した後)、それを広く周知すればよいと、そう考えたのだった。

まず最初に調べたのは「ポケットはてな」だった。最も身近なサイトであるのと同時に、「はてなならやりかねない」と、そう思ったからだ。

さっそく、その方法(X)で接続し、ポケットはてなの「かんたんログイン」ボタンに、携帯電話からではなく、通常のインターネット回線経由でパソコンから telnet でアクセスした。事前に、自分の携帯電話でポケットはてなに「かんたんログイン」の設定をしておき、自分の携帯電話の契約者固有IDを、HTTPリクエストのヘッダとして、telnet で手作業で送信した。

すると、思った通り、突破できてしまった。ログイン済みとして紐付けられたセッションIDが発行され、そのセッションIDでアクセスすれば、私のアカウント HiromitsuTakagi でのログイン状態となった。

ところが、テストしているうちに、何だかおかしいことに気づいた。(X)の方法を使っていないときでも、ログインできているようなのだ……。

半信半疑ながら、検査手順を整理して改めてテストしてみると、やっぱりログイン状態になる。つまり、なんと、ポケットはてなは、はじめっからIPアドレス制限なんぞ、まったくしていなかったのだ。

これにはぶったまげた。いくらなんでもそれはないわ。あれだけ度々、はてなブックマークのセキュリティタグ界隈で、契約者固有IDによる「かんたんログイン」の危うさが話題にのぼっていたのに、はてなの人らは、見てないのか?

急ぎ、脆弱性報告書を作成し、はてなに送付すると同時に、IPAの脆弱性届出窓口に通報した。はてなに送付した文面は以下の通りである(一部伏せ字)。

株式会社はてな 情報セキュリティ対応係 御中

2009年8月9日(第2版)

はてなの「かんたんログイン」が何の対策もされておらず
どこからでもなりすましログインされる欠陥について

携帯電話向けWebアプリケーションの「かんたんログイン」方式の危険性について調査する過程で、はてなの「かんたんログイン」機能を調べたところ、何ら、なりすまし対策がなされておらず、どこのIPアドレスからでもいつでも誰にでもなりすまして不正ログインされてしまうという、致命的でこれ以上なく初歩的な欠陥があることに、ついさきほど気づきましたので、以下の通り、取り急ぎお知らせします。

1. はてなの「かんたんログイン」機能の挙動

私のはてなアカウント「HiromitsuTakagi」は、「かんたんログイン」機能を有効にする設定を、私の所有するauの携帯電話にて行っています。そして、はてなの「かんたんログイン」機能は、たとえば、http://mobile.hatena.ne.jp/ に「ログイン」というリンクで案内されており、そのリンク先のURLは以下のものになっています。

http://www.hatena.ne.jp/mobile/easylogin?uid=NULLGWDOCOMO&(略)

そこで、以下のHTTPリクエストを、直接 www.hatena.ne.jp の80番ポートにTCP接続することによって、手作業で送信しました。ここで、「X-Up-Subno:」フィールドの値は、私のau携帯電話の契約者固有ID(EZ番号)です。

GET /mobile/easylogin HTTP/1.1
Host: www.hatena.ne.jp
User-Agent: KDDI-ST33 UP.Browser/6.2.0.13.2 (GUI) MMP/2.0
X-Up-Subno: 0500XXXXXXXXXX_mg.ezweb.ne.jp

この接続は通常のインターネット回線から行いましたが、正常に送信することができ、以下のHTTPレスポンスが返ってきました。

HTTP/1.1 302 Found
Date: Sat, 08 Aug 2009 14:11:11 GMT
Server: Apache/2.2.3 (CentOS)
Cache-Control: no-cache
Pragma: no-cache
Location: http://mobile.hatena.ne.jp/?sid=1eaeXXXXXXXXXXXX
(略)

ここでリダイレクト先として指定されているURLに、セッションIDらしきものが含まれています。このURLに、初期状態のWebブラウザ(cookieを消去した通常のWebブラウザで、はてなにログインしていない状態)で、通常のインターネット回線からアクセスしてみたところ、「ようこそHiromitsuTakagiさん」と表示され、私のアカウントでログインした状態となりました。つまり、パスワードを入力していないのに、私のアカウントでログインした状態となりました。

2. セキュリティ上の問題点

上記の挙動から、他人の携帯電話の契約者固有IDを知り得る立場の者であれば、「かんたんログイン」設定を有効にしているはてなユーザに対して、なりすまして不正ログインできてしまうと推察されます。

携帯電話の契約者固有ID(EZ番号等)は、Webサイト運営者であえれば誰でも他人のIDを入手することのできるものですから、事実上、誰でもはてなに不正ログインができてしまう、極めて危険な状態にあると考えます。

3. 生じ得る被害

なりすましログインによって、たとえば、はてなダイアリーへ偽の投稿をされたり、既存のダイアリーを改竄される危険性があるようです。その他にも、パスワードなしに操作可能な機能によって、何らかの被害が生じ得るかもしれませんが、確認していません。

以上

この文書を8月10日にはてなにメールで送付した。すぐに「修正対応を検討している」との返事があり、その後、「8月31日に脆弱性への対策を行った」との連絡があった。

当時のテストの様子(不正アクセス行為を伴わない寸止めテスト手法の様子)は、以下の図のとおりである。

画面キャプチャ
図1: ポケットはてなの画面(ログイン前)

画面キャプチャ
図2: かんたんログインのリンクを telnet でアクセスした様子
(X-Up-Subno には自分の契約者固有IDをセットしている)

画面キャプチャ
図3: 図2のリダイレクト先URLに図1のブラウザでアクセスした様子
(「ようこそ HiromitsuTakagi さん」とログイン状態になっている)

画面キャプチャ
図4: リンクを辿って日記の編集画面に進んだ様子

私のEZ番号を知っている人なら、誰でも私の日記を改竄等できてしまう状態だった。

正直、げんなりした。これがケータイWeb業界の実情なのか……と。

心配になったので、「かんたんログイン」でWeb検索して、かんたんログインを提供しているサイトを探し、見つかったところから手当たりしだいに、自分用のアカウントを登録して、自分のアカウントでテストしてまわった。

そうしたところ、他に4か所のサイトで同様の事例が見つかった。(そのうち3か所は、同じところが作った同一のWebアプリケーションだった。)これらについて、Webサイト運営者に脆弱性報告書を送付すると同時に、IPAの脆弱性届出窓口に通報して、修正を促した。

ただ、全部を調べたわけではない。数日間しか探さなかったし、アカウントを自由に登録させてもらえないサイトは調査していないし、マイナーすぎるサイトもスキップした。

こんな事態になっているのは、携帯電話会社が、どうやったら「かんたんログイン」なるものが実現できるのか、ちゃんとした実装方法の公式解説を出さないからだろう。もっとも、契約者固有IDを「かんたんログイン」の用途で使えると公式に認めているのは、NTTドコモだけだったかもしれない。

画面キャプチャ
図5: iモードIDが「かんたんログイン」用途に使えるものであると
NTTドコモが公式に主張している様子
『iモードID』の提供開始について, NTTドコモ, 2008年2月28日

これだけ明確にこの用途を公式に掲げたのだから、NTTドコモの責任で問題解決にあたるべきだろう。*2

はてなは、その後、10月21日に「かんたんログインがよりかんたんになりました」というリニューアルを発表した。リニューアル後の構成についても調べたところ、修正後のポケットはてなの実装では、(X)の手法の影響は受けないものになっていた。

では、(X)の手法の影響を受けるサイトはあったのか。(X)の手法とは何か。これについては、JVNでの公表を待って、近々、公表して注意喚起したい。

*1 携帯電話キャリアのゲートウェイのIPアドレスからのアクセスに限定する処置。

*2 もっとも、それ以前に、iモードID等の契約者固有IDは廃止されるべきなのだが。


2010年02月23日

はてブiPhoneアプリでログインしてはいけない

昨日、iPhone OS用の、はてなブックマークアプリがリリースされたのだが、

これは、下の図のように、最初のトップ画面(左)は専用アプリが表示しているものの、どれかをタップして画面を進めると、それはアプリに埋め込まれた「内蔵ブラウザ」(Safari部品)によって表示されるようになっている(中央、右)。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図1: はてなブックマークiPhone OSアプリ

ブクマされた記事をタップすると、はてなの外に出ることになるが、このときも「内蔵ブラウザ」で表示され、下の図のようになる。しかし、このアプリは、アドレスバーがない。ここがどこなのか、わからない。

画面キャプチャ
図2: はてなの外に出たときの様子
(出典: http://designblog.ecstudio.jp/htmlcss/zen-coding-aptana.html)*1

あちこちタップしていると(てきとうなタイミングで)、下の図のように、はてなのログイン画面(のような画面)が出ることがある。

画面キャプチャ 画面キャプチャ
図3: はてなのログイン画面(のような画面)が出た様子

これが専用アプリならよい(アクセス先が固定だろうから)のだが、これはWebブラウザなのだから、どのアドレス(URL)にアクセスしているのかは定かでない。つまり、これは、どこかの偽サイトが出している画面かもしれないのだが、アドレスを確認する方法がない。

下の図のように、下に引っ張り下げてみても、上に何かあるわけでない。

画面キャプチャ
図4: 下に引っ張ってみた様子

画面上のアプリの固定領域にあるボタンを押してみても、下の図のように、アドレスを確認する機能は用意されていない*2。検索欄をタップすると単にキーボードが出るだけだ。

画面キャプチャ 画面キャプチャ
図5: アドレスを確認する機能が用意されていない様子

ヘルプを見ると、下の図のように、「内蔵ブラウザで閲覧」(左)してページからタップして「ログイン操作を進めて」(中央)と言っている。偽サイトが現れる可能性に想像が及んでいない。現状での自衛策としては、設定画面(右)で「必ずSafariで開く」をオンに変更することしかない。

画面キャプチャ 画面キャプチャ 画面キャプチャ
図6: ヘルプと設定画面

以前にも類似のことがあったが、どうしてこう、基礎がわからないのか。

また、今回のアプリは、ログイン画面は https:// になっている*3ようだけども、画面が図3のままでは、https:// を使っても無意味である。

なぜなら、WebブラウザにおけるSSLの使用は、利用者が入力する際に今見ている画面が https:// になっていることを確認して利用しない限り、暗号化の意味をなさないからだ。

  • 安全なWebサイト利用の鉄則 / よくある質問と答え

    Q1: アドレスの確認を入力の直前にするのはなぜですか?(利用者)

    リンクを辿ってページを移動している間に、どこのサイトにいるかが怪しくなる場合があります。特に、SSLによる通信の暗号化が必要な場面ではこのことは重要です。たとえば、利用するサービスのトップページでアドレスを確認し、本物サイトであることを確認したとしましょう。そこからリンクを辿ってログイン画面に辿り着いたとします。そのページは本物サイトでしょうか? そうとは限りません。なぜなら、リンクを辿っている途中のページに https:// ではない http:// のページが1つでもあったなら、そのページが通信路上で改竄されていた可能性を否定できません。いつのまにか違うサイトへジャンプさせられている可能性があります。

    ページを移動するたびに見ている画面が https:// であることを確認するというのは、利用者にとって煩雑すぎる作業です。入力欄のあるページで利用者が重要な情報を入力をしようとしたそのときに、アドレスのドメイン名を確認し、https:// であることを確認するという手順が、シンプルかつ合理的です。

    Q2: 入力ページを https:// にしなければならないのはなぜですか?(サイト運営者)

    個人情報等をSSLで暗号化していると謳っているWebサイトで、重要な情報の入力欄が http:// のページになっていることがあります。そのとき、サイト運営者が、「入力したデータの送信先は https:// になっているから暗号化されます」と主張することがありますが、それは誤りです。

    入力欄のページが http:// であるなら、そのページは通信路上で改竄されている可能性を否定できません。サーバ側のHTMLファイルが https:// へ入力データを送信するよう書かれていても、利用者のブラウザに到着したHTMLでは http:// へ送信するよう改竄されている可能性があります。利用者がそのことに気づかずに情報を入力してしまうと、暗号化されずに送信され、盗聴されてしまいます。

    SSLは盗聴を防ぐだけでなく改竄も防止する技術です。入力欄を https:// ページとしておき、利用者が入力の直前にそのことを確認することによって、SSLは有効に働きます。

そもそも、専用アプリなのだから、はてなへのログイン(パスワードの入力と送信、認証)はWebブラウザを使わずに実現するのが普通だろう。

*1 アドレスバーが存在しないアプリは、出典を隠して著作物を表示しているとも言え、著作権侵害の面もあると思う。Webコンテンツの著者は、Webブラウザが当然にURLを示してくれることを前提として、著作物を提供しているのだから。

*2 このメニューにアドレス確認機能を追加するのは得策でないかもしれない。偽サイトがこれと同じ見た目の偽メニューを出す可能性を踏まえて、利用者が区別できるかを検討しないといけない。

*3 関連:公衆無線LANで使うと危ないiPod touchアプリに注意, 2008年12月6日の日記


2010年02月27日

なぜ一流企業はhttpsでの閲覧をさせないようにするのか

「かんたんログイン」などという似非認証方式は、たとえIPアドレス制限を実装したとしても安全でない。仕様が公開されていないからという点の他に、技術的な理由として、少なくとも次の2つがある。

  1. 「IPアドレス帯域」と俗称される重要情報が安全に配布されていない。
  2. SSLを必要とするケータイサイトでは、通信経路上の攻撃によってなりすましログインされてしまう。*1

2番目には解決策がない。

1番目については解決策はあるだろうが、携帯電話事業者がサボタージュしていて、実現される見通しがない。これについては、2008年7月27日の日記にも書いたが、その後どうなったかを調べてみたところ、ソフトバンクモバイル以外は、何ら改善されておらず、当時のままだった。

NTTドコモ
iモードセンタのIPアドレス帯域」のページをhttps:// でアクセスすると、404 Not Found となる。
KDDI
EZサーバのIPアドレス帯域」のページをhttps:// でアクセスすると、404 Not Found となる。
ソフトバンクモバイル
Yahoo!ケータイにて利用するIPアドレス帯域」のページは、https:// でもアクセスできる。
イー・モバイル
IPアドレス帯域」のページは、https:// でアクセスしようとしても、つながらない。ポートが遮断されている。

NTTドコモとKDDIは、ちゃんとSSLを稼働させているのに、なぜかあえて 404 Not Found にしている。せっかくSSLを正しく証明書を取得して稼働させているのに、どういうことなのか。

この違和感は、金融機関のサイトについても以前から気になっていた。

金融機関にとっては、連絡先の電話番号なども重要な情報であり、すり替えられたりしないよう、安全に閲覧できる手段を用意していてしかるべきである。それなのに、大手金融機関が、どういうわけか、それを実施していない。

以下は、「銀行」でGoogle検索して上から出てきた順に、各金融機関について現状を調べたものである。

三菱東京UFJ銀行

画面キャプチャ
上のページを https:// でアクセスした様子
(akamaiのサーバ証明書。ホームページをSSL対応にするつもりがないケース。)

三井住友銀行
画面キャプチャ
三井住友銀行の「お問い合わせ先」ページ
(重要な用件の連絡先が書かれている。)

画面キャプチャ
上のページを https:// でアクセスした様子
(EV SSLまで用意されているのに、404 Not Found になっている。)

りそな銀行
画面キャプチャ
りそな銀行の「お問合せ」のページ
(重要な用件の連絡先が書かれている。)

画面キャプチャ
上のページを https:// でアクセスした様子
(SSLは正常に用意されているのに、404 Not Found になっている。)

みずほ銀行

画面キャプチャ
上のページを https:// でアクセスした様子
(SSLのサーバが稼働していない。ホームページをSSL対応にするつもりがないケース。)

イーバンク銀行
「お問い合わせ」ページが見つからなかったのでスキップ。

ゆうちょ銀行

画面キャプチャ
上のページを https:// でアクセスした様子
(SSL用の別サーバ wwws.jp-bank.japanpost.jp の証明書。ホームページをSSL対応にするつもりがないケース。)

画面キャプチャ

別サーバ「wwws」の同じパス名に https:// でアクセスしてみた様子
(404 Not Found。別サーバで用意しているわけではないらしい。)

なんと、このように、上位5行のいずれも、問い合わせ先電話番号等を https:// ページで閲覧できるようにしてくれていない。

2008年9月にフィッシング対策協議会が公表した「フィッシング対策ガイドライン」にも、次のように書かれている。

【要件】 ◎Webサイト運営者の連絡先及びガイダンス等、顧客に間違いなく情報を伝える必要のあるページはSSL/TLSで保護すること

SSL/TLS には、機密性保護に加え、アクセスしている Web サーバの正当性(ドメイン名を含めたサーバ名と運営者との関係について認証局が確認をとっているということ)を検証する機能が備わっている。Web サイト、Web サービスに関する緊急時の連絡先及びガイダンス等、Web サイト運営者から正しく情報を伝える必要のあるページは SSL/TLS でのアクセスを可能とし、顧客が Web サイト運営者からページコンテンツが提供されていることを確認する手段を提供することが望ましい。

フィッシング対策ガイドライン, フィッシング対策協議会, 2008年9月10日

これがぜんぜん守られていない。どうしてこんなことになっているのだろうか。

ここで思い出すのが、昔からしばしば、「https:// のページは http:// でアクセスできてはいけない」などと、出鱈目なことを言う自称セキュリティ屋がいたことだ。インターネットバンキングのSSLサイトを http:// でアクセスして、アクセスできると「危ない銀行だ」などと出鱈目なことを言いふらしているのがいた。

最近でも、以下の文書がそういうことを言っている。

適切に HTTPS を使うことで通信の盗聴・改ざん・なりすましから情報を守ることができます。重要な情報を扱う場合には HTTPS で通信を行う必要があります。また特別な理由がない限りは HTTPS でアクセス可能なページは、HTTP でのアクセスを提供しないことが望ましいでしょう。

発注者のためのWebシステム/Webアプリケーションセキュリティ要件書, 株式会社トライコーダ, 2009年4月

「特別な理由がない限り」って何? 特別な理由って何? 理由があればいいの? 理由がないときはなぜ提供しちゃいけないの? *2

https:// のはずのページが攻撃者によって http:// にすり替えられることを懸念してのつもりかもしれないが、そんなのは、サーバ側で http:// を止めたところで解決にならない。攻撃者は https:// へ中継するだけだし、中継しないでそのまま偽ページを返してもいい。結局のところ、利用者自身が、見ている画面が https:// になっていることを自力で確認しないかぎり、SSLは機能しない*3のであって、サーバで http:// が稼働しているか否かは関係ない。

こういう似非セキュリティコンサルの指摘を真に受けて守ろうとするとどうなるか。

A社ホームページ http://www.example.jp/ のうち、重要な情報を掲載するページを https:// でも閲覧できるようにと、SSLを導入したとする。https://www.example.jp/important.html というページができることになるが、このSSLページは http:// でもアクセスできることになる。セキュリティコンサルが言う要件に違反してしまう。

こんな本末転倒な話があるか。似非コンサルの戯言など無視して、https:// でも閲覧できるようにするべきだ。http:// で閲覧するか https:// にするかは利用者が選ぶことだ。

このままでは、新幹線車内など公衆無線LANから銀行の電話番号を確認できないわけで、本来、こういうことは利用者がどんどん要望を出していってしかるべきことだ。私も、自分が使っている銀行については、週明けにでも電話で要望したい。

*1 これは、2007年6月29日の日記「サブスクライバーID をパスワード代わりに使うべきでない理由」に書いた。図を再掲しておく。

説明図
通信路上の攻撃者がキャリアのIPアドレスからの任意のサブスクライバーIDを送信する様子
(2007年6月29日の日記「サブスクライバーID をパスワード代わりに使うべきでない理由」の図2より再掲)

「通信路上の攻撃者なんているのか」という疑問に対しては、2008年6月3日の日記「通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか?」で紹介した、さくらインターネットのLAN上でARP spoofing攻撃が発生した事件がその実例にあたる。

*2 あいかあらず上野宣がテキトーなことを書いているわけだが、「特別な理由がない限り○○が望ましい」で通るんだったら、どんな要件だっていくらでも書ける。要件を書く方は何も考える必要がない。

*3 「安全なWebサイト利用の鉄則 / よくある質問と答え」参照。


2010年02月28日

著名優良サイトでもiモード2.0の脆弱性に対応していなかった。なぜか。

今月中旬のこと。私は2テラのハードディスクを買溜めするため秋葉原の街に出た。しかし、どの店が最安か調べずに出たため、やむなく携帯電話で調べることにし、価格.comのサイトを探した。すると、携帯電話用のサイト m.kakaku.com があり、私は初めてそこを使った。

サイトはとても使いやすく、すぐに意中の製品を見つけることができた。が、ここで、画面に「履歴」というリンクがあることに気づいた。「履歴」の画面に入ると、なんと、閲覧した製品が既に記録されていた。ログインしていないのに。いや、アカウントさえないのに。

携帯電話の画面
図1: m.kakaku.com の「履歴」機能

これはたしかに便利な機能ではあるが、契約者固有IDを用いて実現されていることにギョッとした。同様の機能は普通のPCのインターネットでもcookieを使って実現できるわけだけども、契約者固有IDの取得と保管は、個人情報の取得と同程度に慎重さが求められるべきと考えている私にとっては、予告と同意なく記録されたことにギョッとした*1。そして、契約者固有IDがもはやこんな用途にまで使われ始めてしまっていることに落胆した。(加えて言えば、契約者固有IDはちゃんとハッシュ化(鍵付きで)してから使っているのだろうかといった疑問もわくが、これは今回のテーマではない。)

まさか去年夏のはてなのようにオッピロゲってことはあるまいなと、調べてみたところ、ちゃんとIPアドレス制限されていた*2が、これも今回のテーマではない。

ここで私は、1月12日の読売新聞夕刊の記事の件を思い出した。

  • ドコモ携帯、情報流出の恐れ…最新29機種, 読売新聞, 2010年1月12日

    NTTドコモでは、公式サイトを運営する約3000社には注意喚起したが、それ以外の無数にある「勝手サイト」には「ジャバスクリプトの安全な利用はサイトを作る側にとって基本的知識であり、具体的に説明はしていない」という。

カカクコムといえば、CSIRTを整備している数少ない企業の1つで、「Kakaku.com Security Incident Response Team (KKCSIRT)」がある。他の企業よりもセキュリティ脆弱性に関する情報には敏感に対応しているに違いない。NTTドコモが「基本的知識」というくらいだから、カカクコムはこの問題に対応済みだろうか。

それが気になった私は、ホスト m.kakaku.com のIPアドレス 202.218.193.79 を用いて、http://202.218.193.79/ のURLに携帯電話でアクセスしてみた。すると、図2のように、画面にアクセスできてしまった。

携帯電話の画面 携帯電話の画面
図2: 数値形式のIPアドレスのURLで契約者固有IDを用いたアクセスができてしまった様子

履歴を閲覧できていて、閲覧後のURLが http://202.218.193.79/history/ になっている。http://202.218.193.79/history/ から http://m.kakaku.com/history/ にリダイレクトされて表示されたわけではない。図2ではauでテストした画面だが、NTTドコモの端末でアクセスすると、「履歴」のページは「http://202.218.193.79/history/?guid=ON」となり、履歴を閲覧できた。

この結果から、読売新聞の記事の問題に対策していないと推定できる。*3

このままでは、(iモード2.0の携帯電話の利用者は)履歴を他人に見られる危険があるし、このサイトには「かんたんログイン」の機能もあるのだから、それも、なりすましてログイン*4*5されてしまうだろう。

私は、2月18日に、KKCSIRT にメールでこのことを伝えた。すると、その日のうちに、対策したとの連絡があった。m.kakaku.com 以外のホストでは 404 Not Found となるように対策された。*6

さすがは、CSIRTを持つ企業だけのことはある。しかし、そんなセキュリティに敏感な企業でさえ、「契約者固有ID + iモード2.0 + DNS rebinding」で生ずるこの脆弱性に対応できていなかった。

これは、NTTドコモの責任だろう。NTTドコモは、「かんたんログイン」用途で「iモードID」を開始すると自ら発表*7しておきながら、その安全な実装方法について要件を公表していない。

NTTドコモは、新聞紙上で「作る側にとって基本的知識であり」などと、まるでサイト側が自発的に対処するのが当然であるかのように言っているが、それはまったく事実でない。iモードIDのないガラパゴスの外の一般世界では、DNS rebinding の問題は、イントラサイト等で問題になり得るものであって、一般のWebサイトには無用な話である。

同様の事例は、他にもあった。

まだ他にもあるのではないか。これは、NTTドコモの責任で解決にあたるべきことだ。尻は自分でぬぐってほしい。

*1 もっとも、図1の画面に「履歴のクリア・機能停止」というリンクが用意されているように、後から削除することはできるし、「履歴機能を停止」というボタンも用意されている。また、「履歴は登録より30日を超えた情報から消去されます」とある。カカクコムは配慮して設計してくれているのだなと感じるが、本来は、最初に履歴に記録する時点で説明の上の同意を得るべきだと思う。cookieを用いた実装と違って、他の情報と突き合わせることができればサイト運営者はそれが誰なのかを調べることが可能だから。

*2 一般のインターネットからのアクセスでは、「履歴機能はご利用頂けません」「携帯端末の個体識別番号が確認できない場合は、当機能がご利用頂けません」と表示される。ところで、「個体識別番号」という下品な言葉遣いはやめられないだろうか。これはワンクリック詐欺業者が広めた言葉で、「個体」は動物用の言葉であって人間に使う言葉じゃない。「個体」じゃなくて「個人」だろう。

*3 この問題への対策は、m.kakaku.com 以外のホストでのアクセスを拒否することである。もしかすると、m.kakaku.com と 202.218.193.79 の2つを許可しているかもしれないから、確実に対策していないとは断定できないが、まあ、そういう設定をしていることは普通はないので、ほぼ対策していないと推定できる。

*4 正確に言えば、かんたんログイン設定中の本人のブラウザに(罠サイトを通じて)自動ログインさせて、その結果の画面を盗んだり、操作したりする。

*5 価格.comのアカウントを作成してログインしてみたところ、「かんたんログイン」を利用していても、ログイン中に重要な操作(設定の変更など)をする画面に進もうとすると、パスワードが要求されるようになっていた。さすが、よく設計されたサイトだなと思った。それでも、パスワードなしでなりすまされると問題のある機能はあるだろう。

*6 修正済みではあるが、統計用に役立つと思い、IPAの脆弱性届出窓口にも出しておいた。

*7 「『iモードID』の提供開始について」参照。


最新 追記

最近のタイトル

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|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
最新 追記