水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2010年のえび日記 > 2010年5月

2010年5月

2010年5月30日(日曜日)

DPIは誰を幸せにするの?

公開: 2010年6月8日1時15分頃

こんな記事が……「ネット全履歴もとに広告」総務省容認　課題は流出対策 (www.asahi.com)。

この技術は「ディープ・パケット・インスペクション（ＤＰＩ）」。プロバイダーのコンピューター（サーバー）に専用の機械を接続し、利用者がサーバーとの間でやりとりする情報を読み取る。どんなサイトを閲覧し、何を買ったか、どんな言葉で検索をかけたかといった情報を分析し、利用者の趣味や志向に応じた広告を配信する。

DPIは、昔ぷららのWinny規制の時に話題になっていますね。「ぷららのWinny遮断は是か非か（前編） (itpro.nikkeibp.co.jp)」を見ると、Winny規制の方法には3種類あるとされています。通信量だけで規制する総量規制、パケットの流れは見るが中身は見ないフロー・ステ−ト・コントロール。そして、パケットの中身まで解析してWinnyだと分かったものだけ規制するのがDPIです。

そこで登場するのが，(3)のディープ・パケット・インスペクションという手法だ。この方法は，通信パターンやパケットの振る舞い，さらにはパケット内の制御情報やペイロード部分までを見て特定のアプリケーションの通信を識別する方法である。制御とデータ通信を別のコネクションとして実現するFTPやIP電話などは，制御チャネルの内容を解析し，該当する通信のやりとりを識別することまでやってのける。

(～中略～)

ただしこの方法には，制御チャネルとはいえ，その内容を解析することが「通信の秘密の侵害」になるのではないかという問題が残る。

以上、ぷららのWinny遮断は是か非か（前編） より

Winnyかどうかという判別を行うだけでも「通信の秘密の侵害」が問題視されていたわけですね。それなのに、今回は通信内容を読んで広告に使いたいという話なのですか……。

作業部会に参加した一人は「総務省の事務方は積極的だったが、参加者の間では慎重論がかなり強かった。ただ、『利用者の合意があれば良いのでは』という意見に反対する法的根拠が見つからなかった」と話している。

以上、「ネット全履歴もとに広告」総務省容認　課題は流出対策（2/2ページ） より

利用者が同意していれば良い……って、理屈はそうかもしれませんが、どうやって「合意」を得るつもりなのでしょうね。誰も読まないような長文の利用規約に潜り込ませるとか、そんな方法では利用者が本当に理解して合意しているとは言えないと思うわけで。

それはそれとして、こういった技術がクローズアップされてくると、通信を暗号化するニーズが増えてきそうです。今までは主に入力フォームだけをHTTPSで保護するやり方が一般的でしたが、「当サイトはプライバシーに配慮し、全ての通信をSSL/TLSで暗号化しています」なんて宣言も出てきそうですね。

それはそれで問題ないのですが、全てのコンテンツをHTTPSにすれば、サーバ側の負荷は確実に上がります。ハードウェアへの追加投資が必要になる場合もあるでしょう。ISPは高価な機器を買ってDPIを行う、サイト側はそれに対抗してハードウェアに投資する……って、まあ、別に良いのですけど、そのコストは誰が負担するのですかね。

いったい誰が幸せになるのか、良く分かりません……。

関連する話題: Web / セキュリティ

2010年5月28日(金曜日)

はとがいる

公開: 2010年6月6日23時20分頃

久々のジャケ買い。

「はと」とカレーのマンガ。白ははとが嫌いなのだけど、はとは白が大好き。しかしよっちゃんに片付けられる。そんなマンガです。

しかし、はとが凄い。日常生活で鳩を見る目が変わってしまう……。

関連する話題: マンガ / 買い物

Yahoo!ケータイはスクリプト無効を推奨、PCサイトブラウザも

公開: 2010年6月6日22時10分頃

ソフトバンクからこんな案内が出ていますね……「ブラウザのスクリプト設定について (mb.softbank.jp)」。

弊社携帯電話の下記の機種にて、Yahoo!ケータイまたはPCサイトブラウザご使用時の設定の一つであるスクリプト設定(JavaScript) を有効にした状態で悪意あるサイトを閲覧した場合に、情報の詐取が生じる可能性があることが確認されました。

お客さまにおかれましては、安全の為、携帯電話のスクリプト設定をOFFに変更していただけますようお願い申し上げます。

スクリプトを無効にするように指導されています。無効化の方法も案内されていますね。

スクリプト設定の変更は下記をご参照ください。

■Yahoo!ケータイの場合

「Yahoo!ケータイ設定」→「セキュリティ設定」→「スクリプト設定」

■PCサイトブラウザの場合

「PCサイトブラウザ」→「PCサイトブラウザ設定」→「セキュリティ設定」→「スクリプト設定」

基本的には徳丸さんが公表されたXMLHttpRequestの脆弱性への対応なのではないかと推察しますが、注意深く見ると2点ほど気になる点があります。

Ajax無効ではなくスクリプト無効

徳丸さんが公表された内容では、攻撃にXMLHttpRequestが必要です。DNS Rebinding自体はJavaScriptとiframeでも可能ですが、iframeを使う方法では攻撃者がHost:の値を変更することができません。ですから、Ajaxだけが問題となります。

私が知る範囲では、XMLHttpRequestに対応したソフトバンク端末には、スクリプトの設定の他に「Ajax」という設定があり、XMLHttpRequestだけを無効にすることができます。JavaScriptを無効にする必要はなく、Ajaxを無効にするだけで問題を回避できるはずです。

にもかかわらず、ソフトバンクからの案内はAjax無効ではなく、スクリプト無効となっています。さらに注意深くリストを見ると、Ajaxに対応していない端末も含まれています (たとえば811SH)。

PCサイトブラウザのスクリプトも無効

ケータイのブラウザだけでなく、PCサイトブラウザ (いわゆるフルブラウザ) のスクリプトも無効にするように案内されています。

DNS Rebindingの問題を受けるのは、契約者固有番号による、いわゆる「かんたんログイン」を実装しているサイトです。通常のPCサイトはCookieを使っていますので、攻撃者のドメインでDNS Rebindingが行われても、認証を突破することができません。つまり、ほとんどのPCサイトはDNS Rebindingの攻撃の影響を受けません。

にもかかわらず、ソフトバンクからの案内ではPCサイトブラウザのスクリプトも無効にするように指導されています。

なぜAjax無効ではなくスクリプト無効なのか、どうしてPCサイトも対象なのか……。

前者については、DNS Rebindingへの対応ができていない (Host:を改変しなくても攻略できてしまう) サイトに配慮したと考えることもできそうです。ただし、それだけでは後者の説明がつきません。まだ隠し玉がある (twitter.com)のかもしれない、という推測も成り立ちますね。

※そのうち追記するかも。

関連する話題: セキュリティ / モバイル / secure.softbank.ne.jp

2010年5月27日(木曜日)

空の下屋根の中 2

公開: 2010年6月6日16時0分頃

購入。

ニートマンガ(?)の2巻。1巻ではアルバイトを初めて「ニートじゃないじゃん!」という感じになりましたが、2巻でまさかのニート逆戻り。いや、ニートではないのか……?

これで完結っぽいですね。

関連する話題: マンガ / 買い物 / 空の下屋根の中

2010年5月26日(水曜日)

Twitterのパスワードを入れさせるUNIQLO LUCKY LINE

公開: 2010年6月6日15時35分頃

Twitterで「UNIQLO LUCKY LINE」というサービスが話題になったようで。関連するつぶやきが以下にまとめられています。

※ちなみにタイトルはパスワードが漏れているという意味ではなく、パスワードが本当に本物サイトに送られるのか、送られた後どう扱われているか、といったことを確認するすべがないという意味です (たぶん)。

UNIQLO LUCKY LINEは、Twitterユーザーが店の前に並んで「行列」をつくることができるというサービスで、並ぶと何人かに一人の割合でクーポン券やTシャツがもらえます。このサービスは当初、以下のように動作していました。

また、Flashで行列を表示する際には http://uniqlo-happy-line.s2factory.co.jp/system/data/heads400_tails400.txt にアクセスし、行列の先頭400人、最後尾400人分のTwitterアカウント名、つぶやき文などを取得します。

複数の問題が絡み合ってややこしいのですが、整理すると、ポイントは4つあります。

行列しているユーザのIDのリストが取得できる

http://uniqlo-happy-line.s2factory.co.jp/system/data/heads400_tails400.txt にアクセスすると、行列しているユーザのIDのリストを取得することができました。これはFlashで行列を表示するのに必要なデータです。

これは特に問題ではないと思います。あえて言うなら、行列しているユーザーのIDを一気に取得できるので悪用される可能性がある……というところでしょうが、行列しているユーザのIDは普通に表示されているわけで、もとより公開されている情報です。単に、簡単にリストが取れるか取れないかという違いでしかないでしょう。

※なお、パスワードが公開されているという噂が流れたようですが、このリストにはパスワードは含まれていませんでした。「IDのリストが公開されている」という話が、伝言ゲームで「パスワードのリストが公開されている」に変わったのでしょうか?

HTTPSではない画面でパスワードを入力させている

パスワードを入力する画面がHTTPSではないため、私が見ているこのサイトが本当にユニクロのものであるという保証がありません。攻撃者によって改竄された偽サイトを見せられている可能性があります。その場合、パスワードは攻撃者のところに送られるでしょう。

ユニクロと関係ないドメインにパスワードを送信している

一般の利用者には確認するすべがありませんが、入力されたパスワードは uniqlo-happy-line.s2factory.co.jp というサーバに送られています。s2factory.co.jp というドメインはユニクロのものではありません。他サイトにパスワードを送るのはどうなのでしょうか?

ここでユニクロのプライバシーポリシーを確認したいところです。トップページのフッタには「プライバシーポリシー」というリンクがあるのですが、リンク先はhttp://faqnavi12a.csview.jp/faq2/userqa.do?user=frgroup&faq=uniqloec&id=5139&parent=3866 (faqnavi12a.csview.jp)というURLになっています。このドメインcsview.jpがまたしてもユニクロではありません……(調べるとNECの所有になっています)。

なんだかよく分かりませんね。もっとも、前述のようにHTTPSではありませんから、私が見ているコンテンツは改竄されている可能性があります。本来はユニクロのドメインにパスワードを送信するようになっているのに、コンテンツが改竄されて別ドメインに送信するように改造されたSWFを受け取っていた……という可能性も否定することはできません。

他サービスのパスワードを入力させている

これが最大にして根本的な問題です。そもそも、他サービスのパスワードを自サイトで入力させようとしていること自体が問題です。

以前にもnwitterというサービスが現れて批判の的になりましたが (高木浩光＠自宅の日記 - 「nwitter」の違法性について考えてみる (takagi-hiromitsu.jp))、当時はまだOAuthの仕組みがなかったため、仕方ない面もありました。しかし、今ではOAuthが使えるわけで……。

そもそも、このサービスで本当にTwitterのパスワードを取得する必要があったのかどうかも疑問です。

さて、そんなUNIQLO LUCKY LINEですが、26日のうちにプレスリリースが出ました。

行動が早いのは良いと思うのですが、「漏れていません」と宣言して終了というのはどうなのでしょうね。まあ、期間限定のキャンペーンサイトなのですから、いまさらOAuthで作り直すというのもナンセンスですけれど。

関連する話題: Web / セキュリティ / Twitter

岡崎市立中央図書館のDoSで逮捕者

公開: 2010年6月5日22時15分頃

こんな記事が……「図書館ＨＰにアクセス３万３千回　業務妨害容疑で男逮捕 (www.asahi.com)」。

県警生活経済課と岡崎署によると、中川容疑者は、４月２日から１５日にかけて、岡崎市立中央図書館のホームページに、計約３万３千回のアクセスを繰り返し、ホームページを閲覧しにくい状態にした疑いがある。

