CNAMEクローキング: DNSを使ったサードパーティCookieの隠蔽

This post is also available in: English (英語)

概要

皆さんはWebサイトを見ているときに、自分が見られているような気がすることはないでしょうか。だとしたら誰が、そのWebサイト、さらにはインターネット全般を通じ、私たちの振る舞いを観察しているのでしょうか。そうした情報の流れを制限したり、せめてその流れを把握しておくことは可能でしょうか。

インターネットはほぼ広告を中心に回っていますので、人びとのオンライン活動の監視から利益を得る企業にとってはユーザーデータが非常に貴重なリソースとなっています。そうして集められた情報が(本当に必要だったものとまではいかないにせよ)よりよいユーザー体験につながることは多いでしょう。ただし、トラッキング行為によるプライバシー侵害への懸念も起きるべくして起きています。

こうした懸念を受け、多数のグループがツールの開発やアプリケーションの改修でユーザープライバシーを保護しようとしてきました。そうした対応のひとつが、主要ブラウザで採用されているサードパーティCookieのブロックです。この対応により、分析や広告、マーケティングを生業とする企業は、ユーザー情報収集戦略の練りなおしにせまられました。そうした戦略のひとつが本稿で紹介する「CNAMEクローキング」です。

CNAMEクローキングは、ブラウザが情報を送信するさい、その情報をWebサイトの所有者が管理するドメインにとめおかず、サードパーティ(広告主など)が管理するドメインにも送信することを、ドメインネームシステム(DNS)を使って隠蔽する手法です。CNAMEクローキングは、一部のユーザーがプライバシー保護に使っているしくみを損なったり、ユーザープライバシーを損なうさらに別の慣行につながったり、そうした慣行と一緒に使われてしまうおそれがあります。

パロアルトネットワークスは、CNAMEクローキングに使われているドメインを検出するシステムを開発しました。この検出器が生成した知見はパロアルトネットワークスの次世代ファイアウォール製品をご利用のお客様でDNS セキュリティや高度なURLフィルタリングなどのクラウド配信型セキュリティサービスをお持ちの方にご利用いただけます。

関連するUnit 42のトピック

DNS

目次

トラッキングがCookieにつながる理由
Cookieブロックのしくみ
CNAMEクローキングとは何か
防御
実際のCNAMEクローキング検出事例
サードパーティCookieのクローキング
Cookie同期による防御の回避
Cookieの流出
結論
追加リソース

トラッキングがCookieにつながる理由

Webで利用できるコンテンツやサービスの多くは広告収入で成り立っています。そして広告は歴史的にトラッキングに依存してきました。この関係は広告主がマーケティング活動の効率を最大化したがることに起因しています。

広告主による効率最大化の方法のひとつが、ユーザーに表示する広告を購入してもらえそうな商品やサービスにしぼる方法です。では広告主はどの広告を出すのがよいかをどう判断しているのでしょうか。これには(それこそクッキーを作るときのような)型にはまった方法というものがないのですが、現在はトラッキングが一般的な方法となっています。

インターネットの文脈でいうトラッキングとは、Webサイト内または複数のWebサイトにわたる人びとの活動を監視することを意味します。トラッキングはさまざまな役割で有用です。

たとえばWebサイトの所有者は、トラッキングデータを使って、ユーザー体験をパーソナライズしたり、ショッピングカートの状態を保持したり、広告キャンペーンの効果を測定したりすることができます。顧客にとってもメリットがあり、トラッキングを合理的な範囲にとどめていればプライバシー関連の問題も制限されます。ところが実際の運用では、情報共有範囲が特定Webサイトや企業をこえて広がることが多いのです。

Webサイト所有者も広告主も、分析やマーケティングを専門とする企業のサービスを利用しており、その中にはユーザーデータの受け渡しが含まれることがあります。そうしたデータには個人情報が含まれることがありますし、たとえ個人情報が含まれていなくても、さまざまな関係者がユーザーの関知も同意もなく複数のサイトやデバイスでユーザー情報を収集しうることから、多くの人びとが懸念を抱いています。

こうした懸念を受け、主要なブラウザ開発者は、特定の種類のトラッキングから人びとを保護する機能を導入しはじめました。そうして行われた大きな変更のひとつが、ブラウザによるCookieの扱いかたの変更です。たとえばサードパーティーCookieをブロックしたり、Cookieへのアクセス方法に制限を設けたりしました。

Cookieブロックのしくみ

Cookieとは要するにWebサイトがユーザーに与えるトークンのことです。ユーザーのブラウザはWebサイトと通信するさい、このトークンを送信することが期待されています。

