前回 http://d.hatena.ne.jp/mala/20111125/1322210819の続きです。
前回のあらすじ
といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。
サードパーティCookieが必要とされてきた歴史
広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾つか混ぜる。
2005年
- Netvibes、iGoogleなどのパーソナライズホームページサービスが登場する。
- 「ガジェット」としてログイン済みの外部サイトをiframeで埋め込むものが存在してきた。
- GoogleはP3Pヘッダを使ってログイン状態の外部サイトを埋め込むことが出来ると案内している
- NetvibesはSafariユーザーに対して全てのCookieを受け入れるように案内している
- JSONPが使われ始める
- JSON with Padding http://ajaxian.com/archives/jsonp-json-with-padding
- 関数名固定のcallbackが呼ばれるものから、クエリパラメータでcallback関数名を指定できるものが広く使われるようになる
- MyBlogLogが開始
- アクセス解析サービスで、ユーザ登録することでBlogに誰が訪問したのか分かるサービス。
- 後に米Yahooに買収、日本でも類似のサービスがいくつか出ることになる。
2006年
2007年
- 1月、YahooがMyBlogLogを買収する。
- 4月、GoogleがDoubleClickの買収を進める
- 7月、はてなスターがリリース(七夕の季節)
- 10月、DISQUS埋め込みのコメント欄を提供するサービス、サードパーティCookieによって認証している。類似のサービスが幾つか。
- サードパーティCookieも含めて送受信を許可するように案内している http://gyazo.com/95c71b727abcb50cf664f147812b0119
- 参考 http://docs.disqus.com/help/26/
- 12月、gooがgooあしあとを提供開始 http://itpro.nikkeibp.co.jp/article/NEWS/20071220/289990/
- 12月、米連邦取引委員会がGoogleによるDoubleClick買収を承認した http://www.itmedia.co.jp/news/articles/0712/21/news017.html
2008年
- 3月、Yahoo JapanがYahooログールをリリース。yahoo.co.jpのCookieを使用。足あとが残るのは登録ユーザーのみ。
- 3月、欧州委員会がGoogleによるDoubleClick買収を承認した http://www.itmedia.co.jp/news/articles/0803/12/news016.html
- 6月、Firefox3がリリースされる。
- 8月、Yahoo Japanがインタレストマッチを開始
- 9月、クリックジャッキングの問題が知られるようになる。
- 全てのブラウザ、全てのWebサイトに影響するとしてブラウザベンダーが対応を表明した。
2009年
- 1月、IE8RCがリリース、クリックジャッキング対策としてX-Frame-Optionsが導入される。
- Webサイト側でフレーム拒否のヘッダを出力するというもので、サイト側の対応が必須であった。3月にIE8が正式リリース。
2010年
- 4月、Facebookが外部サイト向けのlikeボタンを提供する http://jp.techcrunch.com/archives/20100421facebook-like-button/
- 9月、mixiが外部サイト向けのmixiチェックボタンを提供する
- 12月、mixiが外部サイト向けのイイネボタンを提供する http://developer.mixi.co.jp/connect/mixi_plugin/favorite_button/get_html_code/
- 似たような機能を続けてリリースしているがチェックボタンはポップアップウィンドウで投稿、イイネボタンはワンクリックで投稿完了するものとなっている http://developer.mixi.co.jp/connect/mixi_plugin/difference_of_mixicheck_favorite/
- イイネボタンは、イイネを押した友人の一覧が表示できるようになっている(サードパーティCookieによる表示のパーソナライズを行なっている)
- イイネボタンはサードパーティCookieを送信しないとエラーが起きて動作しない。
2011年
- 足あと終了ブーム
- 3月、gooあしあとが終了する http://blog.goo.ne.jp/ashiato_01/e/876cfd81489c43363b60ac4f4305624b
- 5月、米YahooのMyBlogLogが終了する
- 6月、Yahoo Japanの Yahooログールが終了する
- 6月、mixiは足あと機能を先週の訪問者に変更する(念のため書くと、他のサービスと違い外部サイト上からmixiアカウントを把握されうるのはmixiにとっては意図せぬ挙動である)
- 6月、Googleが外部サイト向けの+1ボタンを提供する http://googlejapan.blogspot.com/2011/06/1.html
- 7月、サードパーティCookieブロックすると google.co.jp にログインできない状態になる
- https://twitter.com/bulkneets/status/87321175977500672
- https://twitter.com/bulkneets/status/87767649244823552
- imgタグやiframeによるCookieのセットに成功すると期待して、シングルサインオンを設計した場合、ユーザーの設定によっては全くログイン出来ないことになる。
- いつから発生していたのか不明、比較的直ぐに解決されたと記憶している
- 8月、Google Puzzleが公開
- 途中までプレイできるがサードパーティCookieをブロックしているとエンディングが見れない
- https://twitter.com/sh4/status/103803450004996096
寸評
個々のサービスついて色々と思うところもあるが特にこの記事で深く掘り下げたりはしない、把握している範囲で述べているだけなので、これ以上に影響の大きいサービスもあったかもしれない。
- ブラウザの機能追加によって、仕様を設計する段階では想定されていなかったリスクが発生している。
- 攻撃手法がWeb開発者に知れ渡るまでにも時間がかかる。JSON Hijackやクリックジャッキングが知られるようになったのは「ブラウザの実装上そのような攻撃が出来る状態」になってから随分と先のことだ。
- 開発者がどういったリスクが発生するのかを知らずに実装してしまうケースが多々ある。
- 意図せずに足あとを残す(訪問者のユーザーアカウントを特定する)リスクがあるサービスは、近年、機能を変更したり終了する傾向にある。
- 2007年ごろ(はてなスター登場時)、自分は、サードパーティCookieに依存したサービスを作ることで、ユーザーやブラウザがプライバシーに配慮したデフォルト設定を選択することができなくなる、と主張していた。
- 実際にブラウザはプライバシーやセキュリティに配慮したデフォルト設定に変更することが出来なかったし、今もなっていない。
- GoogleはDoubleClick買収以降、サードパーティCookieを積極的に利用する傾向にある。
- ちなみにGoogleはログイン時に P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."というヘッダを送る
- 誰が望んでこうなったのかと言い切ることはできないだろう。Web業界渾然一体となってサードパーティCookieに依存したサービスを作り、無効化すると利用できなくなったり、不具合に遭遇したり、不便を被ったりする世の中を作ってきた。
Web開発者の多くは、単にブラウザの仕様に合わせてサイトを作っているだけで、自分の作るサイトがブラウザベンダーの意思決定に影響を与えているという自覚が希薄かも知れない。また「悪用されたら対策を考えれば良いだろう」とリリース時には単にspamやイタズラに使える程度であろうと考えていた脅威が、実際にはサービスの性質そのものに関わる問題であり対処のしようがない、と後から気付いた所で手遅れだったりもするだろう。ユーザーに対して「そのようなサービスを使うべきではない」と言った所で、自己責任で片付けられてしまうだろう。サードパーティCookieの送受信に依存したWebサイトを作る(あるいは使う)ということは、大多数のインターネットマニアでもセキュリティオタクでも何でもない普通の人たちがWebを安全に利用することができないという、そういう状況を肯定することに繋がっている。
Web開発者はどうすべきなのか？
- まずWeb開発者は(少なくとも自分が開発に関わるサービスの動作確認をする時には) サードパーティCookieの送信をオフにすることを強く推奨する。ついでにリファラの送信も止めていい。
- サードパーティCookieをブロックする設定にしたFirefoxかGoogle Chromeで動作確認をすれば良い。
- 上で挙げたような「ログイン状態のiframeやJSONを外部サイト上から利用する機能」が動かなくなる、ということを把握していれば、大した不便を感じることは無いだろう。
- ブラウザは不適切なデフォルト設定を修正してこれなかっただけなので、自信を持っていい。IEとSafariを見習うべきである。
- ユーザー目線に近いように「ブラウザをデフォルト設定で使う」というポリシーの人もいるだろう。しかしこれは「本来ユーザーに与えられていた選択肢」を取り戻すためのものだ。
- サードパーティCookieオフでは全く動作しない(ログイン出来ない、表示できない、無限リダイレクトする)ようなものは論外で、回避手段を用意すべきである。
- 足あとを残すサービスは、そもそもが、悪意のある第三者に訪問者のユーザーアカウントを特定されるリスクが伴うことになることを理解すべきである。
ブラウザはこれからどうするべきなのか？
- 2001年とは状況が変わっている、現実問題サードパーティCookieに依存したWebサイトが多くあり、トラッキングCookieを利用したターゲティング広告が広く普及し、その収益に依存したWebサイトが多く存在している。
- (よほどユーザーの関心が高まらない限り) WebブラウザがデフォルトでサードパーティCookieをブロックするということが現実的にありえないという状況になっている。動作しないサイトが出てきて文句を言われるためだ。
- Do Not Trackの策定によってプライバシーを気にする人、トラッキングされたくない人はDNT: 1を送ればいいじゃん、という風潮になりつつある。
- しかしDo Not Trackヘッダでは「ログイン状態で外部サイトに埋め込まれることによって発生している諸々のセキュリティ上の問題」が全く解決しないままである。
サードパーティCookieが無効でも動作するようにするにはどうすればよいか
- 今からサービスを作る人は、単にサードパーティCookieを無効化して動作確認をすれば良い。
- 現実問題ユーザーはサードパーティCookieを送ってくるので、ログイン状態で外部サイト上に埋め込まれることで発生する諸々のセキュリティ上の問題に対処しなくてはいけない。
- 既にサードパーティCookieに依存したサービスを作ってしまっている場合に、どうすれば良いのかについて述べる。
ダメなシングルサインオンサービス編
ソーシャルボタン編
1. 単純に別windowでlikeなり+1なりスターなり押させれば良い
- 未ログインの場合には、どうせ別windowで認証画面を開く実装になっているのが殆どである。
- 別windowではファーストパーティCookieとして認証Cookieが送られるのだから、何の問題もない。
- クリックジャッキングも防げる。
- ユーザー毎に表示をカスタマイズしたりするのは、諦めるか、localStorageを使う
2. サードパーティCookieの代替手段として、localStorageを使う
- localStorageにユーザーを識別するためのAPI tokenなどを保存しておくことで、サードパーティCookieの代わりに使うことができる。
- localStorageはCookieと違って、サーバーに勝手に送信されることがない。
- 訪問した段階ではサーバーサイドで誰がアクセスしてきたのかを識別せず、ボタンをクリックした段階でユーザーを識別することが出来る。
- 主サービスとCookieを共有しない別ドメインで提供すれば、ログインCookieをトラッキング目的で使っているという疑いを晴らすことが出来る。
- 純粋にlocalStorageとして使われるのか、保存した値がサーバーに送信されるのかはコードを読まなければ判別が付かない。
- ブラウザはサードパーティlocalStorageの利用に対して、ユーザーに対して通知バーを出し許可を求められるようにすべきである。
「全ユーザー共通のレスポンスを返す」ような埋め込みパーツは、この方式で完全に置き換えることができる。問題は「このページをいいねと言っている友人の一覧」など、ユーザー毎にパーソナライズされたレスポンスを出力する必要があるケースだ。幾つか解決手段があるだろう。
パーソナライズドホームページの類
- OAuthを使う例が紹介されている http://code.google.com/intl/ja/apis/gadgets/docs/fundamentals.html#Cookies
- 上記のように、今であればlocalStorageを代替手段として使うことも出来るだろう。
- サーバーサイドでOAuthのプロキシをしなくても、localStorageやpostMessageといったHTML5の機能を使うことで、クロスドメインでのデータの受け渡しは容易になっている。
OAuthによる認可を与えたり、URLにpasswordやAPI tokenを付加するなどの方法が考えられるが、これは、ガジェット機能を提供しているプラットフォーム(この場合はGoogle)がその気になればユーザーのデータにアクセス可能であることを意味する。認証情報を預かっている以上、ユーザーに代わって操作できる状態になってしまうことが避けられない。つまり、プラットフォームが信頼できないのであれば、サードパーティCookieによって認証されたiframeを読み込んで直接操作したほうが安全、ということになる。外部サービスにidとpasswordを預けるよりもログイン状態のiframeを埋め込んだほうが遥かに安全である。
クリックジャッキングのような問題にどう対処すれば良いのか
- クリックジャッキングに対するブラウザベンダの対応はX-Frame-Optionsによってフレーム内表示を拒否するという方法だった。
- 「iframeを使ってログイン状態で埋め込み、確認なしでワンクリックで反映される」という機能を作る以上、クリックジャッキングは防げない。
- ログイン済みのiframeを外部サイトに埋め込むことを前提とした場合、そもそも安全に実装することが出来ない。
- そのような機能を作るなといっても、もう作ってしまった場合にどうすれば良いのかについて述べる。
- どうしても確認なしで実行することに拘りがあるのであれば「勝手にクリックされても、大きな影響がない程度の機能にのみ用いる」というアプローチが考えられる。
取り消しが可能な操作であっても、ボタンを押したことが第三者に伝わるのであれば、それは意図せずにユーザーアカウントを外部から特定可能な脆弱性となる
- クリックした結果が知られるのが「自分のみ」に限定されているなら、意図せずにクリックされても影響は軽微と言えるだろう。単に効率の悪いspamである。
- またクリック結果が知られるのが「友人のみ」でも、早期に気付くことが出来ればワーム的に拡散していくことは防げる。
クリックしたことをWebサイト側からスタイル制御不能なブラウザ側のUIで通知して、取り消し可能にするというアプローチもあるだろう
外部サイトに広く埋め込まれるようなサービスを設計する際にどうすればいいのか
- 外部サイト埋め込みを前提としたサービスは、主サービスとCookieを共有しない別ドメインで提供し、登録ユーザーにだけ使わせるべきである。
- 別ドメインにする理由は単純だ、Web履歴を収集されても構わないと考えているユーザーだけが有効化にすることが出来るからだ。
- 「広告」や「外部埋め込みパーツ」にGoogleやFacebookやYahooなど、既にログインして広く受け入れられているCookieを用いることに、倫理的な問題がある。
- ユーザーは単に提供される便利なサービスを利用するために、Cookieを受け入れたのであって、外部サイトのWeb訪問履歴を把握されうるということについて、正確な知識を持ち合わせていない。
- (実際にやっているかどうかともかく) その気になれば彼らはGoogleFacebook Yahooのユーザーアカウントと紐付けて、外部サイトの訪問履歴を把握することができる。
- 大手ポータルサイトやSNSが、サードパーティCookieに依存した外部埋め込みパーツを提供し、サードパーティCookie無効では動作しない機能を提供してしまっている。
- 単に実装した人が「サードパーティCookieオフで動作確認をしていないマヌケ」である可能性もあるが、意図的にこういったことをやっている可能性もある。
ブラウザの設定変更を促すことについての問題
- サードパーティCookieがオフでも正常に動作する代替手段があるにも関わらず、実装の簡便さのために、サードパーティCookieに依存した手抜き実装がまかり通ってしまっている。
- サードパーティCookieに依存しない実装をすることが一番良いが、そのような変更を行うことが困難な場合は、リスクを周知した上でサイト毎にサードパーティCookieを許可する設定を案内することが考えられる。
- Safariのようにサイトごとに受け入れ設定を変更することが不可能な場合、ブラウザ全体の設定変更を案内する結果となってしまっている。Safariが悪い。
- IE6以降やSafariにおいては、キチンと理由があってサードパーティCookieをブロックするデフォルト設定を採用しているわけだが、ほとんどのサイトがCookieを全て受け入れる設定に変更するにあたってどのようなリスクがあるのかを的確に説明していない。
- DISQUSのように、提供サービスのドメインのみをCookie許可のホワイトリストに入れるよう案内する方がマシである(Optional:の部分) http://gyazo.com/95c71b727abcb50cf664f147812b0119