同図書館のホームページ管理用サーバーには、３月中旬からの約１カ月間に、中川容疑者の自宅のパソコンなど特定の端末から計約６万４千回のアクセスがあり、その影響でホームページの閲覧は２１回停止されていた。

14日間で3万3千回のアクセス、6万4千回で21回の停止……って、1回あたり3,000回くらいのアクセスで死んでいる計算ですね。まあ、悪意を持って攻撃をしたのなら犯罪だというのは分かるのですが、それにしても、サーバ弱すぎませんか?

※ちなみに、bakera.jpは同一IPアドレスから1日に106,146回のアクセスを受けたことがあります。参考までにそのときのログ (16MB以上あるので注意!) : dos20070407.txt

同課によると、中川容疑者は１回ボタンを押すだけで、１秒に１回程度の速度でアクセスを繰り返せるプログラムを作っていたという。中川容疑者は同図書館の利用者だったが、目立ったトラブルは確認されていないといい、動機を調べている。

はあ。1秒に1回って、昔の某サーチエンジンのクローラと変わらないですね。というか、サーバを殺しに行くのならもっと激しくアクセスすると思うわけで、むしろサーバが死なないようにウェイトをかけているように思えますが……。サーバの死因も、逮捕された経緯も良く分からないですね。

関連する話題: Web / セキュリティ / 岡崎市立中央図書館事件 / librahack

2010年5月25日(火曜日)

エンジャパンから情報の漏洩?

公開: 2010年6月4日12時10分頃

エンジャパンの関連サイトから個人情報が流出したという話が出ているようで。

正確には、提携先の「EmPro-Aid　First」というサービスからの漏洩のようですね。

このたび流出が確認されたのは、弊社がウィルソン・ラーニング ワールドワイド株式会社との業務提携により、販売代理店として取扱っている採用管理システム「EmPro-Aid First」を利用して、新卒採用活動を行っている企業に応募された 9名の方に関する情報です。情報の流出原因は特定できていますので、現在、セキュリティー強化に向けての対策を講じています。

以上、個人情報漏洩に関する報道についてのお知らせ より

そのウィルソン・ラーニング ワールドワイドからは、「情報漏洩に関するお知らせおよび今後の対策について」というPDF文書が公開されていて、漏洩の原因は以下のように報告されています。

2. 原因

EmPro は、学生一人ひとりを識別できるように個別ＵＲＬを作成し、学生に対する利便性を高めるたに、個別ＵＲＬからの自動ログイン機能を実装しておりました。文字列の変更により個別ＵＲＬが容易に類推できる状況ではなかったことから、こ れまで情報漏洩は起こっておりませんでした。今回発生した情報漏洩に関して調査をしましたところ、以下の原因が判明しました。

１．登録学生による個別ＵＲＬの意図的もしくは不注意による公開

２．検索エンジンによる個別ＵＲＬのクローリング

個別ＵＲＬは登録学生にのみ送信する設計となっておりますが、上記１または２の手段で入手した他人の個別ＵＲＬを掲示板サイトユーザーが本人の許可なく掲示板サイトに掲載したことにより一部個人情報がインターネット上に公開されておりました。

以上、情報漏洩に関するお知らせおよび今後の対策について より

どうも、認証をすっ飛ばしていきなりログイン後画面にアクセスできる秘密のURLが存在していたようです。そのURLが意図的に、もしくは不注意によって公開されてしまったことが漏洩の原因のようで。

調べてみると、2chの就職関連の掲示板で、企業から来たメールの内容を貼った人がいたようですね。貼られたのはこんな感じの内容でした。

王将の会社説明会を開催いたします！

席に限りがありますので、お早めにお申込ください。

●「王将フードサービス 会社説明会」

多くの大手企業が赤字に苦しむ中、業績好調な王将フードサービスの強みを採用担当がお伝えします。

*～～*～～*～～*～～*～～*～～*～～*～～*～～*～～*～～*～～*～～*～～*

▼セミナーのお申込はこちら

https://eform.jp/u/?p=59682f9cwbebe808xc5352b2y37

セミナーでお会いできることを採用担当一同、楽しみにしています。

以上、【今年は】 2011卒専用スレ163 【諦める？】 より

この、「セミナーのお申込はこちら」というURLが、問題の秘密のURLです。当時は、このURLにアクセスするといきなりログイン後画面に行けてしまったようで。

……しかし、このメールの書き方では、このURLを公開するとマズイという気配は感じられませんね。「意図的もしくは不注意による公開」と言っていますが、そもそも、このURLを公開してはならないということが伝わっていない (伝えようともしていない) のではないでしょうか。だとすれば、学生の責任を問うのは筋違いでしょう。

「検索エンジンによる個別ＵＲＬのクローリング」というのも的を外した話で、そもそも、このURLが2chに貼られた時点でまず人間がアクセスしているわけです。それを防がなければ駄目でしょう。

ともあれ、以下のような対策が挙げられています。

・EmPro 利用時における個人認証チェックの導入

仕様の変更後は、EmPro 利用時に、学生個人別に発行したＩＤ・パスワードを活用してログインする形式にいたします。

以上、情報漏洩に関するお知らせおよび今後の対策について より

要するに、URLが叩かれたら認証するということですね。それが普通だと思います。妥当な対策だと思いますが……対策がこれで良いのだとすると、原因は「認証していなかった」という一言で済むと思うのですけどね。

関連する話題: Web / セキュリティ / プライバシー

2010年5月24日(月曜日)

マンガが子供に与える悪影響とはなんだろう?

公開: 2010年6月4日11時20分頃

「親は心配していない？ - 小原篤のアニマゲ丼 (www.asahi.com)」という記事が。

日本ＰＴＡ全国協議会の調べによると、小中学生の親たちはマンガが子供に与える悪影響について大して心配していないし、条例などによる規制も望んでいないことが分かりました。

(～中略～)

「メディア接触の問題点」として「性的・暴力的な描写の多い書籍等が子どもの目にふれる所に置いてあるのは好ましくない」（解説と詳細結果では微妙に文面が違います）という親が８７．２％いて１位になった点ですが、これは文面にその理由があると思います。「好ましくない」がポイントですね。

(～中略～)

逆に１位の文章が「性的・暴力的な描写の多い書籍等が子どもの目にふれる所に置かれていないか心配だ」だったら？

要するにこのアンケートの文言は、「子どもの目につくところにエロ本があって困るよね」という状況を指しているものではなく、「子どもの目につくところにエロ本があるのはよくないことだよね」という至極当たり前の価値観を語っているので、「そう思う」回答が多くなるのは至極当然と言えるでしょう。

「目にふれる所に置いてあるのは好ましくない」は、「目にふれる所に置いてあるから好ましくない」と言っているわけではなくて、単に「目にふれる所に置いてあったとしたら好ましくない」と言っているに過ぎず、現実問題として目に触れるところに置いてあるかどうかは別の話だと言うことですね。まあ、そりゃそうでしょう。

ところで、この手の話を聞くといつも思うのですが、「悪影響」を心配する親のみなさん自身は、未成年のうちに「性的・暴力的な描写の多い書籍等」に触れた経験があるのでしょうか。もし経験があるのだとしたら、その経験で自分が悪い影響を受けたと考えているのでしょうか。

私が中高生の頃は、先生に見つかるとまずいような本を教室に持ち込む生徒がいて、クラス内でそれが回し読みされる……という光景は普通にありました。私はまあ、持ち込みはしませんでしたが、回ってきたものを見たことが全くないと言い切れるのかと問われると、やや苦しい立場です。しかし、それで悪い影響を受けたとは思っていないのですよね。

「悪影響」を心配する方々は、この辺りをどう感じていらっしゃるのでしょうか。

関連する話題: マンガ / 思ったこと

Yahoo!ケータイのXHRでHost:チェックを突破できる話

公開: 2010年6月4日1時25分頃

WASForum 2010 で発表されたソフトバンク端末の脆弱性ですが、文書として公開されました……セキュリティ情報 - Yahoo!ケータイの一部端末に「かんたんログイン」なりすましを許す問題 (www.hash-c.co.jp)。

以前に公開された「iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 (www.hash-c.co.jp)」は、かんたんログインを使っているサイトがDNS Rebindingで攻撃されると認証を突破されてしまうという問題です。このとき公表された対策は、「Host:の値を見る」というものでした。DNS Rebindingの攻撃では、HTTP要求ヘッダのHost: の値が攻撃者のドメインになりますので、サイト側でHost:の値をチェックすれば対応できます。

しかし、この対策が有効となるためには、XMLHttpRequestでHost:の値が変更できないという前提が必要です。Host:の値が変更できる場合、攻撃の際にHost:の値を正しいドメインに変更することができますので、Host:を見る対策は簡単に突破されてしまいます。これでは打つ手がありません。

そして、徳丸さんの調査によって、ソフトバンク端末ではこれができてしまうことが分かったわけですね。

そもそも当初、この問題の影響を受けるのはdocomoのiモードブラウザ2.0端末だとされていました。昔のケータイ端末はJavaScriptに対応していませんでしたが、docomoのiモードブラウザ2.0が初めてJavaScriptとXMLHttpRequestに対応し、そこで初めてこの攻撃が可能になった……と、思われていたわけです。

ところが、実はソフトバンク端末はそれよりも早く、ひっそりとJavaScriptとXMLHttpRequestに対応していたのですね (参考:ソフトバンク端末がAjaxに対応?)。この対応は非公式なもので、あまり知られていなかったため、問題として認識されていなかったと。サイト側の安全性にも影響するような機能なのですから、もっとちゃんと公表してほしいところですね……。

上記内容は2009年11月24日に発見した事実を基本としたものである。発見者は即座にソフトバンク社に通知したが、半年を経過してなお状況が改善されず、注意喚起もされていないことから、Yahoo!ケータイ利用者の安全性確保を目的として公開するものである。

……。ソフトバンクの場合、twitter で @masasonさんにつぶやくと対応してもらえることがあるらしい……という噂を小耳に挟みました。試しに「御社からも対応を働きかけていただけますでしょうか? (twitter.com)」とつぶやいてみましたが、はてさて。

関連する話題: セキュリティ / モバイル / Twitter

2010年5月23日(日曜日)

きみといると 3

公開: 2010年6月4日0時20分頃

いつまにか出ていたので購入。

「下の名前を呼ぶ」というミッションを経て、ついに彼女宣言へ。うむむむむむ。

関連する話題: マンガ / 買い物 / きみといると

2010年5月22日(土曜日)

WASForum Conference 2010: クロージングディスカッション 脆弱性対策至上主義からの脱却

公開: 2010年6月4日0時10分頃

WASForum Conference 2010、Live IDの話の後は最後の最後、クロージングディスカッション。壇上には三井物産セキュアディレクションの国分裕さん、テクマトリックス株式会社の酒井喜彦さん、そして司会は株式会社テックスタイルの岡田良太郎さん。席からはスピーカーの門林さん、松岡さん、高木さんが乱入する形となりました。

以下は、話された内容の一部を断片的にメモしたものです。敬称は略させていただいています。正確性はいまいちな上に、途中ところどころ飛んでいますのでご注意ください。

国分

昔からすると変わってきている。昔は自前で全部やっていたが、最近は外のサービスと連携したり、複数サイトにまたがったり、新たな考え方が今後必要になってくる。

酒井

企業サイトのマッシュアップは進んでいない?

これから対策しなければならなくなる話。伝えていかなければならない。

岡田

今日の話は脆弱性検査で指摘する範囲に含まれる?

国分

指摘している。設計に起因する問題も指摘している。かんたんログインも。

岡田

反応は?

国分

なかなか厳しい。「分かるんだけどユーザからのニーズがあるし……」と言われることが多い。やめることを検討しているお客様もいるが、さまざま。

そもそも、脆弱性検査を頼んでくるところは意識が高い。Cookie対応など、どんどん言っていってもらいたい。

門林

クライアント証明書は使われている?

属性を入れたりいろいろなことができるはずだが、そういう使い方を見たことは?

国分

使っているサイトはあるがIDのかわりにとどまる。属性まで使っているところは見たことがない。

門林

