プライバシー脅威「シルエット」への対策

利用者の皆さんのセキュリティとデータを守ることはとても大切なことです。一つの側面として、他のサイトを訪問する際にTwitterの個人情報を守ることが挙げられます。

メール、ツイート、他のサイトの広告、またはハッキングされた馴染みのあるサイトからのリンクを介して、誤って悪質なウェブサイトへアクセスする可能性があります。そのウェブサイトは利用者にわからないように秘密裏で通信を行うため、そのサイトが悪質な性質を持っているかどうか明らかではないかもしれません。

もし、ウェブサイトが皆さんのTwitterの個人情報を特定できた場合、その情報を追跡や他の紐づいているアカウントにも使用する場合があります。これにより、利用者のオンラインの情報を特定させることができるかもしれません。地域によっては、利用者にに大きな危険を及ぼす可能性があります。

私たちは、Twitterなどのオンラインプラットフォーム上でログイン状態を保持している利用者の個人情報が見つかる新たな脅威を見つけました。そこで、このリスクを緩和するためにサイトを変更し、ブラウザのベンダと連携を図り、対策導入を促すことでセキュリティの改善に努めて来ました。

この問題は、早稲田大学とNTTの研究者グループのプログラムを通じて、2017年12月に報告されました。2018年4月に開催された「IEEE ユーロS&P」で発表された論文の草案が事前に提供されたため、公開前に問題に十分対応することができました。

当社のセキュリティチームは問題を精査し、関連するさまざまなチームとも共有しました。問題の重要性を認識し、問題に対処するためのチームを結成するとともに、脆弱性のある他のサイトやブラウザ会社ともコンタクトを取り、すばやく対処にあたりました。

攻撃の概要

この攻撃は、Webページの読み込みにかかる時間のばらつきを利用しています。ウェブサイトは、標準のブラウザAPIでJavaScriptを使用して、バックグラウンドでTwitterからページをリクエストすることができます。リクエストはログイン認証情報（クッキーに保存されている）を使用して行われるため、Twitterにログインしている場合は、ログインしている利用者としてリクエストが送信されます。

当社のサイトでは、POSTリクエストに対する一般的なCSRF対策を実装しており、利用者名義によるアクションを制限しています（ツイートの送信など）。また、ブラウザは、セキュリティ上の理由から、オリジン間リクエストにも多くの制限を課しています（例：オリジンは別のレスポンスの内容を確認できません）ただし、ページのリクエストの際には、リクエストのロードに要した時間が取得されます。

認証されたTwitterプロフィールページの読み込み時間を示すコードです。

このタイミングデータは、特定の利用者について応答時間を結果に表示できる場合にのみ情報を開示します。一般に、ページの読み込み時間は見ているツイートに依存し、予測するのは困難です。

しかし、ブロックされている場合は、プロフィールページを読み込むことができなくなり、空のページだけが表示されます。そのページは、ツイートが表示されるプロフィールよりはるかに高速に読み込まれます。

テストでは、プロフィールページの読み込み時間が約500msから約200msまで低下しています。このように、利用者の行動は別の利用者のページ読み込み時間に影響することがあります。

利用者のプロフィールを読み込むに200ms 以下であったのに対して、@jack's のプロフィールは 440ms まで読み込むのにかかりました。

研究者はこの事実をマトリックス手法と組み合わせました。特定のブロック関係にあるアカウントを大量に取得し、非常に少ないタイミングリクエストで大規模なセット内の利用者を見つけることができました。

ユーザアカウントを一意に特定するためのブロック/非ブロック設定例（NTT, 2018）

たとえば、特定のブロック関係にあるTwitterアカウントを20個だけ設定し、約100万のセットからアカウントを識別することができます。この技術は、「シルエット」と命名されました。もちろん、リンク先のサイトがTwitter経由のアクセスであることを取得するようなリンクをダイレクトメッセージで送信することも比較的簡単に行なえます。ただし、これは特定のターゲット利用者に対してのみ機能します（スピアフィッシング）。この新しい手法は、Twitter自体から移動しないので、利用者はプライバシーを警戒せず、多くの利用者に対して有効となっています。

私たちが取った行動

研究者の論文により、問題の緩和のためのいくつかのアイデアが提示されました。

理想的な解決策

理想的な解決策は、ログインSameSite属性が付与されたクッキーを使用することでした。他のサイトから私たちのサイトへのリクエストがログイン要求とみなされなくなります。要求がログイン要求でない場合、IDは検出できません。ただし、この機能は期限切れのドラフト仕様であり、Chromeでのみ実装されていました。 Chromeは最大シェアのブラウザクライアントですが、他のブラウザもカバーする必要があるため、他の選択肢を検討しました。

最善の緩和策
最初は、レスポンス時間の変動を減らす方法を検討しました。ブロックされた場合と、ブロックされていない場合の両方で同じ（フルサイズの）プロフィールページを返す必要がありますが、これは不十分だという判断になりました。すべてのページを考慮する必要があり、将来の変更に脆弱で、利用者の読み込み時間が長くなるという理由です。