Cookieはリクエストとユーザーを結びつけるという意味でトラッキングをしやすくしてくれますし、Webサイトの所有者にユーザーの行動について教えてくれます。

「ファーストパーティーCookie」とは、あるユーザーがあるWebサイトを閲覧しているとき、そのWebサイトをホストしているドメインの所有者が生成するものです。「サードパーティーCookie」とは、ユーザーがそのとき閲覧していないドメインによるCookieで、通常は広告のために使われます。

例として、あるユーザー(アリス)がwww[.]example[.]comを閲覧しているとします。また、ドメインexample[.]comを所有しているのはボブで、ボブは当該ドメインでホストされているWebサイトをユーザーが訪問したさい、そのユーザーにCookieを送信するよう、自分のサーバーを設定しているものとします。アリスがexample[.]comのほかのページ(たとえばchocolate_chip.example[.]comやwww[.example[.]com/gersnap)を閲覧した場合、アリスの送るメッセージにはこのCookieが含まれることになります。図1はこの流れを図示したものです。

Cookieの属性とアリスのブラウザの設定によりますが、アリスのexample[.]comへのリクエストがCookieを含むのは、アリスが既にexample[.]comを閲覧していた場合に限られます。たとえば、アリスがすでにwww[.]example[.]comを閲覧している場合、アリスのブラウザが次にexample[.]com/oatmeal.pngへのリクエストを行うのであればCookieを含めますが、www[.]example[.]netへのリクエストを行うのであればCookieを含めません。この制限のおかげでアリスのほかの訪問先サイトをボブは見られず、アリスのプライバシー保護に一役買ってくれます。

アリスのプライバシーを守るもうひとつの方法として、アリスのブラウザは、アリスがexample[.]netを閲覧中、example[.]net以外のドメインが設定しようとするCookieをブロックできます。例をあげて説明しましょう。たとえば、ads[.]example[.]comからの広告が、www[.]example[.]netに表示されたとします。ads[.]example[.]comの所有者は、広告を提供するさい、アリスのブラウザにCookieを送信します。これがサードパーティーCookieにあたります(図2参照)。ここで、アリスのブラウザがサードパーティCookieをブロックするように設定されている場合、このCookieはその後のリクエスト時にexample[.]comには返されません。

CNAMEクローキングとは何か

サードパーティーCookie排除の見通しを受けて広告主やWebトラフィック分析事業者の間に懸念が広がりました。これらの事業者はほかのWebサイトに自社のコンテンツを埋め込んでいることが多く、それらWebサイトから送信されるCookieにたよって閲覧者情報を収集し、その情報によって広告キャンペーンを調整していました。

ここでサードパーティCookieが廃止されてしまうと、事業者が広告ターゲットや分析をするのに使える情報が減ってしまいます。そこでこの制約に対抗するべく「カノニカルネーム(Canonical NAME: CNAME)クローキング」と呼ばれる手法にうったえる事業者が出てきました。

CNAMEレコードとは、DNSのリソースレコード(Resource Record: RR)の一種で、代替ドメイン名をその真の名前にマッピングするものです。CNAMEレコードを使うと、複数のドメイン名からひとつのドメインにユーザーを誘導できるので便利です。

たとえば、あるDNSリゾルバが、あるドメインのIPアドレスを解決するクエリを送信し、それに対してCNAMEレコードが返されたとしましょう。その場合、そのリゾルバはふつう、さらにそのCNAMEのIPアドレスを解決するクエリを送信することになります。こうしてIPアドレスを得たリゾルバは、そのクエリを開始したクライアントにそのIPアドレスを返します。

ブラウザがWebサイトのドメイン名に対するDNSクエリを開始するさい、ブラウザからはこれらクエリの内容が見えないことが多いので、対象ドメインにCNAMEレコードがあることも知りえません。ブラウザに見えるのは元の名前、つまりその元の名前が最終的に解決するIPアドレスだけです。

図3はCNAMEクローキングのしくみの大まかな流れを示しています。Webサイト所有者のボブは、サードパーティが提供するコンテンツをwww[.]example[.]comのWebサイトに埋め込んでいます。このサードパーティコンテンツを提供しているのがad[.]example[.]comで、これはボブがWebサイトをホストするのに使っているドメインのサブドメインです。

さらにボブはad[.]example[.]comのCNAMEレコードを作成し、このレコードをトラッカーであるx[.]example[.]netの所有するサブドメインに向けておきます。ここでアリスがwww[.]example[.]comを閲覧し、アリスのブラウザがad[.]example[.]comにリクエストを送ると、そのリクエストはWebサイトをホスティングしているのと同じドメインへ送られているように見えます。

アリスのブラウザはad[.]example[.]comからのレスポンス内で送信されたCookieをファーストパーティーCookieとして扱うことになります。このように、CNAMEクローキングを行うことで、サードパーティによるCookie受信・設定が可能になり、こうした活動に対するブラウザの保護が回避されてしまいます。

CNAMEクローキングではサードパーティーCookieを許可した場合と同レベルのトラッキングは行えませんが、こうした手法はデータがどこに送信されたかという情報を隠すことになりますし、サードパーティに情報が漏れたり、新たな脆弱性が生じるなどの問題につながるおそれもあります。

防御

CNAMEクローキングはとくに目新しい戦略ではないので、この分野にはすでに複数の防御策が展開されています。たとえば、ブロックリストに依存するブラウザ拡張機能もそうした防御策の一形式です。ただし、ブロックリストによる防御策は拡張性の高いCNAMEクローキング検出方法とはいえないでしょう。サードパーティに向けられるファーストパーティサブドメイン数がほぼ無限に存在しうるからです。

UBlock Originはそれとはべつのアプローチをとる拡張機能で、DNSルックアップにもとづいてCNAMEクローキングを検出しています。ただしこの防御策はFirefoxでのみ有効です。DNS APIへのアクセスに制限があるからです。

Privacy Badgerは、それとはすこし異なるアプローチのブラウザプラグインで、トラッキングの振る舞いを探します。残念ながらこれはサードパーティCookieのブロックにしか機能しません。CNAMEクローキングはサードパーティーであることを隠蔽するので、このプラグインでは保護できません。

ブラウザベースの防御とは対照的に、DNSベースのアプローチでは、トラッキングに使われるサブドメインではなく、トラッカーのドメイン名にもとづいて通信をブロックすることが可能です。AdGuardやNextDNSなどほかのいくつかのグループもこの戦略で広告ブロッキングを行っています。

このDNSベースのアプローチは多くのブラウザベースのアプローチよりも拡張性が高いので、弊社ではこのアプローチを採用しています。パッシブDNSデータから得た知見を援用すると、既知のトラッカーに属するドメインに解決されるサブドメインを確認できます。この情報が弊社のCNAMEクローキング検出器のベースになっています。これらの結果から、どの広告会社ないしマーケティング会社がCNAMEクローキングでデータにアクセスしているかを知ることができます。弊社製品をお使いのお客様はクローキングされた完全修飾ドメイン名(FQDN)をブロックすることもできます。

実際のCNAMEクローキング検出事例

1ヶ月間運用した結果、私たちのCNAMEクローキング検出器は、38,000個以上のルートドメイン下の約43,000個のクローキングサブドメインを特定しました。これらのクローキングサブドメインは32の組織に属するドメインに向けられているCNAMEレコードをもち、主に広告やマーケティングを目的とする分析にフォーカスしているものでした(図4参照)。AdguardとEasyPrivacyが作成したリストはそれぞれ私たちが検出したサブドメインの10%未満のみをカバーしていました。

CNAMEクローキングを使うドメインの98%は、単一のサードパーティドメインのみに向けられたクローキングサブドメインをもっていました。数百個のサブドメインは2つのサードパーティドメインに依存しており、一握りのサブドメインが3〜4個のドメインに依存していました。

同様に、CNAMEクローキングを使うドメインの92%以上は、クローキングFQDNが1つだけでした。ただし数千個のドメインは2つ以上、数個のドメインが10個以上のクローキングFQDNを使っていました。このほか、サードパーティドメインに向けられたワイルドカードレコードを作成しているケースも確認されました。

上述の通り、CNAMEクローキングそれじたいが本質的に悪性の指標というわけではありません。しかしながら、プライバシー保護慣行が損なわれる、データの行き先があいまいになる、新たな脆弱性が生まれるかねないなど、数々の問題も生じます。私たちの検出器が特定したクローキングFQDNのなかから4,000個強のサンプルを調べてみると、クローキングがどのように使われているかについての知見が得られました。

サードパーティCookieのクローキング

予想される通り、多くのドメインが、ファーストパーティのコンテキストで生成されたCookieをサードパーティのサービスに送信することを目的に、CNAMEクローキングを使っていました。

たとえば、Adobe Experience CloudでCNAMEクローキングを使っているWebサイトの85%は、AMCV Cookieを含むクローキングFQDNにリクエストを送信しています。Adobeのドキュメントによると、AMCV Cookieは、Webサイト所有者が、Webサイト全体または所有者に属する複数のドメインにわたり、ユーザーを追跡できるようにします。

Adobeを使っているWebサイトの3分の1強がs_ecid Cookieを送信していました。このCookieは「ファーストパーティのステートで持続的にIDをトラッキングする」ことをサポートするもので、「AMCV Cookieが失効した場合に参照IDとして使用」されるものです。このCookieはCNAMEクローキングを使うドメインでのみ利用可能です。

このサービスを使う多くのドメインから送信されるその他のAdobe Experience Cloud Cookieには、AMCVS Cookie(セッションが初期化されたかどうかを判断するために使われるセッションCookie)、s_cc Cookie (Cookieが有効かどうかを判断するために使用されるCookie)、s_ppv Cookie (スクロール動作の測定に使用)などが含まれます。

Mappのwt-eu02[.]netに向けられたCNAMEを持つクローキングドメインへのリクエストには、負荷分散、Webサイトの新規訪問者か再訪問者かどうかの判断、トラッキングなどの機能をサポートするさまざまなCookieが含まれていました。私たちのサンプルでは、Mappに依存するサイトの76％がこれらのCookieの少なくとも1つを使っていました。

Salesforceを使うドメインの約14％が、クローキングサブドメインにvisitor_id Cookieとvisitor_id<accountid>-hash Cookieを送信していました。

Cookie同期による防御の回避

SalesforceのCookieはブラウザの導入した保護機能をトラッカーがやりすごすための方法の興味深い例といえます。Salesforceは、サードパーティCookieに関するSafariのIntelligent Tracking Prevention (ITP) 1.2による制限に特異的に対応するアプローチを開発しました。

このアプローチをとるSalesforceの顧客は、pi.pardot[.]comからvisit_id Cookieとvisit_idhash Cookieを設定するスクリプトを取得するコードをWebサイトに埋め込み、顧客のクローキングドメインからスクリプトを取得します(図5参照)。

取得されたスクリプトは何もしませんが(図6参照)、HTTPレスポンスヘッダは同一の2つのCookieを設定します(図7参照)。

この処理により同一のCookieが異なるドメインで作成されることになり(図8参照)ます。これがCookie同期の典型例です。

Cookieの流出

CNAMEクローキングの利用がまねく結果のひとつに、ほかのファーストパーティーCookieがクローキングFQDNに自動的に送信されてしまう可能性があげられます。意外にもクローキングドメインへのリクエストでもっともよく見られたCookieはクローキングを使うトラッカーが設定したものではなく、Google Analyticsに関連するものでした(表1参照)。

Cookie	クローキングドメインにCookieを送信しているWebサイト数	Cookieを受信するトラッカーのドメイン数
_ga	322	18
_gid	299	17
_gcl_au	191	14
GoogleAnalytics_gat	149	10
GoogleAnalytcs_ga	95	15
Adobe_AMCV	92	2
Adobe_AMCVS	91	2
S_CC	85	3
GoogleAnalytics_gtm	80	9
Act-On Beacon Cookie	75	2

表1 リクエスト内での観測数が多かったCookie。青地の行はGoogle AnalyticsのCookieを表す

クローキングFQDNに送られるリクエストでよく見られたほかのCookieとしては、Hotjar、Microsoft、Dynatraceに属するものがあげられます。これらのサービスはいずれも弊社のCNAMEクローキングをサポートしている関係者のリストには記載されていません。

結論

多くのWebサイトが、サードパーティーCookieにまつわるブラウザの制限を回避するためにCNAMEクローキングを使っていますし、サードパーティのデータ分析・広告・マーケティング企業のサービスを活用したい場合には便利なものです。

Cookieやトラッキング情報を扱う企業の提供するサービスは建設的な用途にも使えますが、CNAMEクローキングはセキュリティとプライバシーに関する深刻な懸念をもたらしています。まず第一に、誰がユーザーデータを受け取っているのかあいまいになり、自分の情報がどう扱われるのかをコントロールしづらくなります。第二に、Cookieの流出が原因で、ユーザー情報が不用意にサードパーティにわたってしまうおそれがあります。最後に、CNAMEクローキングの使用はこのほかのプライバシー保護を弱めたいという意図のあらわれとも受け取れます。実際私たちは、これがCookieの同期など、べつの不審な慣行とあわせて使われているようすを観測しています。

パロアルトネットワークスでは、次世代ファイアウォールのクラウド配信型セキュリティサービスを通じ、CNAMEクローキングを使用したドメインを検出して「adtracking (追跡型広告)」カテゴリにに割り当てています。これらのセキュリティサービスにはDNSセキュリティや高度なURLフィルタリングなどが含まれます。この検知器を通じ、弊社のお客様は、自組織のデータがどこに送信されているかを可視化し、コントロールすることが可能です。

追加リソース

• CNAME Cloaking-Based Tracking on the Web: Characterization, Detection and Protection
• The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion
• Towards Understanding First-Party Cookie Tracking in the Field