暗号学者からするとCookieも論外。暗号化されていないから。

ソフトウェアのへたくそなつくりを指摘→直れば立派、というのはそろそろ……。

国分

設計思想によって脆弱性がある、というのは被害につながるので指摘はしている。

岡田

2～3年前、雨後の竹の子のように不良検査会社が出てきた。その後どうか。

国分

ツールによる検査だけで良いサイトもある。そうではなくてしっかり見てほしい、というサイトもある。顧客も二極化している。

岡田

ものを作る立場としてどうか?

酒井

うちではAppScanがメイン。構築の方も見ているが「やっていただきたい」。今日聞いた話をいかにしてお客様に伝えるか。

ぜひ資料配付をお願いしたい。来てないけど資料で分かる、ということはあんまりない。バズワードが面白かったね、で終わらせたくない。

高木

Cookieが駄目と言われたが、SSL/TLSも一緒。CookieのポイントはJSから触れるという点だけで、やり方としては普通。

門林

ケータイは物理的なセキュリティに立脚している。ケータイを持った人を本人扱いにしてしまう。認証に重要な要素をスルーしている。だから5歳の子どもが父のケータイでゲームコンテンツを購入してしまう。誰がどう責任を取るのか。ビジネスとして考えなければならない。そこも含めてのエコシステム。

高木

ソフトバンクでは、課金の時に暗証番号を入れていたのが省略されるようになった。初回アクセスで包括認証というのは無茶ではないか。総務省研究会で問題にすべき。auも入力を省略できるようになった。リアルの契約と電子契約は違う。暗証番号によって「買う」と意思表示していたはず。これでは架空請求の餌食になる、なんとしても元に戻すべき。

門林

総務省の研究会はポリシー論だけで結論を出して終わっている。国がやれば良いじゃないか、というのも問題。インターネットにも様々な問題がある。spam、ボットネットなど。ケータイでも時間差で同じ事は起きる。かんたんログイン、透明でない仕様……情報が出てこないので専門家はどうしようもない。商用サイトも含めて検査をされている会社こそ出せる統計情報があるのでは?

ここでもやはりかんたんログインの話が。

クロージングと言いつつあんまりまとめになっていませんでしたが、それはそういうものということで。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: SDL脅威分析の方法とWindows Live IDにおけるアプローチ

公開: 2010年6月3日0時45分頃

WASForum Conference 2010。Web2.0(ツーオー)の次は最後のセッション、「SDL脅威分析の方法とWindows Live IDにおけるアプローチ」。スピーカーはMicrosoftのJiong Luさん、お話は英語で通訳付きでした。

脅威モデル
脅威の"STRIDE"
  • Spoofing (なりすまし)
  • Tampering (改竄)
  • Repudiation (否認)
  • Information disclosure (情報漏洩)
  • DoS (サービス拒否)
  • Elevation of priviladge (権限の昇格)
脅威モデルのサンプル

シンプルな1ページのみのメールフォームの例。

  • 他人のメールアドレスを入れる …… Spoofing
  • 他人がそのメールアドレスを入れてデータを上書きできる? …… Tampering
  • Repudiation のリスクは無し
  • Information disclosure もリスクゼロ
  • DoS……
Live ID

……

……ありのまま今起こったことを話すと、手元のメモがここでぷっつりと途切れているわけですよ。この後はWindows Live IDの話が続いていたはずなのですが、メモが跡形もなく。

印象に残ったのは通訳の方で、この方がまたマニアックな脆弱性関連用語をさらっと訳したりしておられたわけですよ。事前の読み合わせなどもされているのでしょうが、それにしても凄いと思いました。

セッションはこれで終わりですが、最後に締めのディスカッションがあります……「クロージングディスカッション 脆弱性対策至上主義からの脱却」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: "Web2.0" におけるセキュリティ ～ セキュアなWeb2.0環境の構築とは

公開: 2010年6月1日1時30分頃

WASForum Conference 2010、OAuthの話の次は、日本IBMの吉濱佐知子さんによる「"Web2.0" におけるセキュリティ ～ セキュアなWeb2.0環境の構築とは」というお話。吉濱さんはWASForum初の女性スピーカーなのだそうです。

※全体的に話の流れが非常に速く、ほとんどメモが取れませんでした。以下、メモは断片的です。

Web2.0におけるセキュリティ
  • Webアプリケーションの脆弱性は依然として多い
  • Web2.0(ツーオー)の特徴……Ajaxによる非同期アクセス、MashUp
  • Same-Origin Policyを破るコンテンツ …… サイト運営者が用意したものではないUGC (user-generated content、ユーザが投稿したさまざまなコンテンツ) や JSONP による外部ドメインコンテンツの取り込み
脅威の発生経路
  • T1: 通信チャネルに対する脅威 …… 通信傍受、改竄。Ajax通信の部分だけHTTPSになっていない、といった破れ
  • T2: HTTPクライアントからサーバに対する脅威 …… インジェクション攻撃
  • T3: 攻撃者サーバからユーザへの脅威 …… フィッシング、Typosquatting(有名ドメイン名の打ち間違いを狙う)、Pharming(?)
  • T4: クライアント側のインジェクション …… 悪意あるマッシュアップ。たとえば、広告スペースの又貸しによって、有名サイトに悪意ある広告が出現するなど

※他、いくつかあった模様ですがメモしきれず。

Googleの事例
  • Google docsのXSS
  • 他のサービス全てに対してセッションハイジャックのおそれ
XSSの難読化
  • img要素のjavascript:スキーム
  • JavaScriptの途中に改行やNUL文字を挿入
  • %xx形式
  • <meta url=data:text/html;base64>
  • 数値文字参照、 &#x0000000000001; のような冗長な書き方
  • charset=US-ASCIIのとき、8bit目を無視するブラウザが存在
  • charsetに未知の値 (たとえばcp932) が指定されたとき
  • DOM-based XSS
  • Cross-Site Image Overlay …… コンテンツ内のリンク付き画像のpositionを調整して正規のロゴ画像にかぶせたり
  • Cross-Site Flashing ……ActionScriptの getURL() に外部パラメータをまんまインジェクションできるケース
  • jarプロトコルハンドラ …… jar:https://example.com/a.jar!/b.html のようにするとjar内のコンテンツが参照できる。jarはZIPなので、ZIPが置けるサービスに使用すると……。
  • GIFAR …… 画像として妥当だが、jarとしてもアクセスできるファイル
  • javascriptハイジャッキング …… メソッドを上書きして外部JSを呼んだり
T6: ユーザのPCに対する脅威
  • ローカルネットワークに対する攻撃
  • JavaScriptによるポートスキャン
  • Cross-Site Printing
  • CSRFによるルータ設定変更

基本的には手法などの紹介なのですが、展開が非常に早くてメモが全く追いつきませんでした。前のセッションが長引いていたので仕方ないと思いますが、もう少しゆっくり聞きたかったところですね。

紹介されていたものの中では、jarを使った攻撃手法が印象的でした。このパターンはあまり見たことがないので、少し調べてみたいですね。他の手法はおおむね既知だったり……あとは、「クロスサイト」という名前がやたら多い割に、内容がクロスサイトとは言いにくいものが多かったような気がします。海外ではクロスサイトという名前が好まれているのでしょうか?

しかし、やはり最も印象に残ったのは "Web2.0(ツーオー)" ですね。会場でも多くの人が感銘を受けていたようで、Twitterでもしばらく「ツーオー」の話が流れていました。

あとちょっとだけ続きます……SDL脅威分析の方法とWindows Live IDにおけるアプローチ

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: OAuthとWEBサイト運営のエコシステムに潜む罠

公開: 2010年6月1日0時30分頃

WASForum Conference 2010、高木さんのセッションが延びてしまって開始予定時間を大きく過ぎたところで、トライコーダ上野宣さんによる「OAuthとWEBサイト運営のエコシステムに潜む罠」。

自己紹介
エコシステムの中核は認証と認可
エコシステム
  • エコシステム = 生態系の意味、特定の業界の収益構造を指したりもする
  • 他のWebサイトとの連携で生態系が成り立つ、Googleなど
エコシステムが成り立つために
  • コンテンツ、サービスの提供
  • マッシュアップ、APIの提供
  • ユーザーの特定をしたい
  • ユーザー固有のコンテンツと連携したい
  • twitter連携など、多くは認証後に認可まで行う
認証と認可
  • 認証 = authN(authentication) / 本人確認
  • 認可 = AuthZ(authorization) / リソースへのアクセス権の付与
どうやって他サイトのリソースのアクセス権を得るか

認証情報を預ける? UserID/Passを預ける → 認証、とするのは簡単だが……。

  • 連携サイトに平文でIDとパスワードを送付する必要があるため、預けたサイトでは平文で (少なくとも復号可能な形で) 保存される
  • 他のサイト、他の管理者によって管理される。不正アクセスに使われる可能性も
Basic認証によるAPI連携
  • ID、バスワードが平文で送られる (Base64エンコードされているが簡単に読める。たとえば JavaScript の window.atobメソッド)
  • ログアウトがない (一度でもブラウザからAPIを叩いてBasic認証のパスワードを入れてしまうと、容易に攻撃される)
OAuth
モバイルOAuth
  • アクセストークンの有効期限はデフォルト無し
  • ガラケーだと「拒否」「許可」が「送信」「送信」に化ける
OAuthを使っていないサイト
  • USTREAM
  • twiike (Nike + twitter)
  • つぶやきタカ
OAuth1.0の脆弱性
  • リクエストトークンを使ったセッション固定攻撃……攻撃者がリクエストを出し、承認確認URLを利用者に踏ませる
  • アクセス権の委譲を許可したユーザとアクセストークンを取得させるユーザーが同一かどうか確認していない
  • 委譲同意確認後に乗っ取り

修正:OAuth1.0a……コールバックのURLをユーザーのブラウザを介さない経路に変更

OAuthなんて誰も知らない?
  • 異なるドメイン・サービスにIDやパスワードを入れてはならない (入れさせてはならない)
  • しかし、OAuthの画面が出ても、何を言っているのか分からない (UIやメッセージが分かりにくい)

とまあこんな感じでOAuthの話でしたが、全体的には入門的な内容で分かりやすかったと思います。もっと先にこのセッションを持ってきても良かったのではないかと思いました。

部分的に少し説明不足かな、と感じるところもありましたが (たとえばBasic認証の危険性のあたり)、これはセッションハイジャックの影響も大きいでしょう。

続きます……"Web2.0" におけるセキュリティ ～ セキュアなWeb2.0環境の構築とは

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: どうするケータイ認証

公開: 2010年5月31日0時45分頃

WASForum Conference 2010、ソフトバンクの脆弱性の話に続き、産総研の高木浩光さんによる「どうするケータイ認証」。

ケータイWebの世界

従来、WASForumではあまり扱ってこなかった分野。その理由は……

  • 独自方式、仕様が明確でない
  • NDAの壁 (特に公式サイト)
  • 契約で縛った独自世界なら、キャリアが責任を持つべき。部外者は何かを言うべき立場にない

しかし、昨今では……

  • ケータイ独自方式が一般サイトにまで侵出
  • 2008.3 iモードIDがスタート
  • スマートフォン対応の活発化
ログイン認証の欠陥
  • ID (契約者固有ID) による認証を JavaScript + DNS Rebinding で突破される問題
  • 海外ではあまり問題にならない
  • DNS Rebindingという手法は古くから知られていたのだが、そんな認証は日本でしか使われていないため、海外では問題になりようがない
    • iモードIDを使った認証がDNS Rebindingで突破される件、2010年1月4日に読売新聞の記事となる
    • その際のdocomo広報の言い分: JSの危険性は皆さんご存じのとおりであり……?

※正確には、読売に載ったコメントは「ジャバスクリプトの安全な利用はサイトを作る側にとって基本的知識であり、具体的に説明はしていない」というものだったようです。この話では攻撃者がJavaScriptを使うことを想定しているので、安全な利用も何もないのですけどね……。

