追記(2012/08/10 20:10)
たくさんの方に読んでいただき、ありがとうございます。一部に誤解があるようですが、ツールバーが送信している内容はURLだけで、Cookieやレスポンスまでも送信しているわけではありません。URLを送信するだけでも、以下に示す危険性があるということです。
追記終わり
追記(2012/08/13 23:50)
ポイントツールバーにバージョンアップがあり、WEB閲覧履歴の送信がSSL通信に変更されました。従って、WEB閲覧履歴が盗聴可能な状況は回避されました。本日22:50頃確認しました。
追記終わり
導入
Tポイントツールバーの導入は以下の手順です。- T-IDの登録(アカウント作成)
- ツールバーのダウンロード
- ツールバーの導入
使ってみる
それでは、さっそくTポイントツールバーを使ってみましょう。IE起動時の画面は以下となります。ツールバーの左端にTポイントカードのロゴがあり、その右に検索キーワードの入力欄があります。Tポイントツールバーは、Tサイトにログインした状態で使用する想定のようです。ログインしてから、入力欄に「育毛剤」と入力して検索してみます。
検索結果のドメインは、tsearch.tsite.jp ですし、T-IDでログインした状態なので、利用者のキーワード収集は、ツールバーではなく、このサイトの側で行っているのかもしれませんね。画面の検索ボタンの右に「Powered by Yahoo!」とあるので、検索エンジンはYahoo!のOEMなのでしょう。キーワード検索広告もYahoo!のもののようです。
WEB閲覧履歴の送信
ところで、Tポイントツールバーの利用規約には以下のように書かれています。第6条(履歴の収集)実際のところツールバーがWEB閲覧履歴を収集しているかを確認してみましょう。IEで、https://www.hash-c.co.jp/?PHPSESSID=ABCDEFGHIJK0123456789 を閲覧してみます。すると、以下のHTTPリクエストがPOSTされます。文字の一部をマスク表示して、読みやすいように改行を追加しています。xxxとなっているのは、謎の3バイトです。
1. 利用者は、当社が提供した本ツールバーをインストールした利用者端末による全てのWEB閲覧履歴(閲覧したURL、検索キーワード、ファイル名及びアクセス日時等の履歴情報をいい、以下「WEB閲覧履歴」といいます)が当社により取得されることをあらかじめ承諾するものとします。
POST /service/track.cgi?y=-8588570930699932058 HTTP/1.1log.opt.ne.jpというホストに、閲覧履歴が平文で(HTTPSではなくHTTPで)送信されています。
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727)
Content-Type: application/x-www-form-urlencoded
Host: log.opt.ne.jp
Content-Length: 183
Expect: 100-continue
Connection: Keep-Alive
xxx&
mid=4A7DZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ50170&
tlsc_l=NVEpO4ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZU_s&
u=https%3a%2f%2fwww.hash-c.co.jp%2f%3fPHPSESSID%3dABCDEFGHIJK0123456789
これは問題がありますね。閲覧履歴がカルチュア・コンビニエンス・クラブ株式会社によって取得されることは利用規約に書いてありますが、「閲覧履歴が平文送信されるので、カルチュア・コンビニエンス・クラブ株式会社以外のものに盗聴により取得されるかもしれない」ことは利用規約には書かれていないからです。
実はTカードツールバーの利用規約には以下のようにも書かれています。
第10条(免責事項)一般的に利用規約にはこの種の免責事項を書くものではありますが、免責を記しているからと言って利用者の閲覧履歴を粗末に扱ってよいということにはならないと思います。それに、FAQのページには以下のように書かれています。
1.利用者は、自己の判断と責任の下で、本ツールバーを利用するものとします。本ツールバーを利用したこと又は利用できなかったこと若しくは第3条に基づくTポイントの付与が受けられなかったことにより、利用者に損害、その他の不利益が生じたとしても、当社は一切責任を負いません。
上記は、データが漏洩しないとは書いていませんが、「テスト済みですので、ご安心下さい」と書いてあれば、多くの利用者は、カルチュア・コンビニエンス・クラブという大きな会社が運営していることもあって、データの安全性にも配慮してあるのだろうと暗黙に了解するのではないでしょうか。
URLの平文送信の影響
利用者の閲覧履歴であるURLを平文送信することにより、HTTPSアクセス時のURLが盗聴される可能性が出て来ます。この影響について考えます。まず、URLにセッションIDを埋め込んであるサイト(携帯電話向けサイトでは一般的な方式ですが、他のサイトにも存在します)では、セッションIDが盗聴されることにより、成りすましのリスクがあります。
また、セッションIDでなくても、URLに秘密情報を埋め込むことによりアクセス制御をする場合があります。また、画像ファイルやPDFについても、URLを秘密にすることによりアクセス制御をしているサイトがあります。とあるネットバンクの取引明細のPDFは、URLに乱数が埋め込まれていますが、URLを知っているとパスワードなしでアクセスできてしまいます。 このようなサイトについても、URLを盗聴されることにより、成りすましやデータの窃取の危険性が生じます。
これら、成りすまし等以外にも、どのページをアクセスしたかを第三者に知られたくないという状況もあるでしょう。Tポイントツールバーを導入すると、Webのセキュリティ強度は強制的に低下します。それは、利用規約などには書いていないことです。
利用者固有番号
追記(2012/08/10 20:25)
以下のパラグラフで、「固有の利用番号」を利用者にひもつくものと解釈しておりましたが、そう解釈する必然性はないことに気がつきました。むしろ、端末の結びついた情報と解釈した方が日本語としては自然かもしれません。しかし、端末にひもつく「番号」は機能の実現に不可欠とは言えないと考えます。一方、利用者にひもつく情報は、閲覧履歴を収集するという仕様を実現するためには不可欠なもので、それを番号と呼ぶか、ユーザIDと呼ぶかということに過ぎず、以下の指摘はやや的外れでした。指摘している脅威が存在することには変わりませんが、その原因は、(1)Web閲覧履歴を収集すること自体が問題、(2)仮に閲覧履歴を収集するなら暗号化して送信するべき、ということです。
追記終わり
Tポイントツールバーの利用規約には以下のように「利用番号」についての記載があります。
第6条(履歴の収集)「固有の利用番号」というと嫌な感じですが、先ほどのPOSTデータの中に、この「利用番号」は含まれるのでしょうか。先のPOSTデータには、mid および tlsc_l と言うパラメータがあり、ログイン・ログアウトしてもこの値は変わりません。これらのいち、私は tlsc_l の方が「固有の利用番号」のような気がしました。その根拠は、以下の通りです。
【略】
3. 本ツールバーには固有の利用番号が登録されています。当該利用番号は、本ツールバーが機能するために必要な情報であり、無効化あるいは削除することはできません。
- ツールバーインストール直後のT-SITEにログイン前の状態では、tlsc_lは空である
- T-SITEのWebアプリケーションの発行するCookieにも tlsc_l というCookieがあり、TポイントツールバーのPOSTする tlsc_l と値が同じ
- 端末を変えても、T-IDが同じなら tlsc_l は同じ。midの方は端末毎に変わる
- Cookieのtlsc_lの方も、ログイン毎に値は変化しない
「固有の利用番号」が、TポイントツールバーのPOSTデータについていることから、以下のような困ったことが起こり得ます。
利用者固有番号の悪影響
たとえば、PROXYサーバーを経由でアクセスしている場合、平文の(HTTPSでない)リクエストはPROXYサーバー上で監視することができます。一方、HTTPSのリクエストについては、アクセスしているホスト名まではわかりますが、URLは分かりません。しかし、TポイントツールバーのPOST値を監視できる立場の人は、「固有の利用番号」がついていることにより、特定ユーザの挙動把握が容易になります。
たとえば、とあるユーザが、https://twitter.com/#!/ockeghem/HiddenList を頻繁にアクセスしているとします。これはtwitterのリストのURLですが、このリストが非公開となっている場合、このユーザは、twitter IDがockeghem(すなわち私)であると推測できます。
すると、このユーザと同じ「固有の利用番号」がついてるWEB閲覧履歴は、すべて私のアクセスできることが分かってしまいます。
Tポイントツールバーの利用者にとって、WEB閲覧履歴がCCCに伝わることは利用規約上で(建前上は)許諾しています。しかし、第三者にもWEB閲覧履歴が漏れることまでは許諾していません。それが起こってしまう原因は、Tポイントツールバーの以下の設計上の問題に起因しています。
- WEB閲覧履歴の平文送信(根本原因)
- 「固有の利用番号」の存在(攻撃を容易にする要因)
まとめ
Tポイントツールバーについて紹介しました。Tポイントツールバーは、利用者のアクセス履歴(URL)をログ収集サーバーに送信しますが、(1)平文通信である、(2)固有の利用番号がつく、ことがセキュリティ上の問題となります。
とくに、利用者のアクセス履歴を平文で送信することにより、Webサイトのセキュリティ強度を勝手に下げてしまう点は致命的であると考えます。これが許容できる利用者は、ほとんどいないでしょう。カルチュア・コンビニエンス・クラブ株式会社は、至急、以下のいずれかの対処をすべきです。
利用規約に上記セキュリティ上のリスクを明記するWEB閲覧履歴の送信をSSL通信に変更する- Tポイントツールバーの提供を停止し、既存ユーザには強制アップデートにて履歴送信機能を止める。log.opt.ne.jpも停止する
※前2項を一応考えましたが、どう考えてもダメなので、当エントリ公開時に削除しました。
「Cookieのtlsc_lの方も、ログイン毎に値は変化しない」って最悪の設計じゃないですか
返信削除そうですね。あまりよくはないと思います。ユーザIDをCookieに入れるようなものですね。
削除しかし、WebアプリのセッションID(と思われるCookie)の方はログインの度に変化するので、最低限の基準は満たしていると思いました。そのため、ここには突っ込みませんでした。
# 他にも問題がないわけではなく、論旨とずれるので書いていないだけというものもあります。
指摘されている内容には全般的に同意なのですが、最後のまとめのところがよくわかりませんでした。
返信削除今回の件に関してはWEB閲覧履歴を収集すること自体の是非に関する問題とセキュリティの問題の二つが論点としてあると思うのですが、徳丸様のこのエントリでは後者を取り扱っていると判断しました。
それを踏まえて質問させていただきたいのですが、「WEB閲覧履歴の送信をSSL通信に変更する」ことで(1)平文通信である、(2)固有の利用番号がつく、というセキュリティの問題は解決するのではないでしょうか?(2についてはSSLにしても利用番号はついたままですが、暗号化して送信するようになるため。)
まとめのところの「WEB閲覧履歴の送信をSSL通信に変更する」に取り消し線が入っているのは、SSL通信に変更してもなおセキュリティ上の問題が存在するためなのか、WEB閲覧履歴を収集すること自体NGと考えているためなのか、どちらなのでしょうか?
お時間のあるときにお応えいただければ幸いです。
根本原因が履歴の平文送信であるのに、対策の2項(SSL通信への変更)がダメな理由を補足してもらえると嬉しいです。
返信削除コメントありがとうございます。対策2が駄目とした理由は書き漏らしていました。確かに、このエントリで書いた内容からすると、SSLで閲覧履歴を送信すれば、とりあえずの問題はなくなります。
返信削除私が対策2を駄目とした理由は、本サービスは閲覧履歴を送信する必然性がないわけで、それにも関わらず「SSLにすればOK」と書く訳にはいかないということです。
過去に、はてなツールバーに似たような問題があって、髙木浩光氏が日記に書かれていますが…
「はてなツールバー」がHTTPSサイトのURLを平文のまま送信していた問題
http://takagi-hiromitsu.jp/diary/20060205.html#p02
『任意のサイトのページにアクセスするたびに、アクセスしたURLをはてなに送信するようになっている。これは、今見ているページが「はてなブックマーク」などに何件登録されているか(図1の矢印部分)をリアルタイムに表示するために必要としている仕掛けだ。』
引用部分にあるように、はてなツールバーにはアクセス中のURLを送信する記述的な必然性があります。だから、このサービスを使いたい人は、リスクを認識した上で、URLの送信を受け入れるしかありません。
一方、Tポイントツールバーには、URLを送信する必然性はありません。だから、駄目だと思ったわけです。これに対して、検索キーワードを送信するのは、検索サービスを実装するのに必須の情報なので、送るなと言うわけにはいきません。
ご回答ありがとうございます。
返信削除Web上でのサービス提供するためにURLを送信する必然性がなければ履歴収集はNGとお考えゆえの記述だということがわかりました。
私個人としては、利用者の同意を前提として、履歴データのWeb上でのサービス提供目的以外の利用についても認めていくべきだと考えております。サービス提供者側の同意取得方法や利用者側のリテラシー等考慮しなければならない問題はありますが、問題があるから禁止ではなく、サービス提供者と利用者がお互いに成長し合いながら問題をクリアして、新しいサービスが生まれるような形になるとよいと思います。
エントリと直接関係ない話題で失礼いたしました。今後もブログを興味深く拝読させていただきます。
SSLで通信したとしても、送信している内容に query 文字列を含めているのであれば、その文字列には第三者のサイトのID/Password等「アクセス制御機能に係る他人の識別符号」が含まれている可能性があることは、WEB関係の知識があれば明白ですから、例えば不正アクセス禁止法が禁止している助長行為についてグレーですね。
返信削除したがって徳丸さんが例示されたように「検索サービスのURLと明白にわかっていて、かつ、その検索キーワード部分だけを送信している」というケースでなければ、そうした無差別的データ収集行為を行うこと自体が限りなく黒に近いと思います。
(不正アクセス行為を助長する行為の禁止)
第五条 何人も、業務その他正当な理由による場合を除いては、アクセス制御機能に係る他人の識別符号を、当該アクセス制御機能に係るアクセス管理者及び当該識別符号に係る利用権者以外の者に提供してはならない。
盗聴というのは、実際には問題にならないはずです。HTTP通信が盗聴されるとすれば、一般的にはISPかホスティング事業者のところだけです。しかも、盗聴するにはL3スイッチに仕込みをした上で別途盗聴サーバーを用意しないと駄目で、組織的に行わない限り盗聴は困難です。
返信削除サーバーが日本にあるなら怪しいところは経由しないであろうから、ほぼ問題はありません。履歴送信が平文で行われている事を問題視する必要は無いと思います。
SSLであろうと履歴送信が行われている事実は問題視されるべきですが・・・
コメントありがとうございます。
削除しかし、それを言い出せば、SSLなんて必要ないということになりますよね。
実際には、利用者の端末の近辺のネットワーク(無線LANなど)で盗聴されるリスクや、DNSに対する攻撃(Secuniaなど被害例多数)、ARPスプーフィング攻撃(心配しなくていいような気もするけど某データセンターで実際にあったので、ないとは言い切れない)などさまざまな方法で盗聴の可能性はあり得ますよ。