Googleが投稿したITPの欠陥に関する論文の紹介です。
tl;dr
- ITPのトラッキング判定はデバイス毎に行われるよ
- あるドメインがトラッキング判定されているかを知る方法がいくつかあるよ
- 特にそのドメイン・サイトが攻撃者管理なら
- ので、閲覧情報のリークやフィンガープリントとして使われる可能性があるよ
指摘している問題
この論文では、
- あるドメインがトラッキング判定されているか、別のサイト（攻撃者管理）で判断出来る(1,2,3,5)
- 攻撃者が、あるドメインをトラッキング判定させることが意図的に出来る(2,3,4)
ことがマズい場合を指摘しています。
1.トラッキング判定されているドメインを判定出来る（かもしれない）
トラッキング判定はユーザー毎に異なるので、トラッキング判定されているドメインがわかると、ユーザーの地域などがわかる可能性があります。
（例：hoge.co.jpがトラッキング判定されているから、日本在住っぽい）
2. ユーザーがあるWebサイトにアクセスしたかがわかる（かもしれない）
あるドメインがトラッキング判定されていれば、そこにリクエストするサイトに一回はアクセスしたことを意味します。
攻撃者管理のドメインを使えば、攻撃者のサイト(A)を訪れた後、別の攻撃者のサイト(B)で、サイトAへのアクセスの有無を判別することが出来ます。
3.フィンガープリントとして使われる（かもしれない）
- ユーザーに適当なビット列を割り振る
- 各ビットを攻撃者管理のドメインに対応させる
- 値が1なビットに対応するドメインをトラッキング判定させるようにリクエスト
- 以降、各ドメインがトラッキング判定されているかを調べ、ビット列を復元する
とすると、サイトを跨いでユーザーを特定するフィンガープリントに使えてしまいます。
同じようなことを、HTTPからHTTPSへのリダイレクトの記憶(HSTS)で行う手法もある（あった？）らしいです
（techscoreさんの解説がわかりやすいです）。
4.管理外のドメインをトラッキング判定に加えられる
攻撃者が管理していないドメインをトラッキング判定させることで、シングルサインオンなどのサービスを使用不可出来てしまうよねという話。
5. 検索結果のリーク(Cross-Site Search攻撃)
ITP以前からCross-Site Search Attacksという攻撃があります（mbsdさんの解説がわかりやすいです）。
攻撃者のサイトから検索を受け付けるページ（ECサイトとかWebメール）にリクエストを投げ、レスポンス時間の違いで、ユーザーの情報を探ろうとする攻撃です、
検索結果がトラッキング判定されるドメインへのアクセスを含んでいる場合、同じ事がITPのトラッキング判定でも出来てしまう可能性があるよという話です。
トラッキング判定されているかの判定
攻撃者がこの欠陥を利用するには、ドメインがトラッキング判定されているかを、攻撃者のサイトが知ることとが必要です（4除く）。
論文にはその方法がいくつか記載されています。
- 攻撃者が判定したいサイトを管理している場合、リファラかクッキーを見れば判定がわかる
- アクセス先に送るリファラ（＝アクセス元のURL）をむっちゃ長くして送ってみる
- アクセス先がトラッカー判定されていなければ、リクエストサイズが多すぎてリクエストが失敗する（サイトの設定次第）
- アクセス先がトラッカー判定されていれば、リファラが短縮され、リクエストが成功する
- などなど…