欠陥の例
  • サイボウズOffice (JVN#87730223 (jvn.jp))
  • OpenPNE JVN#06874657 (jvn.jp))
  • はてな、日経就職ナビ、などなど……

これらは、そもそもIPアドレスの制限をしていなかった (DNS Rebinding以前の問題)

ケータイIDによるログイン認証

ケータイID (契約者固有ID) の利用によるログイン認証、IPアドレスを制限していればOK?

OpenPNE2.14の事例
  • 携帯キャリアのIPアドレスをプログラム中にハードコード
  • 対応キャリア: docomo、au、softbankに加えて EMnet (EMobile)
  • IPアドレス制限の処理、ログイン判定に使用するとID抽出の処理は、別々のモジュールで行われていた

攻撃シナリオ …… EMnetで接続し、他社のケータイIDを送信すると突破される。

誰の脆弱性なのか?

この問題は誰の責任なのか?

EMnetのProxyの動作
  • EMnetのProxyはX-EM-UIDを挿入
  • 既に (偽物の) X-EM-UIDがついている場合は、それを消して上書きする
  • 他のヘッダについては関与しない。他社のIDを示すヘッダがあってもスルーしてしまう
他社のIDを削除しないから悪い?

EMnetのProxyが他社のIDを削除するべき?

  • どうやって削除するのか?
  • 他社が新たなIDを創設するたびに対応する?
  • X- で始まるフィールドを全て削除する?

いずれも現実的ではない。

従って、Webサイト側の脆弱性ということになる (いわざるをえない)。

無責任な解説の蔓延
  • ケータイIDによる認証の方法には公式な解説がない
  • 一方、素人のずさんな解説が蔓延している
  • 典型的な解説 …… アクセス制限は .htaccess で処理、ただし ENnet や Googlebot などは通す。アプリでID取得
EMnetだけの問題ではない

Softbankにも同様の問題

  • 2009年夏にblog界隈でささやかれていた話
  • 海外製端末向けAPNにダイヤルアップし、Proxyサーバを経由するとSoftbank携帯のIPアドレスになる
  • X-JPhone-UIDを削除した上で本物を付与する (なりすまし不可)
  • それ以外のヘッダには関与しない
  • User-Agentの中の端末シリアル番号は書き換えないため、なりすまし可能 (そもそも書き換え困難。端末シリアル番号を含む User-Agent の書式は仕様はBNFで定義されているでもなく、いかにも日本人的な「何となく」のものでしかない)
  • ただし、User-Agentが所定のもの以外ならアクセスが拒否される。Softbank以外のUAを拒否しているものと思われる
User-Agentの判定を突破
  • 後ろにつけた文字列は無視される。例: User-Agent: Softbank...KDDI-
  • アプリのロジックによっては突破され得る
  • CGI RESCUEの「会員制携帯サイト簡単ログイン」がこの手法で突破可能だった
誰の責任?
  • これはWebアプリ側の脆弱性なのか?
  • キャリアは公式情報を公表していない
  • 何をどこまですればよいのか不明。X-JPHONE_UIDが通るとか……きりがない。
IPアドレス別のキャリア判別なら安全?
  • キャリアから正式に公表されているわけではない
  • 公式サイト向けにはある?「当該ケータイIDを使用する際には当IPアドレスから……」という記述があるのではないかと想像
  • キャリアは他キャリアのことは考慮してくれない。3キャリア連携の都合などは知ったことではない
SSL接続で出たID
  • end-to-endのSSL接続で送信された任意のIDはそのまま届く (Softbank, EMnet)
  • https: の機能を提供していないつもりでも、稼働している場合があるので注意
不確実なIPアドレス制限

キャリアが出している「IPアドレス帯域」の情報

  • https:での取得が出来ない
  • 機械的に処理できないカタチでの提供
  • 保証しない(あくまでも目安)という宣言
  • 誰も信頼あるシステムを構築しようとしない
  • Google日本法人もblogで公表する体たらく
  • サイボウズOfficeはさじを投げた (「お客様で制限してください」と注意喚起する以上のことはできない)
SSL必須前提では使えない

割り込んだ攻撃者は任意のIDを送信できる

端末付与型のリスク
  • EZ番号は end-to-end で送られる (ゲートウェイが付加しているのではなく、端末が送信している)
  • 端末が jail break されたらなりすましのおそれ
無責任なキャリア
  • 公式情報を公表していない
  • しかもdocomoは「iモードID」の使用を推奨している
Cookieで実装せよ
そもそもUIが変
  • かんたんログインボタン、ログアウト機能……?
  • utn送信時の「はい/いいえ」に配慮?
「かんたんログイン」言うなキャンペーン
パスワードを登録しないサイト
  • ワンタイム課金なら問題ない
  • SNSなどはキャリア乗り換えの問題があるのでパスワードが必要なはず。ケータイID認証で徹底したとしても、どこかにパスワード入力画面がある (一番最初に登録していることが多い)
  • ケータイだから弱いパスワード使う、というのは利用者の責任
docomoをどうする?
  • 基本的にはCookieで実装
  • iモード1.0の場合のみiモードIDで実装
ヤマダ電機
  • 一人1回を実現するため?
  • 国民ID的な利用
  • 国民ケータイ総背番号制
  • 国民IDが出来てもポイントカードでの利用は認められないだろう
  • 使用が広がると戻れなくなる
一般インターネットへの波及
ケータイIDがなくなると困る?

IPアドレスをころころ変える荒らし

  • ISPは対応してくれる
  • ケータイキャリアは通信の秘密を盾に拒否?
何を取るかの問題?
  • プライバシーを取るか、安全・安心を取るか……という二者択一なのか?
  • 両立できないのか?
  • 法務系の人々……IDやCookieのことが分かっていない
docomo ID

基本的には高木さんの日記 (takagi-hiromitsu.jp)で既出の論点のまとめ、という感じでしょうか。徳丸さんのセッションに引き続き、キャリアが情報を公開していないことの是非、キャリア側の責任のあり方について問われる内容になりました。

しかしなによりこのセッションで驚愕したのは、おおっぴらにセッションハイジャックが行われたこと。終了時間になっても「まだ重要な話がありますので、上野さんのお時間をいただいて……」と続行、後に続く上野さんのセッションを乗っ取ってしまいました。

そんな不幸な上野さんのセッションに続きます……「OAuthとWEBサイト運営のエコシステムに潜む罠」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010 / モバイル

WASForum Conference 2010: ケータイ2.0が開けてしまったパンドラの箱

公開: 2010年5月30日16時40分頃

WASForum Conference 2010。OpenIDのお話の後は、昼休みを挟んで午後のセッションです。午後の一発目は、HASHコンサルティングの徳丸浩さんによる「ケータイ2.0が開けてしまったパンドラの箱」。実はこのセッション、事前に「未公表のネタ2件を発表する (twitter.com)」と宣言されていました。未公表の脆弱性が複数公開されるのではないか……と、期待と不安が高まります。

かんたんログインのお話
各サービスのかんたんログイン機能
  • はてな …… 「かんたんログイン」あり
  • ライブドア …… 「クイックログイン」あり
  • mixi …… 「かんたんログイン」あり
  • ブラウザ三国志 …… なんと、「かんたんログイン」のみ。むしろ潔い?
  • Twitter …… かんたんログインあり。このサービスは、端末が3台あれば3台ともかんたんログインできるように頑張っている。
  • Remember The Milk …… iモードのみ、「かんたんログイン」が利用可能
かんたんログインが成り立つための条件
  • 端末固有ID …… 秘密情報ではない。「書き換えができない」という前提
  • ふつうにHTTPヘッダに入っている
  • 携帯電話を使っている限りは書き換えできない?
  • ケータイ網が閉じたネットワークであること
  • ケータイ端末の機能が低く、HTTPヘッダを書き換える必要がないこと
iモードブラウザ2.0
  • 2009年5月19日、iモードブラウザ2.0の発表
  • JavaScript対応、Ajax対応、Cookie対応、Referer対応
ケータイJSで端末固有IDを書き換える
  • XMLHttpRequestが使用できる
  • setRequestHeaderが使用できる
  • setRequestHeaderでリクエストヘッダを書き換ることができる

……10月の時点で、setRequestHeaderが機能しなくなった (setRequestHeaderメソッドはあるが、呼んでも何もしない)。これにより、能動的攻撃はできなくなった。

mpw.jpによる情報
徳丸浩の熱い日
  • 事業者側での対応は困難。一方、サイト側での対策は可能。
  • そのため、公表することにした。
DNS Pinning
  • IEは強固だが、他のブラウザは割とゆるい。キャリアのせいというわけでもなさそう
  • ゲートウェイで名前解決するので、ブラウザ側では対策できない
  • ゲートウェイ側で一定時間Pinningする場合、ゲートウェイが共有であることが問題になる。攻撃者がPinning開始時間を設定できる (例: Pinningが1時間なら、攻撃者は攻撃開始の58分前に1度アクセスしておけば良い)
ゲートウェイIPの変遷
  • リモートホストのIPアドレスは頻繁に変わる
  • docomoは1分間はDNSキャッシュを保持
  • ゲートウェイの群単位でキャッシュを共有しているらしい?
ソフトバンク端末のJavaScript対応
  • 2004.12 ノキア JS対応
  • 2006.3 804SS JS対応 (ただしiframeには対応せず)
  • 2008.3 922SH Ajax対応

実は、2006年からパンドラの箱は開いていた!

setRequestHeaderはどのヘッダを改変して良いか?
  • Host, Referer は書き換えできては駄目なはず……。
  • ソフトバンク端末では、なんと Host: が書き換えできてしまう!
徳丸浩の熱い日2
  • 932SHを購入 (7万円) して確認。
  • 問題を報告。ソフトバンクモバイルの側の担当者がアサイン
  • 12月某日、ソフトバンクにて打ち合わせ

Host: の改変防止が根本対策だが……。

3月末某日
  • DNSの挙動に変化が……
  • DNSキャッシュを5分間保持するようになった
  • ただしゲートウェイ群が切り替わると駄目
しびれを切らして……
  • デフォルトAjax許可の端末はないのか?
  • マニュアルを片っ端からダウンロードして通読
  • 検証センターで検証!!
検証結果

検証センターで3時間かけて64機種を調査したところ、以下の4機種でAjaxがデフォルトONであり、しかもHost:書き換え可能であることが判明。

  • 940SC
  • 820N
  • 821N
  • 830CA

SH (シャープ端末) はデフォルトでAjaxが無効となっている。ユーザーが設定を変えた場合には影響を受ける。

NEC、CASIOの端末では Refererの改変も可能。

  • NECとCASIOは、いったんAjax有効の端末を出したものの、後継機種では何故かまた無効になった。
  • SHARPは一貫してAjaxがデフォルト無効であり、慎重な姿勢が見られる
  • メーカーごとに対応がバラバラであり、連携がない。他メーカーの教訓が生かされていない
  • NET FRONTのACCESS社は何をしていたのか!?
  • IEも昔は脆弱だったが、対応してきた歴史がある。
  • 携帯端末でのブラウザシェア8割に見合う責任を果たしていただきたい

幸い、Ajaxデフォルト有効機種はシェアが低いため、影響は大きくないと判断し、このたび公開を判断した。

対策は?
  • アプリ側の対策はない
  • ユーザ側にセキュリティ設定を促す
  • 運営者にやる気があれば……危険な機種のみかんたんログインを無効にする
  • ソフトバンク端末ではかんたんログインを無効に
能動的攻撃の可能性
  • SSLでエンドトゥエンド通信にすると、キャリアのゲートウェイでヘッダフィールドを書き換えられなくなる
  • "User-Agent" ではなく "User_Agent" というヘッダフィールドをつけることで、User-Agentを誤認識させることができる (CGIプログラムで環境変数 HTTP_USER_AGENT を参照している場合)
  • SSLではかんたんログインを受け付けないことが対策になる
まとめ
  • 機種に依存する要素が多い
  • そのため、全ての端末について検証しないと何とも言えない。が、一人でやるのは大変
  • オープンに議論できる場が必要なのではないか

というわけで、ソフトバンク端末の XMLHttpRequestで Host: が改竄されるという脆弱性が公表されました。

私もソフトバンク端末が JavsScript や XMLHttpRequest にひっそりと対応していることには気付いていて、ひっそりと問題視していたのですが、XMLHttpRequestはデフォルト無効になっているものと思っていました。デフォルト有効の機種があったとは……。そして、その調査のためにわざわざ検証センターに出向き、64もの機種を調査されたというのが凄いです。会場も沸いていました。

しかし、そんな検証を個人でやるのは大変だという事実。キャリアから公式サイトに向けた資料はNDAベースですし、端末のメーカーごとに対応がまちまちだったりするところを見ると、端末側の技術資料もあまり共有されていないように見受けられます。そういったところがオープンになり、情報が共有されるようになって行けば、安全性の向上にもつながりそうですね。

続きます……「どうするケータイ認証」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010 / モバイル

WASForum Conference 2010: OpenIDのモバイル対応 ～ 認証基盤連携フォーラムの取組み他から

公開: 2010年5月29日22時10分頃

WASForum Conference 2010、Yahoo!のお話に引き続き、OpenIDのお話です。野村総研の崎村夏彦さんによる「OpenIDのモバイル対応 ～ 認証基盤連携フォーラムの取組み他から」。

OpenIDって、何?
  • Open Identity
  • Identity とは?
Digital Identity

Subject / Entityに対応する、属性の集合

  • 形質 traits …… 変わらないもの。生年月日、身長、体重、名前など
  • 属性 attributes …… 住所 電話番号 {メールアドレス ユーザー名} …… 識別子)
  • 関係性 relationships 交友関係、購買履歴、etc.
  • 例: Wii でいうところの mii。mii に体重なども結びつけて記録することができる
  • ただし、mii は Wii の中でしか生きられない
  • 標準化・Open化すると Open mii → Open ID
