Client Hints を使用した不一致の検出方法

デバイスがサーバーに HTTP リクエストを送信する場合、従来は各リクエストと一緒に User-Agent (UA) ヘッダーが送られていました。このヘッダーにはデバイスやその環境に関する情報が含まれているので、サーバーで分析し、レスポンスをカスタマイズすることが可能になります。実際には、User-Agent ヘッダーによってエントロピーが受動的に公開され、それを他の属性と併用することで特定のユーザーを識別できます。Google Chrome チームは、Client Hints (CH) と呼ばれる新たな標準を導入することで、これまでと同じ情報へのアクセスをよりプライバシー保護に重きを置いた方法で実現することを目指しています。 

サイトが収集できる Client Hints には、User-Agent Client Hints、Device Client Hints、Network Client Hints の3種類があります。このブログ記事では、User-Agent Client Hints (UA-CH) の仕様を中心に取り上げます。具体的には、User-Agent Client Hints の仕組みやプライバシーにかかわる機能と懸念、この新たな標準の限定的な採用や不完全な部分を利用して動作の不一致を特定し、攻撃者や望ましくないトラフィックを明らかにする方法を、実際の事例を見ながら紹介します。 

Client Hints の仕組み 

Client Hints には低エントロピーと高エントロピーの2種類があります。低エントロピーヒントは、多くのユーザーが共有する基本的な情報を含み、デフォルトですべてのリクエストで提供されます。高エントロピーヒントはより詳しい情報を提供し、その情報価値が高いことから、サーバーはそれらを明示的に要求する必要があります。

サーバーは Accept-CH レスポンスヘッダーに Client Hints を列挙することで、受信したい Client Hints を指定します。クライアントが Accept-CH レスポンスヘッダーを受け取ると、列挙した Client Hints を含むヘッダーがそれ以降のリクエストに追加されます。  

この仕組みを以下の例で見ていきましょう。 

ステップ1 : サーバーは Accept-CH レスポンスヘッダーに特定の高エントロピーヒントを列挙して、それらを要求します。

Accept-CH: Sec-Ch-Ua-Platform-Version, Sec-Ch-Ua-Bitness

ステップ2 : ブラウザは低エントロピーヒントと要求された高エントロピーヒントの両方を、後続のリクエストで返します。

Sec-CH-UA: "Google Chrome";v="105", "Not)A;Brand";v="8", "Chromium";v="105"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "macOS"
Sec-CH-UA-Platform-Version: "12.6.0"
Sec-CH-UA-Bitness: "64"

Client Hints は、User-Agent Client Hints API を介して JavaScript でも利用可能です。Client Hints をサポートするブラウザを起動し、こちらのテストサイトを使用することで、実際に試すことができます。 

プライバシー保護機能

通常、低エントロピーと高エントロピーの両タイプは、UA 文字列にまとめられ、デフォルトでファーストパーティーとサードパーティーのリクエストでサーバーに送られます。

これは、Mac OS デバイス上で動作する Chrome からのリクエストにおける UA 文字列の例です。

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/106.0.5249.62 Safari/537.36

以下の表では、UA 文字列に含まれる値を、各 Client Hints エントロピーのカテゴリ別に分類しています。