次に、ページシェルを読み込み、AJAXを使用してすべてのコンテンツをJavaScriptで読み込むことで、レスポンス時間の違いを減らすことを検討しました。ウェブサイトのページナビゲーションについてはすでにこのように機能しています。しかし、シェルはヘッダー情報を提供する必要があり、それらの照会はレスポンス時間に大きく影響を及ぼしているため、サーバーの処理の相違がページシェルにとって重要であることがわかりました。

POSTリクエストに対するCSRFの保護メカニズムですが、リクエストの発信元とリファラーヘッダがTwitterからのものかどうかをチェックしています。POSTに対して有効ですので、GET要求に対してどのように実装できるかということについても考えていました。

これは脆弱性に効果的でしたが、ウェブサイトの読み込み負荷が増加しました。 Googleの検索結果からTwitterを読み込んだり、ブラウザにURLを入力したりしてアクセスする場合には障害となります。このケースに対処するために、私たちはtwitter.com上に空のページを作成しました。再読込するだけのページで、再読込時に、リファラがtwitter.comに設定され、正しく更新されます。 Twitter以外のサイトでその再読込を追跡する方法はありません。空ページはとても小さいため、負荷時間にはあまり影響しません。

この際に考慮したいくつかの事項について申し上げます。

私たちは、JavaScriptを必要とせずに動作する従来のバージョンのTwitter（内部的にはM2として知られています）をサポートしています。再読込にJavaScriptが不要であることを確認する必要がありました。

• セキュリティのためにCSPを使用しています。私たちは再読込する空ページがサービスごとに異なる独自のCSPルールに従っていることを確認する必要がありました。
• 元のHTTPリファラを通過して、検索エンジンのリファラを正確に反映しているかどうかを確認する必要がありました。
• ページがブラウザによってキャッシュされていないことを確認する必要がありました。空ページがずっと再読込されてしまうからです。 クッキーを使用してこれらのループを検出し、短いメッセージと用意し、ページが複数回読み込まれている場合は手動によるリンクを表示しました。
• 一部のプライバシー関連のブラウザ拡張機能により、リファラがページ間で正しく反映されていないことが判明しました。これらの利用者には、クリックする手動リンクを常に表示します。残念ながら、このケースについてはあまり対策が講じられませんでした。
• APIクライアントがHTMLページのリダイレクトを予期していない場合、Twitter APIルートを確認して問題の影響を受けていないか、この解決策の影響を受けていないかどうかを確認しました。

上の緩和策を実装するにあたり、SameSite属性が付与されたクッキーに関する主要なブラウザ供給元とコンタクトをとり、問題を共有したところ、熱心に協力してくれました。主要なブラウザはすべてSameSite属性が付与されたクッキーサポートを実装しました。これには、Chrome、Firefox、Edge、Internet Explorer 11、Safariが含まれます。

SameSite属性に遭遇したときにブラウザまたはネットワークがクッキーを破損した場合に、既存のログインクッキーに属性を追加するのではなく、ログアウトのリスクを軽減するためにSameSite用の2つの新しいクッキーを追加しました。クッキーにSameSite属性を追加するのは比較的簡単です。 set-クッキー HTTPヘッダーに「SameSite = lax」を追加します。しかし、Twitterのサーバーは、NettyのラッパーであるFinagleに依存しており、Nettyはクッキーオブジェクトの拡張をサポートしていませんでした。驚くべきことに、1年前に開発者の1人から機能リクエストを受けていたのです！しかし、SameSiteは承認された仕様ではなかったため、Nettyチームによる実装のコミットメントはありませんでした。最終的には、Finagleの実装にオーバーライドを追加し、新しいクッキー属性をサポートできました。

終わりに

SameSite属性が付与されたクッキーは、参照元を確認すると、利用者がプライバシー脅威「シルエット」から守られている確信が持てます。

このような類の攻撃はまったく新しいものではありません、以前に起きたセキュリティのリスクはそのときに対応しています。ご報告いただけるシステムを持ち、応対するセキュリティチームを設けたりしています。プライバシー脅威「シルエット」から影響を受けているのはTwitterだけではありません、他のウェブサイトがSameSiteのクッキー属性を将来的に使用していただけることが楽しみです。この他のサイトやブラウザ会社ともコンタクトを取り、すばやく問題に取り組んでいただいたセキュリティチームの皆さん、渡邉卓弥さんとNTTさんによる論文、それから継続的なご協力を賜りましてありがとうございました！

-----------------------------------

引用

[1]  Watanabe, T. (2018) "User Blocking Considered Harmful? An Attacker-controllable Side Channel to Identify Social Accounts", https://arxiv.org/abs/1805.05085 14 May 2018

[2] "NTT Discovers Novel Privacy Threat “Silhouette” in Social Web Services" http://www.ntt.co.jp/news2018/1807e/180718a.html ,18 July 2018