認証プロセス
  • Digital Identityの制御者として「正当性の確認」「属性引き渡し」を要求
  • Digital Identityの制御者としての正当性の確認
  • 正当性と属性確認書 (Assertion) の発行とお届け
OpenIDの基本モデル
  • IDプロバイダとサービス提供者
認証基盤連携フォーラム

「通信プラットフォームのあり方について」で規定

  • 分散&連携
  • ユーザー中心
  • 高可用
  • 信頼&評判

目的は、ユーザセントリックIDの実現

OpenIDはモバイルでは……。
  • コンテンツ画面で「ログイン」をクリックすると……エラーが発生
  • GET URLが長すぎる
  • POSTにすれば通るが、ユーザーがクリックしなければならない
  • レスポンスにはAssersionが全て乗るのでさらに大きくなる
属性連携はユーザ利便性を高める

属性情報を全て入れてもらう場合と、属性連携を使って一部の属性情報入力を省いた場合とでユーザテストを実施。

  • 時間短縮削減、エラー発生率低下の効果
  • 1分33秒 vs 19秒
  • 19.6% vs 7.1%
  • テスト後のアンケートでは、属性連携を「非常に利用したい」53%、「利用したい」41%、「利用したくない」3%、「全く利用したくない」0%、「わからない」3% となり、予想以上の評価
  • ただし、情報提供先が信頼できるのかどうかを確認したいという声も見られた
OpenID for mobile (Artifact Binding)
  • RPはリクエストファイル作成、そのURLをOPに送信
  • OPはファィルを取得、Artifactを送信
  • RPからArtifactをOPに送信、Assertion取得
  • リクエストファィルはJSON
  • AeerstionもJSON
  • Artifactは302リダイレクト
  • OP https Endpoint に対して GET で取得 (ログ残る)

実装サンプルが https://openid4.us (openid4.us) で見られる。

  • ブラウザ経由のGETを小さくできる
  • ほとんどサーバ間通信
  • Assertion Disclosureの防止 (ブラウザを経由しないため)
  • OPの完全ステートレス化も可能
  • NISTのLoA4まで対応可能
  • Signed Assertion Requestを使えば繰り返し属性の取得が可能 (ユーザの許可があれば)
  • OAuth2.0のtoken受け渡しも可能 (OAuth2.0--)
  • 実装が簡単
  • OPがサポートすればSAMLやWSSも返せる

スケジュール……5末仕様凍結、12月最終仕様?

属性をどう表現するのか
  • Type URI で表現するのが主流
  • どの Type URI を使うかのコンセンサスはない
  • AXSchema, Portable Contacts, etc... ユーザのOPによってリクエストするURLを使い分けなければならない
  • フリガナなどはない。そもそもスクリプトの概念がないので、ひらがな/カタカナ/漢字のような指定ができない
  • "Type_URL#言語_スクリプト_国" の形で表現する案 例: http://axschema.org/nameParson#ja_Kana_JP
  • Artifact Binding の短縮表記案 例: ns:ax/foo = http://axschema.org/foo
Q&A
  • Artifact Binding
  • SAMLなどと比較した際の優位性は?
  • OpenIDとSAMLの相互運用性確保
  • Idプロバイダが廃業すると……
    • 今まではサービスプロバイダ = IdPだった
    • 分離されると……IdPの廃業でサービスにログインできなくなってしまう
    • アメリカで4社廃業、うち2社はトラストフレームワークに入っており、データをエスクローしていて問題なし
    • どこまでの情報を移行すれば良いのか?
    • RPごとに別々のIDを振り出せる……どこにどのIDか、という情報まで必要
  • デバイス間のセッション引き継ぎ
    • 携帯電話上でパスワードを入れさせるのはユーザからの評価が非常に低い
    • しかし、インターネット上で識別番号を使用するのは非常にまずい
    • タンパリングされている可能性が高い
    • ガラケー → フィーチャーフォン
    • ケータイから来ているかどうかを知りたい、というニーズがある(AOL / Yahoo)
    • ケータイキャリアがOpenIDプロバイダになれば良いのだが……

WASF2008のときにはOpenIDをあんまり理解していなかった私ですが、2年経ってもそんなに理解が進んでいない気がしております。というわけであんまりコメントすることはありません。

※結構知らない単語や概念があったりして、勉強不足を痛感しております。orz 午後の上野さんのセッションの方が入門的な内容だったので、順番が逆の方が分かりやすかったかもしれません。

このセッションで一番印象に残ったのは、やはり「フィーチャーフォン」でしょうか。「ガラケー」ではなく「フィーチャーフォン」と呼ぶのがクールみたいですよ。

続きます……「ケータイ2.0が開けてしまったパンドラの箱」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010 / モバイル

WASForum Conference 2010: 国民のためのウェブサイトを運営するID認証の舞台裏 (後半)

公開: 2010年5月29日13時35分頃

WASForum Conference 2010、国民のためのウェブサイトを運営するID認証の舞台裏。前半に引き続き、外部サービスとの連携の話に移って行きます。

オープン化とプライバシー
  • 社内で明文化されたポリシー : 「ヤフーをプラットフォームとして、ヤフーだけにとどまらず、パートナーサイトとの最適な連携を通じて、インターネット上に存在する情報・サービスの中から、お客様にとって最良の情報・サービスを提供して行く」
  • OpenID、OAuthなどによるプラットフォーム提供
  • プロバイダ側が充実しても、ユーザーにはその事が分からない。共同プレスリリースを出して行く
連携の例
  • smart.fm × Yahoo!
    • Yahoo!側のプロフィールをsmart.fm側で出せる
    • 渡したくないものは渡さないように選択できたりする
  • Oisix × Yahoo!
    • 決済・ポイント連携
  • 何が起きるかを明確にユーザーに説明する必要がある
  • パートナーサイト→ログイン画面(Y!)→同意画面(Y!)→パートナーサイト登録画面(追加情報の登録)→パートナーサイト登録完了画面
どのように連携するか
  • ID連携のみ (OAuth)
  • + 属性連携 (Attribute API)
  • + 決済連携 (Wallet API)
  • + ポイント連携 (Point API)
どの属性情報をどの外部サービスに提供するか
  • 本人が利用する情報 : 配送先、氏名、電話番号など。ショッピングサイト、銀行などに提供
  • 他のユーザーに見せる情報 : 表示名、画像など。SNS、ゲーム、コミュニケーション用サイトなどに提供
  • SNSなどは両方を使ったりする
API公開情報レベル区分
  • LV1 提供可能: 購入・決済に関わらない情報
  • LV2 特定企業に審査後に提供可能: 購入・決済に関わる情報
  • LV3 提供不能: 個人を識別する情報
  • 大切なお客様の情報をどういった基準でどこまで提供するか? → 現状はYahoo!として独自に判断している
  • 各企業の独自判断ではなく、共有できるルールか必要とされている
  • facebook connect 50%以上、twitter OAuth 25%くらい
  • Activity Stream から生まれるトラフィックが魅力
  • さらにfacebook、twitterを利用するというエコサイクルを作っている

外部サービスとの連携の際に、「何が起きるかを明確にユーザーに説明する必要がある」というお話は印象深かったです。いつも思うのですが、twitterのOAuthの画面などは何が起きるのか分からないわけでして、実際、OAuthでspamツイートを送信させるような攻撃が行われています。

あとは、どのサービスにどの属性を渡すのかというレベルの話ですね。

……完全に余談ですが、スライドの左上に「Y!」のロゴが入っていて、そのすぐ右にページタイトルが入るというデザインになっていたので、ページタイトル部分が「Y!××」というサービス名のように見えました。

続きます……「OpenIDのモバイル対応 ～ 認証基盤連携フォーラムの取組み他から」。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: 国民のためのウェブサイトを運営するID認証の舞台裏 (前半)

公開: 2010年5月26日1時25分頃

WASForum Conference 2010、オープニングセッションに続いて、ヤフーの松岡泰三さんによる「国民のためのウェブサイトを運営するID認証の舞台裏」。松岡さんは「R&D統括本部プラットフォーム開発本部セントラル開発1部」に属し、OpenID、OAuth、認証API、認証(ログイン)、ソーシャルプラットフォーム、ストレージプラットフォーム、外部サービス連携……といった諸々のお仕事をされているそうで。

今回のお話は大きく前後半に分かれていて、前半はYahoo!の認証に関する仕組みや統計データについてのお話、後半は外部サービスとの連携の話になっていました。まずは前半部分のメモから。

Yahoo! Japan ID の現在
  • アクティブユーザ数 …… 2396万ID
  • Yahoo!ウォレットのユーザ数 …… 1900万
  • Yahoo!プレミアムの会員数 …… 759万

アクティブユーザ = 月1回以上ログインしているユーザと定義、単純な会員数はほぼ日本国民の数と同じくらい。

  • ログイン試行数 …… 775万回/日
  • ログイン成功数 …… 698万回/日 (90.4%)
  • ログインエラー数 …… 77万回/日 (9.6%)

主な間違いは ID、パスワードの入力ミス (ログインフォームのIDはフィルしていない)。

内外比率
  • 内部の利用 …… 93.8%
  • 外部からの利用 …… 6.2%
  • 外部利用のうち、OAuthとOpenIDは2%。そのほか、古いチケット型の認証の仕組みが残っていて利用されている
パスワード再確認

Yahoo!では、ログイン状態でも再度パスワードを訊くケースがある。

重要情報はログイン直後でないとアクセスできないようになっている。個人情報を閲覧する場合、決済シーンなど。

  • パスワード再確認の比率 …… 15.72%
Yahoo!のIdentityプラットフォーム

安心・安全・便利

さまざまなニーズ
  • さまざまなサービス …… Yahoo! のサービス一覧 (services.yahoo.co.jp)、数えるのに力尽きたがたぶん150くらい

    ※私がカウントしたところでは、2010-05-25現在で157あるようです

  • さまざまな端末 …… PC、ケータイ、スマートフォン、テレビ、カーナビ
  • さまざまなユーザーエージェント …… Webアプリ、クライアントアプリ、ガジェット
  • Yahoo!のサービスと、外部のサービス
  • コンシューマと、ビジネスユーザ
  • オトナと、子ども。子ども向けのIDが欲しいというニーズがあり、「Yahoo!きっず」というサービスがある