UA-CH 仕様には、より限定されたユーザー情報を優先するために UA 文字列の粒度を下げることで、高エントロピーヒントへのアクセスを保護する目的があります。さらにこの仕様では、Client Hints が安全な TLS 接続のみを介して配信されるように規定されています。また、Client Hints は同じオリジンリクエストにのみ送信されます。クロスオリジンリクエスト (例 : https://thirdparty.example/tracking.js) を許可するには、実装者が Permissions-Policy ヘッダーを介して明示的に許可を与える必要があります。 

一方、こうしたプライバシー面でのメリットは悪用の恐れもあります。Client Hints によって、識別値にアクセスすることが可能になるためです。例えば、ファーストパーティーは、バックグラウンドでサードパーティーに対してすべての値を送るようブラウザに指示できます。そうでない場合、スクリプトを挿入する必要が生まれ、結果として大半のユーザーが気づかないままより多くの当事者にさまざまな識別情報が共有されてしまう可能性があります。

さらに、プロキシや CDN、ファイアウォールなど、TLS 終端を実行するシステムもこうした情報にアクセス可能になります。この標準の採用を検討する前に、お客様のインフラを支えるコンポーネントにかかわるプライバシーポリシーを注意深く読み、理解することが重要です。

検出可能な不一致 

検出の専門家たちは長年、危険な動作の特定や不正行為の減少、セキュリティ上の問題の発見に繋がる不自然な点を見つけるのに UA 文字列を利用してきました。一方でこれは広く知られた手法であることから、攻撃者は正当な UA 文字列を使用して自分たちの行動の偽装を試みることがあります。

Client Hints を活用する利点のひとつとして、現在もそれが実験の段階であることが挙げられます。これは、Client Hints をサポートするブラウザが、当面の間は各リクエストと一緒に従来の UA 文字列と Client Hints の両方を送信することを意味しています。実験段階であるため、Client Hints は比較的あまり知られておらず、見落とされやすい面があります。そのため、CH 情報を UA 文字列に組み合わせて不一致を特定し、攻撃者と望ましくないトラフィックを発見するのに活用できます。 

例えば、非常に人気の高いペネトレーションテストツールである Burp Suite には独自の Chromium Web ブラウザが組み込まれています。現在、デフォルトの UA 文字列によって以下のように識別されます。

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/106.0.5249.62 Safari/537.36

これにより、ユーザーが Windows 上で実行していない場合、以下のリクエストが示すように不一致を検出できます。

GET /headers HTTP/2
Host: user-agent-client-hints.glitch.me
Sec-Ch-Ua: "Not;A=Brand";v="99", "Chromium";v="106"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "macOS"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/106.0.5249.62 Safari/537.36

この情報を活用して、1時間にわたる攻撃データを調査しました。その結果、シグナルを受けたすべてのリクエストの内、約8%が Burp に組み込まれたブラウザのデフォルトの UA 文字列に類似した UA 文字列を伴っていたことがわかりました。さらに分析を進めると、既知のオペレーティングシステムを表す Client Hints に不一致がみられるリクエストの90%以上が、プラットフォームが Linux であるという情報を公開していることが判明しました。

この攻撃トラフィックは、Kali Linux (オープンソースの Debian ベースのペネトレーションテスト向け Linux ディストリビューション) 上で動作する Burp から発生していることが予測できます。この情報を JA3 などの指標と一緒に活用することで、より高いレベルの信頼性を生み出すことが可能になります。 

さらに詳しく調査したところ、SQL インジェクションやコマンドインジェクション、クロスサイトスクリプティング (XSS) などの攻撃ペイロードが、Client Hints ヘッダーに注入されていることも判明しました。Client Hints は HTTP ヘッダーフィールドなので、UA 文字列と同様に、ユーザーによるこれらのフィールドの操作を妨げる術はないことを認識する必要があります。例えば CH ヘッダーは、ユーザーによるコントロールが可能なため、さまざまな問題を引き起こす可能性があります。サーバーが CH ヘッダーを暗黙的に信頼し、適切な検証やエスケープを怠ると、攻撃者がこのベクトルを利用してさまざまな欠陥を悪用するリスクが生まれます。

まとめ

Client Hints は現在も実験段階にある新たな標準です。しかし、現時点では限定的な採用にとどまり、さらに不完全な部分もあることから、興味深い研究分野でもあります。このプライバシー保護機能はさまざまなメリットをもたらす一方で、それらのメリットが悪用される懸念もあります。また、この標準の採用が広がりつつあるものの、低エントロピーと高エントロピーのデバイス情報を送信するという従来的な方法もいまだに使用されています。そうしたデータを、Client Hints の技術と組み合わせることで、より多くのことを明らかにすることが可能になります。