私は常日頃からある気がかりにとらわれていました.それは以前の私の常識に照らし合わせてみると,いささか突拍子もないものであり,私は,私がひとたびその考えを口にすれば,その相手が友人であれば顔をしかめ,あまり親しくない知人であれば二度と私に近づかなくなるであろうことを理解していました.
しかし私はとうとう見つけたのです.憎きあいつらに私と同じく苦しめられている人々を.彼らは,私の代わりに,私の気がかりが真実であると言う証拠を掴んでくれました.誓って言いますが,彼らが私に何かしたわけではありません.ただ淡々と事実を公開していただけです.私は彼らと共に闘う決意をしました.
あなたは私の言葉を信じないかもしれません.少し前までは,私自身,私の考えは突拍子もないものだと信じていたのですから.しかし,いずれは来るであろうあなたが気付く時のために,このアドレスを残しておきます.
上に書いたようなことがインターネットの世界では結構頻繁に起きているのではないかと,某掲示板を見て思ったり.
インターネットは良くも悪くもフラットな構造をしています.そこにある情報がメジャーなのかマイナーなのか,あるいは正しいのか間違っているのかということは,なかなか判断できません.また,マイナーで一般には間違った考えに基づくものであっても,日本中,あるいは世界中といった規模の母集団があれば,数十人単位のコミュニティはあっさりと出来上がってしまう可能性は十分にあるでしょう.そうした情報に触れたときに,はたして私は正しい判断ができるのだろうか.
そういえば,某まんがにそういう落ちの話があったなぁ.
午前中は作戦会議.日ごろからもう少し積極的に行動すべきだったと反省.
午後いちで不明点を総務に問い合わせ.どうもあちらもよく分かっていないらしく,2度ほど確認の電話があったものの結論はもう少し待てとのこと.
復習あり、新しい話ありで充実した内容でした。ただ、時間配分が…Cookie固定の話題については、高木さんの発表とは別に、某言語の標準ライブラリで、サーバがセッションIDを発行する前にクライアントからセッションIDを渡されると、それを採用してしまうという問題があったのを思い出しました。
あと、まぎらわしくないドメイン名を使うという指摘もありましたが、業者が自分のドメインに対してそうするのは当然として、悪意のある第3者がまぎらわしいドメインを勝手に取得することについては防ぎようがないよなあと思ったり。さらにそのドメインで、夜のBoFで星澤さんが発表したような、警告の出ない証明書を取得されたらどうするのかというのは、前にも指摘しましたが、大きな問題だよなあと改めて感じました。
これは今の仕事と見事に絡んでいて、非常にためになるセッションでした。法律の話から始まり、個人情報の漏洩が起きてしまったときの対処の話、著作権の話、ECサイトと法律の話と続き、メインとして、いわゆるプロバイダにおいて、自社のユーザーが違法情報を公開している可能性があるときに、どういうリスクがありどういった対処をすべきかという話でした。最後のやつは違法情報媒介というそうです。
セキュリティホールmemo のBoF。
1発目はオライリーの方による技術系出版の現状について。オライリーから萌え本を出すことを一瞬だけ考えたが、提案する勇気はなかったというお話に妙に納得。
2発目は星澤さんのフィッシングにかんするプレゼン。さまざまな方法の紹介の中に、高木さんの項で触れた正規の証明書を取得したフィッシングサイトの話もありましたが、会場では特に反応なし。星澤さんも認証局側の問題だと思うと言っただけで流していましたが、例えば、QuickSSLとかは、admin@【ドメイン名】にメールが届きさえすれば、証明書を発行しますということを堂々と書いています。本当にそれ以外に確認作業があるのかどうかは、実際に証明書を入手してみないと分かりませんが、ほとんど確認なしで証明書を乱発する認証局が存在すると、今のWebセキュリティの枠組みが根本から崩れかねないと思うのですが、みんなスルーしているところを見ると、私が何か勘違いしてるのかなぁ。
3発目はアンプの話。だと何も分かりませんね。ある手法を使うと、パケットを増幅することができ、サーバへの攻撃に応用できるというお話。帰ったら自分のところの設定を見直さないと。
会場には無線LANがあり、今いるホテルも無料で有線LANがあるので、いつもと変わらない状態です。Web巡回に関しても、FEEDBRINGERの設定が終わった後だったのが幸いして、自宅にいる時とまったく同じ状態で使えるのが非常に嬉しい。
まさに狙ったかのように、CNET JAPANに389万件のドメイン名が虚偽または不完全な情報を使って登録されていたというニュースが。記事の中には
登録ドメイン名全体の5.14%に相当する231万件のドメイン名が、「明らかに、そして意図的に」虚偽の情報のもとで登録されていたというという記述もあります。
ふと思いついた実験でGoogle Analyticsの脅威がわかりやすく説明できそうだったので、デモ動画と解説を公開します。右の画像をクリックすると、動画(AVIファイル:20MB)を見ることができます。
このデモはあくまで可能性の提示であり、実際にGoogleがこういうことをやっているかどうか、私の関知するところではありません。また、動画中にはいくつかの実サイトが登場しますが、これは私がたまたま知っているサイトのうち、デモに都合が良かった、または、動画の取得時にたまたまリンクがあったというだけです。各サイト様におかれましては、運が悪かったということでご容赦ください。
◆ 動画解説
まず画面構成について説明します。画面左は実験用に準備した偽www.google-analytics.comの解析サーバのコンソールです。ここに、www.google-analytics.comに送られた解析用データを整形したものが表示されます。
右は何の変哲も無いFirefoxの画面です。動画では、最初にGoogleで「はてな」をキーワードに検索し、はてなのトップページに移動した後、「最近の人気記事」を開いて各種ニュースサイトを巡回します。
動画の流れとしては、右のFirefoxでWebを巡回している時に、www.google-analytics.comに送信される解析用データの様子が、左のコンソールにリアルタイムで表示されるようになっています。
以下、動画の冒頭について少し詳しく解説します。初期のGoogleの画面では私はログインしていて、右上にメールアドレスが表示されています。つまり、GoogleはHideki Sakamoto(hs@on-sky.net)の検索内容について、把握可能な状況です。ここでキーワードに「はてな」と入力して検索し、はてなのトップページに飛びます(0:25)。
はてなのトップページが表示されると、www.google-analytics.comに次のようなデータが送信され、左のコンソールに表示されています。
-----
IP: 192.168.xxx.xxx
TIME: 08/Dec/2007:23:07:10 +0900
HOST: www.hatena.ne.jp
UTMP: /
UTMR: http://www.google.co.jp/search?hl=ja&q=%E3%81%AF%E3%81%A6%E3%81%AA&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
UTMCC:
__utma=90496003.1296348447.1194094804.1197115118.1197119304.16;
__utmb=90496003;
__utmc=90496003;
__utmz=90496003.1197119304.16.10.utmccn=(organic)|utmcsr=google|utmctr=%E3%81%AF%E3%81%A6%E3%81%AA|utmcmd=organic;
UTMR変数にはリファラであるところのGoogleの検索ページのURLが、検索語「はてな」を含む完全なURLとして入っています。さてここで、「08/Dec/2007:23:07:10 +0900」に「www.hatena.ne.jp」を訪問した、__utmaの最初の2つの数字(以下、「個人ID」とする)が「90496003.1296348447」である人物がhs@on-sky.netであるということは、もし仮にGoogleが検索についてログを記録している場合、IPアドレスと検索語、および上記TIMEの前後の時刻を照合することにより把握することができます(しつこいようですがあくまで仮説です)。という話はひとまず置いておいて、次の説明に進みます。
動画では、0:30にページ内にある最近の人気記事の一覧リンクをクリックしています。このリンク先はb.hatena.ne.jpで、ここでまたwww.google-analytics.comに次のようなデータが送信されています。
-----
IP: 192.168.xxx.xxx
TIME: 08/Dec/2007:23:07:15 +0900
HOST: b.hatena.ne.jp
UTMP: /hotentry
UTMR: http://www.hatena.ne.jp/
UTMCC:
__utma=12101991.1308323039.1193486202.1197115125.1197119312.12;
__utmb=12101991;
__utmc=12101991;
__utmz=12101991.1197119312.12.12.utmccn=(referral)|utmcsr=hatena.ne.jp|utmcct=/|utmcmd=referral;
b.hatena.ne.jpとwww.hatena.ne.jpは異なるサーバなので、個人IDには別の値「12101991.1308323039」が入っています。ところが、IPアドレスについては当然1つ目と2つ目のエントリで同じです。また、1つ目のエントリのHOSTとUTMPを組み合わせれば、2つ目のUTMRとの照合ができます。このような2つのデータの照合により、www.hatena.ne.jpにおける個人ID「90496003.1296348447」と、b.hatena.ne.jpにおける個人ID「12101991.1308323039」が同一人物であるということが分かり、1つ目のエントリの解説にある仮定が本当なら、それがhs@on-sky.netであると特定できます。
さて、動画では0:36に読売新聞のサイトに飛んでいますが、ここはGoogle Analyticsを使っていないようで、www.google-analytics.comには何も届きません。ただし、ブラウザの戻るボタンをクリックしてはてなのページに戻る(0:40)と、www.google-analytics.comには2つ目のデータとまったく同じデータが再び届きます。Google Analyticsではこうやって戻るボタンでページに戻ってきたことを把握可能なようです。
さらに動画では0:48にwww.ideaxidea.comというサイトに飛んでいます。ここもGoogle Analyticsを利用しており、先ほどと同様、IPアドレス、b.hatena.ne.jpエントリのHOSTとUTMP、www.ideaxidea.comエントリのUTMRを照合することにより、www.ideaxideax.comの個人ID「236144985.1540274803」がb.hatena.ne.jpの個人ID「12101991.1308323039」と同一人物であると特定できます。
あとは同様な処理を繰り返すだけで、b.hatena.ne.jpの個人ID「12101991.1308323039」と同一人物である他のサイトの個人IDは収集可能です。動画の中では最終的に次のサイトと個人IDを収集できています。
www.hatena.ne.jp | 90496003.1296348447 |
b.hatena.ne.jp | 12101991.1308323039 |
www.ideaxideax.com | 236144985.1540274803 |
codezine.jp | 2413090.890357120 |
www.goodpic.com | 141067684.491258399 |
www.100shiki.com | 169936416.1719369956 |
code.google.com | 247248150.894477186 |
internet.watch.impress.co.jp | 180657279.1043611980 |
www.excite.co.jp | 148185315.1361122659 |
gigazine.net | 208899204.21573543 |
zapanet.info | 133676037.963137375 |
あらためて見るとかなりのサイトに浸透してます。
一方で、動画中の巡回先でGoogle Analyticsを利用していないサイトは以下の通りです。
komachi.yomiuri.co.jp |
mainichi.jp |
sankei.jp.msn.com |
www.itmedia.co.jp |
www.asahi.com |
www.watch.impress.co.jp |
portal.nifty.com |
ちょっと面白い結果ですが、単に予算の都合だけなのかもしれませんし、これだけではなんとも言えません。
◆ ユーザーが可能な対処
こうしたブラウザからGoogle Analyticsに追跡用のデータが送られることを阻止する方法は、Firefoxならいくつかあります。Internet Explorerについては残念ながらよく知りません。
1つは、Google Analyticsへのトラッキングコードがhttp://www.google-analytics.com/__utm.gifまたはhttps://www.google-analytics.com/__utm.gifという画像ファイルへのアクセスの形で送信されることを逆に利用する方法です。具体的には、
これで現状では十分な対処となりますが、Googleが解析用のURLを画像ファイル以外の拡張子を持ったファイルへと変更すると、この方法は使えなくなります。ただしその場合でも、次の方法を使えば対処可能です。
その方法とは、9月6日のエントリへのコメントでinoueさんに教えてもらったAdblockというFirefox用のアドオンを利用するものです。このアドオンをインストールした後、以下の手順でgoogle-analytics.comへのアクセスを禁止にします。
これで、google-analytics.comへのアクセスがブロックされるので、結果として追跡用のデータが飛ぶこともなくなります。
9月1日のエントリ内の画像にあるように、当時はGoogle Analyticsで利用されているファーストパーティcookieの有効期限は2038年1月18日9:00に固定されていましたが、いつの間にやら修正が入って、2年間になっていました(左図)。が、これはまったくもって無意味です。
なぜなら、ファーストパーティcookieの有効期限は、Google Analyticsを利用しているサイトを訪問するたびに更新されるからです(右図)。
左右の図を比べてみれば分かるとおり、__utmaに含まれる個人IDの部分は「169936416.1719369956」という同じ値であり、有効期限が2009年12月7日1:38:25から13:54:10に変わっています。これは、最後にアクセスしてから2年以内に同じサーバ(図の例では100shiki.com)にアクセスすれば、「169936416.1719369956」という個人IDはさらに2年間有効期限が延長されるというサイクルが繰り返されるだけであり、毎日とか週1とか月1とか年1とかぐらいの頻度で訪問しているサイトであれば、半永久的に同じ個人IDが使われるということを意味します。
で、Googleの中の人は何を考えてこんな変更をしたんでしょうか。意味不明です。
Before...
- hs [この正月は久々に帰省するので,何かご希望があれば快気祝いに送るよ.>taru_k]
- taru-k [やはり厳しかったか...スンマセン。ギリギリを狙ったのだが、適当に削除してくれてもOKです。"快気祝い"は別途連絡し..]
- hs [いえ,今後は「お国自慢」も書いていきます.という宣言だと思ってください.特定されても恥ずかしくないことを書いていけば..]