さまざまな認証
  • Web
  • 内部クライアントアプリケーション向け (Token Login)
  • 外部クライアントアプリケーション向け (RawAuth)
  • 端末ID認証 (モバイルログイン)

    ※ここで高木さんが来場されているかどうか確認 :-)

  • テレビ向け
  • Webブラウザ向け
  • OpenID
  • OAuth
  • SSO
  • AEAuth (教育機関向け)
  • ビジネスID
  • きっずID (「IDを入力してね。」のようにやさしい文言。Yahoo!きっずでしかログイン状態にならない)
どれがベストか?
  • パスワード再確認画面は何で必要なの? どういうリスクがあるの?
  • 多様なニーズに応えながらも、守るべきは守る
ユーザを守る機能とその課題

不正アクセスからユーザーを守るために「ログイン履歴」「ログインシール」「ログインアラート」という仕組みを用意している。社内ではこれら3つを「ログイン3兄弟」と呼んでいる。

ログイン履歴
  • 直近60件のログインの履歴を表示。成功も失敗も記録。
  • 表示する情報は……どのサービスでログインしたか、ログイン時刻、ログインなのか再確認なのか、成功or失敗、IPアドレス、端末がPCかモバイルか
  • 悪いことをしようという人にもこのサービスの存在を知ってもらって、抑止につなげたい
ログインシール
  • ログインフォームに、ユーザーが設定したシールを表示する
  • フィッシング防止のため
ログインアラート
  • ログインするたびにメールが届く
  • メールにはURLが書かれており、そのURLにアクセスするとアカウントをロックすることが可能。ログインに心当たりがないときにはロックを。
  • ただし強制ログアウトにはならず、現在のセッションは有効。次回ログインからブロックされる。
ログイン3兄弟の課題
  • 利用率がイマイチ……。
  • 場所が分かりにくい。たとえば、ログインアラートは「Yahoo!トップの右上」→「ガイドページの左下」→「ログインアラート説明ページ」と辿らないと出てこない
  • ログイン履歴の利用 = 136万PV/月
  • 他の2機能の利用数は非公開 (と言いつつ、利用数のグラフは公開)。シールは利用率が低く、アラートはさらに低い
  • 選択式ではなかなか利用者数が増えない
  • しかし、全ユーザーに利用を強制するわけにも行かない
  • 利便性を保ちつつ全ユーザに適用できる対策はないか?
リスクベース認証
  • "Login Risk Manager" という仕組み
  • あらかじめユーザーの利用環境、アクティビティの情報を持っておく
  • 普段の利用と著しく異なる時間、環境、国からのアクセスは怪しい
  • ログインイベントの不審度(リスクレベル)を判定し、レベルによって通知or追加認証orブロックを実施する
  • この仕組みであれば、非常時以外は普段と何も変わらない利用ができる

数値データは参考になります。特に、ログインエラーの数が1割近いというあたり、いろいろ考えさせられるものがありますね。

それから、ログイン3兄弟の話。ログインシールは実際どのくらいの有効性があるのかな、と疑問に思っていたのですが、そもそも使っているユーザが多くないようですね。

ちなみに、一部で「ログインシールも捏造され得るのでは?」という疑問も出ていたようですが、このログインシール、ベリサインのシールなどとは根本的に異なるものです。このYahoo!のログインシールは、ブラウザのCookieと連動して表示される仕組みになっています。そのため、ドメインが異なる偽サイトにアクセスした場合、ログインシールのCookieは送られませんから、正しいシールをく表示することができないという仕組みです。そのため、ブラウザを変えると表示されなくなるという欠点もあり、以下のように説明されています。

ログインシールはブラウザ（Internet Explorer、Firefoxなど）ごとに設定するので、1台のパソコンを家族で共有している場合などは、誰がログインページを表示しても同じログインシールが表示されることになります。また、複数のパソコンや複数のブラウザを利用している場合（家や会社など）はそれぞれに設定する必要があります。

以上、ログインシールでフィッシング詐欺対策 - Yahoo! JAPAN IDガイド より

……というわけで、欠点もありますが、仕組みとしては有意義なものです (繰り返しますが、ベリサインのシールとは違います)。

リスクベース認証の話はなかなか筋が良いと思いますが、利用者の身近な人による不正アクセスは防ぎにくそうにも思えますね。他のさまざまな仕組みと組み合わせて使って行く必要があるのでしょう。

後半に続きます : 国民のためのウェブサイトを運営するID認証の舞台裏 (後半)

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

WASForum Conference 2010: オープニングセッション -「Webサイトを安全に使う秘技とユーザが直面する３つの危険」

公開: 2010年5月24日17時30分頃

WASForum Conference 2010 (wasforum.jp)に行ってきました。印象に残った話を中心にメモ。ただし、あんまり網羅できていなかったりしますし、聞き違いや勘違いが含まれている可能性もありますのでご注意ください。

まずはオープニングセッション、「Webサイトを安全に使う秘技とユーザが直面する３つの危険」。フォーラム代表でもある、奈良先端科学技術大学院大学の門林雄基さんによるお話です。

Webアプリのセキュリティ問題
  • ユーザ - デベロッパという軸と、クライアント - サーバという軸の2軸で見ることができる
  • セキュリティという面では、ブラウザ(ソフトウェア)、サーバの比重が大きく語られてきた
ユーザとWebブラウザ
  • うまいユーザ vs 下手なユーザ、地味なブラウザ vs 派手なブラウザという軸
  • 地味なブラウザの例: w3m
  • 下手なユーザ + 地味なブラウザ = ダサイ
  • 下手なユーザ + 派手なブラウザ = 危険
Webブラウザの進化
  • 1993年 CERN = 自転車
  • 1994年 Netscape Navigator = スーパーカブ
  • 2010年 (あえて具体名は出さない) 爆速・多機能 = デコトラ

デコトラの運転は危険がいっぱい。

3つの危険
  • まぜるな危険
    • あそびと、しごと。同じブラウザ?
    • あそびはChrome、仕事はFirefox?
  • アクティブコンテンツ危険
    • 聞いたこともないサイトにJavaScriptオンのままアクセスする達人はいませんよね?
  • パスワード危険
    • いろいろなサイトで同じパスワードを使っていたり……
    • 2要素認証、クライアント証明書も使える
    • 流行ってないですよね……と言われますが使っていないだけでは?
どうやって安全運転させる?
  • URLバーの色だけで状況判断できる?
  • 自動車の運転席 vs 飛行機の操縦席
  • ゾーン設定のツマミは、ダッシュボードの奥の方?
危険をどうやって伝える?
  • 自動車の場合、道路標識がある
  • 「慎重にクリックしてください」?
  • マウスが滑ったら事故が起きる? onmouseover="game.over"

今までのWASFではサーバー側のセキュリティ問題を中心に扱ってきていて、ユーザー側、クライアント側のセキュリティについてはあまり取り上げて来なかったというお話でした。今回はユーザー側、クライアント側の問題を中心に、ユーザーへの教育という観点も含めて論じて行きたい……ということですね。

というわけで、このお話は前振りです。ざっくりとテーマが提示されたところで、次のお話に続きます : 国民のためのウェブサイトを運営するID認証の舞台裏 (前半)

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

2010年5月21日(金曜日)

ドラクエ9 ギネス認定

公開: 2010年5月23日20時10分頃

ドラクエ9 (www.amazon.co.jp)がギネス認定だそうで。

1億1757万7073人だそうです。集計方法は書かれていないのですが、国勢調査 (member.square-enix.com)のすれ違い通信の集計と同じものでしょう。

ドラクエ9には「ぼうけんのしょをWi-Fiつうしんでおくる」というコマンドがあって、セーブデータをスクウェア・エニックスに送信することができます。知らないうちに送られるのではなく、あくまで能動的に送信したものだけが集計対象です。

このデータは集計に使われるだけではなく、ケータイサイトで表示したり、共有したりすることができるようになっています。そのため、各データには「ぼうけんのしょのカギ」という12桁の番号がつけられ、メンバーサイトでその数値を入力することで、ユーザーと「ぼうけんのしょ」が結びつけられます。こういう管理方法ですので、同じセーブデータで「ぼうけんのしょをWi-Fiつうしんでおくる」を複数回実行した場合、前のデータが上書きされます。

※カギはおそらくサーバ側で発番しているのでしょう。

また、公式サイト (www.dqix.jp)やWi-Fiショッピングで公表された「第6回Wi-Fiクエスト」の結果報告によると、4月30日の時点で「ぼうけんのしょをWi-Fiつうしんでおくる」を実行したプレイヤーは100万204人。ギネスの集計は3月4日ですから、100万人弱の集計結果と考えられます。

と、こういう感じです。まとめると、以下のようになっているものと思われます。

売れた本数から考えると「ぼうけんのしょをWi-Fiつうしんでおくる」を実行した人はそれほど多くはないので、実際にはもっと通信されているのでしょうね。

※ただ、改造データが含まれるのかどうかはちょっと良く分かりません。そもそも、改造したデータを「Wi-Fiつうしんでおくる」メリットが無いように思いますが、やってやれないことはないような気がしますね。

関連する話題: ゲーム / ドラクエ / ドラクエ9

2010年5月20日(木曜日)

検察が危ない

公開: 2010年5月23日13時40分頃

Amazonでは「発送まで1週間」とか表示されていたのに、そこらの本屋に初版第一刷が置いてあったという謎。

強引にストーリーどおりの自白をさせる、微罪なのに大々的に捜査して起訴する……といった諸々のお話。内部の体質など様々な問題が指摘されていますが、強く思ったのは、検察が常にマスコミや国民の期待に応える形で動いてきたのではないかということですね。一度「政治家○○に疑惑発覚」となり、そのマスコミ報道を見ると、「その政治家は有罪にするべき、不起訴や無罪では満足できない」……と思ってしまう国民が大勢いて、検察はその期待に応えようとすると。

これは脆弱性の発見・報告にも通じる話ですね。脆弱性の話が出ると、「即座に公表すべき」「脆弱性を生み出した企業は糾弾されるべき」という反応をする人々が大勢出てきます。その期待が圧力にまで高まると……。スルーする勇気も大切なのだと思いますね。

関連する話題: 本 / 買い物

2010年5月19日(水曜日)

レベル99竜王撃破

公開: 2010年5月22日22時55分頃

ドラクエ9 (www.amazon.co.jp)、竜王を撃破。

竜王は初代ドラクエのラスボスなのですが、なんというか……首を寝違えたのでしょうか。初代ドラクエの時代は敵のグラフィックは全て正面から見た状態の静止画で、竜王はちょうど横を向いた瞬間の絵だったわけです。それはそれで格好良かったのですが……そのまま3Dモデルにすると、何故かずっと横を向いているという変な感じになりますね。

ともあれこんな感じの行動をしてきます。

これで3回行動。

強いです。行動パターンは少ないのですが、ほとんど全てガッツリとダメージを与えてくる行動なので厳しいです。特に、なぎ払い・れんごく・暗黒のコンボは強烈で、HP満タンの状態から一瞬で全滅することもあります。しかも頻度が高いのが泣ける。

ブレス攻撃の頻度が高いので、扇の技「といきがえし」が有効です。ターン開始時に3人以上が「といきがえし」の状態だとブレス攻撃をしてこなくなるようですが、ブレスを封じられるだけでも意味があります。もっとも、ブレスがなくなってもなぎ払い+打撃で普通に死にますし、凍てつく波動の頻度が上がるので一長一短という感じがしますね。2人がといきがえし状態で戦うのも良いかも。

……基本的には運ゲーのような気がします。いちおう10ターンで撃破しましたが、運が良ければ3～4ターンで行けるでしょう。

関連する話題: ゲーム / ドラクエ / ドラクエ9

DNSポイゾニングによるブロッキングに意味はある?

公開: 2010年5月22日1時35分頃

児童ポルノのブロッキング、総務省が容認、「民間主導」で今年度中に開始へ (internet.watch.impress.co.jp)

なお、今回の会合で導入表明を行ったISPであるNTTコミュニケーションズとニフティでは、いくつかあるブロッキング手法のうち、「DNSポイズニング」と呼ばれる手法を検討しているという。これは、ISPの会員から自社のDNSサーバーに対して、遮断リストに含まれるホストについてのクエリーがあった場合に、ダミーのIPアドレスを返すことで該当サイトへのアクセスを遮断する方式だ。

「DNSポイズニング」って……これ、意味あるのでしょうか。ぱっと思いついただけでも以下のような問題があります。

最後の項目がもうどうしようもないわけです。提供側は見てもらいたいのでしょうから積極的に回避策を講じると思いますが、単に「IPアドレスのURLを使う」というだけで簡単に回避できてしまいます。もとよりドメインの信頼性など必要ないようなサイトでしょうし、これをためらう理由はなさそうに思います。

そもそも、WinnyやShareなどには何ら影響しない訳ですし……。

これ、コストをかけて実施する意味があるのでしょうか?

※なんというか、「ホントはブロッキングなんてしたくないけど、仕方ないのでコストを最低限におさえられる方法でカタチだけ対応をしておこうか……」というような思惑なのではないかと思えてしまいます。ISP側はコストを抑ようとする一方で、「遮断するURLのリストを作成してISPに提供する第三者機関」はお金を使いそうですし。むしろブロッキングの有効性はどうでも良くて、その機関を作ることが目的なのかも……などと、いろいろなことを考えてしまいますね。

関連する話題: Web / セキュリティ

2010年5月18日(火曜日)

ソフトバンク端末がAjaxに対応?

公開: 2010年5月22日1時0分頃

「Yahoo!ケータイのブラウザが仕様改定、Ajaxなどに対応 (k-tai.impress.co.jp)」という記事が。

JavaScriptにも対応し、いわゆるAjaxで構築されたページが利用できるようになる。

あのー、ソフトバンク端末はもうだいぶ前からJavaScriptやAjaxに対応しているのですけど……。

手元の検証用端末の中では、2006年発売の811SH (plusd.itmedia.co.jp)がJavaScriptに対応していること、830SH (plusd.itmedia.co.jp)がJavaScript+Ajaxに対応していることを確認しています。

ただし、830SHのAjaxはデフォルトでは有効になっていません (ブラウザの設定にズバリ「Ajax」という項目があり、ON/OFF可能)。設定項目が分かりにくい場所にあることもあり、有効にしている利用者は少ないのではないかと思います。設定を有効にすれば「Ajaxで構築されたページが利用できる」ようになりますが、普通の人が普通に利用できるという感じではないでしょう。

「Ajaxで構築されたページが利用できるように」というのは、この設定がデフォルトで有効にされるということなのでしょうか?

ちなみに、JavaScriptのほうは有効になっているようで、iframeを経由してコンテンツを読み取るようなことも普通に可能です。ただし当然、別ドメインのコンテンツはそのままでは読めませんが……。

※5月22日以降追記するかも。

関連する話題: Web / セキュリティ / モバイル

EZ番号は何のため?

公開: 2010年5月22日0時20分頃

「先週からEZ番号の変更が不可能にされていた (takagi-hiromitsu.jp)」。追記部分 (takagi-hiromitsu.jp)が興味深いです。

（２）変更背景

「ＥＺｗｅｂ」オプションの廃止⇒再加入等で「ＥＺ番号」を変更し、ＳＮＳサイトで迷惑行為を繰り返すといった問題行為も確認されている場合がある事から、迷惑行為対策としてシステム改修します。

迷惑行為への対策だと明言しているようなのですが、そもそもEZ番号って迷惑行為への対策に使えるものなのでしょうか?

KDDIはどちらだと考えているのでしょうね。

関連する話題: Web / セキュリティ / プライバシー / モバイル

ブラウザの「フィンガープリント」で個人を識別する技術

公開: 2010年5月21日12時45分頃

「ほとんどのブラウザーで個人を識別できる“指紋”を残す、米EFFが警告 (internet.watch.impress.co.jp)」。

その結果、全ユーザーのうち84％が、ユニークで識別可能だった。また、Adobe FlashまたはJavaプラグインがインストールされている場合、94％がユニークで識別可能だった。2回以上同じ設定が現れた割合はわずかに1％だったという。EFFではこれらの情報を“フィンガープリント（指紋）”と呼んでいる。

これは興味深いですね。ブラウザのバージョンやその他の設定が全く一緒であっても、AさんのFlash Playerがバージョン「10.0.45.2」、Bさんが「10.0.45.1」だとすれば、サイト側でバージョンを取得することで区別できるわけですね。元記事 (www.eff.org)のレポートを軽く見た感じでは、以下のような情報で判別できるという話のようです。

インストールされているフォントの種類を取得するという手法は、なるほどという感じですね。FlashやJava Appletを使うと、インストールされているフォントの一覧が取れるようで。

また、企業で使用されている端末は全く同じ設定である場合が多いため、識別しにくい特徴があるという。

企業の場合、オフィスで使用するOS、フォント、ブラウザのバージョンは決められているケースが多いですし (しかも、よりによってIE6のことが多い)、一括で全員のプラグインをアップデートしたりもしますから、差が出にくいと。

※……しかしまあ、日本のガラパゴスケータイ業界を見ると、こんな「警告」とは全く別世界ですね。ガラケーなら個体識別番号でイッパツ判別!

関連する話題: Web / セキュリティ / プライバシー

脳という臓器は身体の一部

公開: 2010年5月21日12時15分頃

「お父さんが「眠れない」のは、心の問題ではない 自殺対策について精神科医ができること・計見一雄氏に聞く (business.nikkeibp.co.jp)」という記事が。興味深いと思ったのはこの部分。

今までに私があげたことは、ぜーんぶ身体の不調ですね？　痩せて食えなくて、便秘して、眠れなくて…不眠やそれに伴う日内変動という一日のうちでの体調の乱れは、日夜リズムという周期の異常で、これも脳という臓器の「歩調取り装置」の故障ですから、やはりからだの異常です。

以上、お父さんが「眠れない」のは、心の問題ではない 自殺対策について精神科医ができること・計見一雄氏に聞く より

肉体と精神は別のもの、肉体の不調と精神の不調もまた別のもの……と考えてしまいがちですが、肉体と精神は不可分です。実際、怪我をしてどこかが痛み続けている状態では思考に集中できませんし、風邪で熱が出ると眠くなったりぼうっとしたりしますよね。

「脳という臓器」という言い方は、非常にうまい説明だと思いました。

関連する話題: 思ったこと / 精神医学

2010年5月17日(月曜日)

ムダヅモ無き改革4

公開: 2010年5月21日0時35分頃

購入。

今回も凄い。「第一打の前にロン」「1回のロンで4回和了」って、天地創世はまだ麻雀のルールの範囲で理解可能でしたが、これはもう完全にぶっ飛んでいますね。「スーパーアーリア人」「スーパーカミオカンデ」「イタコ3人同時ロン」……とネタが尽きないのですが、一番可笑しかったのが「ベタオリ」。ベタオリと書いて「神を試してはならない」と読むという……。

関連する話題: マンガ / 買い物 / ムダヅモ無き改革

2010年5月14日(金曜日)

Web&モバイルマーケティングEXPO 2010: roundabout

公開: 2010年5月20日13時55分頃

情報セキュリティEXPOと併設で開催されていた「Web&モバイルマーケティングEXPO」もちょっと覗いてみましたが、気になったのは「roundabout (www.symmetric.co.jp)」という製品。ワンソースで、ケータイ各キャリア用のコンテンツを生成できるというコンテンツ変換サーバですね。この分野の既存の製品としてはx-Servlet (www.flexfirm.jp)とかElixir (elixir.neu.co.jp)あたりが有名です。

そのroundaboutですが、私が面白いと思った点は以下の2つ。

x-Servletなどでは、ソースは謎のi-CSSが書かれた状態で提供する必要があり、要するにstyle属性を書きまくる必要がありました。外部CSSが使えれば……というのは誰しも思うことです。これができるとだいぶ楽になりそうですし、「ケータイ専業」の知識がなくても作業できそうですね。ただし、レイアウトはtableになるとのことでした。

それから、Apacheモジュールというのは筋が良いと思います。Javaより速そうだというのもありますが、バックエンドのアプリケーションとの連携がしやすそうです。

……と、いろいろ興味深くはあるのですが、お値段がなぁ。大手の企業でも、ケータイサイトにはそんなにお金出してくれないんですよね。

※roundabout footprint (www.symmetric.co.jp)というアクセス解析のソリューションもあるようで、iモードIDが云々……という話もあるようなのですが、これについては採用事例がまだ少ないらしく、あまり詳しい話は聞けませんでした。

関連する話題: Web / モバイル / Web&モバイルマーケティングEXPO

情報セキュリティEXPO 2010: yarai脆弱性防御機能

公開: 2010年5月20日1時0分頃

情報セキュリティEXPOの最終日だったので行ってみました。

去年はyaraiを見に行ったのですが、今年は「yarai脆弱性防御機能 (www.fourteenforty.jp)」というものが展示されているようなので、それをお目当てということで。

しかし、会場のマップを見てもFFRのブースが見あたらず。……と、つぶやいたら、はまもとさんにAITブースの中だ (twitter.com)と教えていただきました (ありがとうございます)。

というわけで、yarai脆弱性防御機能のRC版と、yaraiチロルチョコを手に入れました!

実は去年も評価版をいただいて一ヶ月試用してみたのですが、その期間中にゼロデイ攻撃を受けたりはしなかったようで、特に何も起きず。まあyaraiに限らないのですが、アンチウィルスは「何も起きない」のが正常動作ですから、評価するのが難しいですね。

※だからこそ、わざわざ「トラッキングウェア」なんてのを検出して、ちゃんと動いている感をアピールするソフトがあるのでしょうけれど。

その事を相談してみると、「実際にyaraiで攻撃を防いだ事例が集まってきており、近いうちに公開する予定」とのことでした。官公庁方面で標的型攻撃を防いだりした事例があったりするのでしょうか。楽しみです。

関連する話題: セキュリティ / yarai

2010年5月13日(木曜日)

エンディングにありがちなこと: 東京タワーに突き刺さる

公開: 2010年5月18日1時15分頃

「ゲームのエンディングにありがちなこと (getnews.jp)」というネタが。よくある「あるある」ネタですが、これには吹き出してしまいました。

東京タワーに突き刺さる

そんなゲームないですよ! 私も結構いろいろゲームをクリアしてきましたが、そんなエンディングのゲームは見たことがありません。……ただ1本を除いて。

その1本とは、スクウェア・エニックスの奇ゲー「ドラッグ オン ドラグーン (www.amazon.co.jp)」。全ての武器を集めてはじめて到達できるEエンディングは通称「新宿エンド」、これはもう全てが異常としか言いようがない世界です。これが「ありがち」って、どれだけマニアックなんでしょう……。

※続編 (www.amazon.co.jp)はわりと普通になってしまったのが少し残念。

関連する話題: ゲーム

Webプログラミングにおいて、すべての拡張子はセキュアでない?

公開: 2010年5月18日0時45分頃

「Webプログラミングにおいて、すべての言語はセキュアでない (slashdot.jp)」。

元ネタのWhiteHat Website Security Statistics Report (www.whitehatsec.com)を見ると、調査対象はASP,ASPX,CFM,DO,JSP,PHP,PLとなっているようで。

って、"DO" って何だろうと思ったのですが、拡張子 .do のことでしょうか。言語ではなく拡張子で見ている? そのわりには .cgi が無かったりしますが……。

関連する話題: セキュリティ

告白

公開: 2010年5月16日17時30分頃

読み終わったので。

これは面白かったですね。

謎が提示されて答えが示される……というスタイルではなく、誰かが先に言ったことを、後から別の人物が覆すというスタイルが面白いと思いました。先に示された解釈で完全に整合性がとれているのに、あとから事実は異なると指摘されるわけですね。

もっとも、そのスタイルのおかげで、最後のほうは疑心暗鬼になってきます。ラストはある意味衝撃的なのですが、それも実はブラフなのではないかと考えさせられます。それはそれで良いのですが、主人公(?)の森口のキャラクターがそれほど前面に出ていないため、考える材料が少ないのですね。

個人的にはオススメなのですが、ショッキングなシーンもかなりあるので、そういうものが苦手な人だと厳しいかもしれません。

関連する話題: 本 / 買い物

2010年5月12日(水曜日)

個体識別番号は個人情報と容易に結びつく

更新: 2010年6月1日11時35分頃

「KDDIの固体バカが言う「EZ番号はプライバシーに関する情報ではない」 (takagi-hiromitsu.jp)」。

「固体」ではなく「個体」が正解なのですが、KDDIのドキュメントには「固体」と記述してあるという。まあ、それは単なる変換ミスの類でしょうが、問題なのはその記述の内容の方ですね。

■EZ番号はお客さまがURLにアクセスした際にサイト提供元のサーバに通知され、会員のアクセス管理などに利用されますが携帯電話番号やメールアドレス、氏名などのプライバシーに関する情報は含まれておりませんのでご安心ください。

以上、[000021]EZ番号（固体識別番号）を変更したい。 より

※2010-06-01追記: 上記の記述は削除されたようで、現在は確認できません。

確かに、EZ番号それ自体には個人情報は含まれていないでしょう。しかし問題は、個人情報と簡単に結びつくという点です。たとえば、以下のようにすると……

これでEZ番号とメールアドレスが結びつきます。そして、このEZ番号とメールアドレスの組みが他のサイトに提供されると……そのサイトでは、アクセスしてきた人のEZ番号を取得し、メールアドレスを知ることができるようになります。

この例はメールに記載されたURLにアクセスさせるという方法ですが、結びつけの方法は他にもあります。たとえば会員制のサイトでは、会員情報登録の際に入力した情報とEZ番号とを結びつけてDBに保存しています。これはどのサイトも普通にやっていることですが、SQLインジェクションでDBの内容が漏洩したりすれば、利用者にとっては厳しいことになります。

そのため、個体識別番号をそのままDBに格納するのではなく、ハッシュ関数を通してハッシュ値だけ記録するようにしているサイトもあるようです。ただ、キャリア側からそのような指導が行われている気配もありませんし、むしろ「安全です」と言ってしまっているわけですから、そのような取り組みの必要性は認識されていません。わざわざそのような処理をしているサイトは少ないでしょう。

EZ番号それ自体に個人情報が含まれるかどうかは、どうでも良い話なのです。それを個人情報と結びつけることが出来るか、実際に結びついているかが問題です。

ちなみに、CookieやIPアドレスも個人情報と結びつけることが可能です。もっとも、これらが個人情報と結びつけられても、その結びつきは限定されています。Cookieの場合はブラウザ側で削除できますし、そもそも発行したサイト以外からは読み取れません。IPアドレスの場合、同じ値がずっと使われるとは限りませんし、そもそも個人と一対一対応しているわけでもありません。

※プライバシーポリシーに「CookieやIPアドレスは個人情報ではありません」と書いている企業もあるようですが、それ自体が個人情報かどうかは問われません。そうではなく、「当社ではCookieやIPアドレスを個人情報と結びつけません」と書かなければなりません。

それに対して、EZ番号はどうでしょうか。削除できず、変更できず、どのサイトからも同じ値を読み出し可能であるとすれば、それはかなり強固な結びつきになるのではないかと思います。

関連する話題: Web / セキュリティ / プライバシー / モバイル

2010年5月11日(火曜日)

Cookieをまめに削除するユーザーが2割?

公開: 2010年5月16日14時35分頃

「英クッキー削除で、アクセス解析でのサイト利用者数は実際の2.4倍にもなっている (ibukuro.blogspot.com)」。

英ネットユーザの4人に1人（23.5％）が、ファーストパーティ・クッキーを月に一度はクリアする。その結果アクセス解析ツールで出てくる利用者数は実際の2.4倍にもなっているというレポートが出た。サードパーティ・クッキーだと5.1倍となるらしい。

Cookieを削除なんてことをやっている人がそんなに多いとは信じにくかったのですが、社内で議論したところ、アンチウィルスの影響ではないかという説が。確かに、アンチウィルス製品の中には、「トラッキングCookie」をスパイウェアとして検出するものが存在します。それを素直に消しているユーザーはいるでしょうね。

この説が正しいとすると、アンチウィルス製品のシェア等によっても変わってくるのかも。

関連する話題: Web / セキュリティ

ブレイクスルー・トライアル

公開: 2010年5月16日11時30分頃

読み終わったので。

とある施設の警備システムの物理的な脆弱性を洗い出すための公開ペネトレーションテストを実施、侵入してマーカーを持ち帰ると賞金1億円、という設定。謎解きらしい謎解きは特にありませんが銃撃戦あり、爆破シーンありで、ミステリというよりハードボイルドアクションという感じですね。

施設内はほぼ無人で、アクションの相手は警備ロボットとなるのですが、その警備ロボットがまたあっさりと。最後の方は何かが発動したようですが、どういう条件でそうなったのか良く分かりませんでした。そうなる意味も良く分からないですし。

※本当はもっと長かったのを無理矢理削ったのかも。

関連する話題: 本 / 買い物

2010年5月8日(土曜日)

サガフロ2 クリア

公開: 2010年5月12日12時45分頃

サガフロンティア2 (www.amazon.co.jp)をクリアしました。

ラスボスではまる、と噂されていましたが、私は初見で撃破。ジニーのHPは400に満たなかったのですが、それでも特に倒れたりもせず、厳しい場面もありませんでした。スタークエイクでLPをもりもり削られましたが、それでもジニーのLPは6残りましたし。

後で確認したところ、どうも石形態と樹形態が強いようですね。私はたまたま石と樹の将魔獣を倒していたので (獣と音の将魔では粘り勝ちできることに気づかず、勝てないと判断してスルーしていた)、強い形態が出なかったという幸運がありました。また、普段LP消費回復を使わないスタイルだったのも良かったようです (LPを消費した状態でラスボス前でセーブするとハマるのですが、私は満タンでした)。

グラフィックと音楽、そして何より世界観が非常に良かったですね。

しかし、わかりにくいところも多かったです。特に、ギュスターヴ周辺の人間関係が分からず、正直何が何だか。

※以下ネタバレ注意。

終盤、グスタフがヴァンアーブルからギュスターヴの剣を渡されて、そこでグスタフの素性が明らかになります。重要なシーンのはずなのですが、私は「結局グスタフは誰?」と思ってしまいました。ファイアブランドの儀式で暗殺者に刺され、竜に連れ去られたフィリップ2世が実は生きていたのか……と思ったのですが、後で調べたところ、どうも違うようです。

グスタフに関係する人物を整理すると、以下のようになります。

で、フィリップ3世の子がグスタフらしいです。ケルヴィンの孫、デーヴィドの従兄弟にあたります。マリーの孫でもあるのでフィニー王家の血筋であり、ファイアブランドを継承しています。

と、ここまで説明されれば分かるのですが、そもそも、マリーがケルヴィンと再婚していたという話が本編に出てきません (シナリオの選択の仕方が悪かった?)。フィリップに息子がいることも示されていませんし、本編の情報だけで理解するのは無理だと思います。

結論としては、副読本としてアルティマニア (www.amazon.co.jp)の購入が強く推奨されるという事ですね。

関連する話題: ゲーム / PS3

2010年5月7日(金曜日)

WASForum Conference 2010 登録完了

公開: 2010年5月12日11時55分頃

WASForum Conference 2010 (wasforum.jp)ですが、プログラム (wasforum.jp)を見ると「ケータイ2.0が開けてしまったパンドラの箱」「どうするケータイ認証」というテーマが挙げられています。タイトルからして危険な雰囲気が漂っていて、ケータイサイトを実装することもある身としては聞いておいた方が良さそうですね。

このプログラムが発表になったのが4月30日。前回は会社のお金で行かせていただいたので、今年も……と思ったのですが、「5月6日までに振り込むと安くなる」というアナウンスが。「連休中に稟議を通すのは無理 (twitter.com)」とつぶやいたら、なんと「5/7まで (twitter.com)」としていただけました (ありがとうございます)。お言葉に甘えて昨日稟議を通し、本日振り込みました。

というわけで5月22日が楽しみです。

※そしてちょっぴり怖い。稟議書には「ケータイサイトのセキュリティに関して重大な事項が発表される可能性がある」と書いておきましたが、誇張ではないつもりなのです。

関連する話題: セキュリティ / WASForum Conference / WASForum Conference 2010

2010年5月3日(月曜日)

サガフロンティア2

公開: 2010年5月9日14時40分頃

PS Storeでサガフロンティア2 (www.amazon.co.jp)を購入してPS3 (www.amazon.co.jp)にダウンロード。

グラフィックと音楽は非常に良いのですが、システムが分かりにくい……。

シナリオ選択

ゲームスタートするとオープニング後、唐突にシナリオ選択画面になります。シナリオ選択画面からシナリオを選択して進めていく形なのですが、この選択画面が分かりにくい。特に、時系列が分からないので、話の流れが分かりにくいです……。時系列順の一覧で選びたかったです。

シナリオ自体は良いのですが、登場人物が多すぎて誰が誰やら……(特にギュスターヴ編)。

2種類の戦闘

通常のパーティバトルの他にデュエルという一対一の戦闘があるのですが、ルールが異なります。デュエルは事前に4回分のコマンドを入力して行動する形で、アンリミテッド:サガの戦闘に近い雰囲気です。

そして、難しいのが技の出し方。たとえぱ「払い抜け」を出す場合、通常戦闘では事前に「払い抜け」セットしておいて選択すれば良いだけです。が、デュエルでは「けん制」「払う」の順にコマンド入力すると技が出ます (ただし失敗することもある)。事前に技をセットしておく必要が無いかわりに、コマンドを覚えておかなければなりません。簡単に出る技は良いのですが、「ためる、集中、集中、叩く」「構える、集中、払う、突く」なんてのを全て覚えるのは厳しいです。技コマンド表を見ながらのプレイが前提なのでしょうか?

ロールと行動順

メニューの「バトルスタイル」から、ロールの設定や行動順の指定ができます。これ、しばらく存在に気付きませんでした……。ロールの効果は絶大なので、気付いていると戦闘のスタイルがかなり異なってきます。

訓練されたプレイヤーならともかく、そうでないとつらいかも。アルティマニア (www.amazon.co.jp)を買えば問題なく楽しめそうな気がしますが……。いろいろな意味で「アンリミテッド:サガ」に流れていく歴史を感じますね。

関連する話題: ゲーム / PS3 / PlayStation Network

2010年5月1日(土曜日)

Cookieのpath指定はセキュリティ的に無意味

公開: 2010年5月1日23時5分頃

「共用SSLサーバの危険性が理解されていない (takagi-hiromitsu.jp)」。内容としては、「Cookieのpath指定はセキュリティ的に無意味」という話ですね。

しかし、「安全な設定」として紹介されている以下の記述は誤りであり、全く安全でない。

(～中略～)

Set-Cookie: における「path=...」指定は、じつはセキュリティ上何の効果もない*3ことが昔から知られている。

Cookieを発行するときに path=/foo/ のように指定した場合、/foo/ 以外のディレクトリでは、Cookieを直接は読み取れなくなります。しかし、iframeを使うと、/foo/のコンテンツにアクセスすることができます。/foo/のコンテンツからはそのCookieを読むことができますから、結局、Cookieにアクセスすることが可能だというわけですね。

あくまで、ドメインを変えないと駄目ということです。

※ここではさくらインターネットが例に挙げられていますが、当然、さくらインターネットに限った話ではありません。

関連する話題: セキュリティ / secure.softbank.ne.jp

最近の日記

関わった本など