• 検索結果がありません。

れます 図1 ユーザアカウントを一意に特定するためのブロック/非ブロック設定例 特定実行時 すなわちアカウント名を特定するためのスクリプトが設置されたウェブサ イトに訪問したユーザに対しては それぞれの特定補助アカウントのページへの通信を強 制的に送信させます このときの通信は Same-Origi

N/A
N/A
Protected

Academic year: 2021

シェア "れます 図1 ユーザアカウントを一意に特定するためのブロック/非ブロック設定例 特定実行時 すなわちアカウント名を特定するためのスクリプトが設置されたウェブサ イトに訪問したユーザに対しては それぞれの特定補助アカウントのページへの通信を強 制的に送信させます このときの通信は Same-Origi"

Copied!
5
0
0

読み込み中.... (全文を見る)

全文

(1)

1 ソーシャルウェブサービスにおける新たなプライバシー脅威 「Silhouette」について NTT は、ソーシャルウェブサービスに対する新たなプライバシー脅威「Silhouette (シル エット)」を発見しました。本稿では、この脅威の概要および原理と対策手法について解説 します。 1. 概要 本脅威は、ソーシャルウェブサービス(※1、以下「SWS」)のユーザが悪意のある第三者 のウェブサイトに訪問した際に、当該ユーザが所有する SWS のアカウント名が第三者のウ ェブサイトから特定されうるというものです。SWS のアカウントにはユーザの実名や顔写 真、位置情報、日々の投稿といった情報が含まれているため、意図しない第三者に特定され ることで重大なプライバシー情報が露見してしまうこととなり、さらにソーシャルエンジ ニアリングや脅迫といった攻撃に発展する可能性があります。例えば、検索エンジンの結果 や、一般的なウェブサイトに含まれる広告、メールに含まれるリンクなどを経由して、本来 SWS と全く関係のない悪意のあるウェブサイトへアクセスしてしまった際に、その悪意の あるサイトはユーザが利用しているであろう SWS への通信をユーザにはわからないよう秘 密裏に行い、ユーザの SWS のアカウント名を特定してしまいます。 特定が成立してしまう条件は、パソコンやモバイル端末のウェブブラウザにおいて、本脅 威に対して脆弱な SWS へのログイン状態を保持しているユーザが、悪意ある第三者の設置 したウェブサイトに訪問するというものです。一般的な SWS では、ログアウトを明示的に 実施する等の操作によってブラウザの Cookie(※2)が削除されるまで、自動的にログイン 状態を保持する仕組みになっています。したがって、過去に一度でも脅威の対象となる SWS を利用した経験のあるユーザは、特定の対象となってしまうおそれがあります。 2. 原理 本脅威が成立する原理について解説します。本脅威を成立させるために、SWS に広く採 用されている「ユーザブロック」という機能が悪用されます。ユーザブロックは本来、正当 なユーザが悪質なユーザに対して自身のページ閲覧可否をコントロールし、ハラスメント やスパム行為から身を守るための機能です。ここで注意しなければならないのは、悪質なユ ーザもまた正当なユーザに対してページの閲覧可否をコントロールできてしまうという特 徴です。 事前準備として、悪意ある第三者は SWS 内に自らアカウントを作成します(以下、「特定 補助アカウント」)。特定補助アカウントを複数用意し、同一サービス上のユーザらを計画的 にブロックすることで、さまざまな閲覧可/閲覧不可の組み合わせパターンを構築すること ができます。このパターンは、ユーザアカウントを一意に識別するための情報として利用さ

(2)

2 れます。 図1:ユーザアカウントを一意に特定するためのブロック/非ブロック設定例 特定実行時、すなわちアカウント名を特定するためのスクリプトが設置されたウェブサ イトに訪問したユーザに対しては、それぞれの特定補助アカウントのページへの通信を強 制的に送信させます。このときの通信は Same-Origin Policy(※3)によって保護されてい るため、第三者は応答内容を直接的に取得することはできません。 図2:Same-Origin Policy による応答内容の保護

(3)

3 しかしながら、閲覧可能時と閲覧不可能時では通信の応答時間には統計的な差異が発生し ます。悪意ある第三者はこの差異を用いて、訪問ユーザがそれぞれの特定補助アカウントか らブロックされているかどうかを推定することができます。最後に、推定結果をあらかじめ 構築したパターンと照合することで、当該ユーザの SWS におけるアカウント名を特定しま す。 より詳細な説明や実験結果については、我々が発表した論文(※4)に記載されています ので、あわせてご参照ください。 3. 対策手法 本脅威に対して、SWS 事業者およびユーザが実施可能な対策手法をそれぞれ紹介します。 本脅威は、クロスサイトリクエストフォージェリ(※5、以下 CSRF)と、タイミング情報を 使ったサイドチャネル攻撃(※6)を組み合わせた攻撃であるため、これらのいずれかを防 御することで対策が実現します。CSRF は、ウェブサービスのプログラム変更を伴う汎用的 な対策が知られています。以下では、CSRF の対策に主眼を置いた対策手法を紹介します。 なお、サイドチャネル攻撃の対策には、タイミング情報の特性を考慮した専門的な見地が必 要とされます。こちらの詳細については論文をご参照ください。 3.1 前提条件 本脅威の対象となり得るサービスは、アカウント登録機能を有し、なおかつユーザブロッ ク機能などによって、あるユーザが他のユーザに対して、ユーザのコンテンツページ(たと えば、プロフィールなど)の閲覧権限を強制的に変更できる機能を持っている SWS となり ます。これらに該当しないサービスは本脅威の対象ではありません。 3.2 SWS による対策 SWS は、サービスへの影響を勘案した上で、適切な対策手法を選択することが望まし いです。以下に、SWS が実施できる対策手法を 2 つ紹介します。 ■リクエスト検証 CSRF では、JavaScript によってユーザおよびサービスが意図しない HTTP リクエスト が発生します。このとき、サーバー側でリファラやリクエストパラメータを検証することで、 正当なリクエストであるかどうかを判別し、不正なリクエストを棄却するという対策手法 が知られています。具体的な手順については、IPA「安全なウェブサイトの作り方」(※7) の該当項目をご参照ください。 リクエスト検証は、ウェブサービスへの投稿等を行う POST メソッドを受け付けるペー ジで採用されることが多いですが、ユーザプロフィールのような GET メソッドを受け付け るページにおいても採用することができます。ただしこの場合、検索エンジンやブログ記事 から直接リンクされた際に検証に失敗し、不正なリクエストとして棄却してしまう可能性 があります。そこで、検証に失敗した際には、サーバーが実際のコンテンツを含まない中間 ページを返した後、その中間ページの JavaScript によって実際のコンテンツを取得すると

(4)

4

いう手順を加えることで、通信ホップ数は増加するものの、直接リンクからのアクセスを阻 害することなく対策できます。

■SameSite 属性

SameSite 属性(※8)が付与された Cookie は、JavaScript 等による異なるサイトへのリ クエスト時に送信されなくなります。したがって、ログイン状態を管理する Cookie にこの 属性を指定することで、本脅威を含む CSRF を広く対策することが可能となります。ただ し、SameSite 属性を利用するためには、ユーザの用いるウェブブラウザが SameSite に対応 している上で、SWS が HTTP ヘッダで SameSite の利用を宣言する必要があります。 SameSite 属性は、現時点ですべてのブラウザで利用できるわけではない点に留意してくだ さい。SameSite 実装に向けた我々とブラウザベンダの取り組みについては、ニュースリリ ース(※9)もあわせてご参照ください。 3.3 ユーザによる対策 SWS が本脅威に対して脆弱であり対策を講じていない場合に、ユーザが実施できる対策 手法を 2 つ紹介します。 ■プライベートブラウジングの利用 現在の主要なウェブブラウザでは、プライベートブラウジング機能が備わっています。こ れはシークレットモード、プライベートウィンドウ、InPrivate などとも呼ばれており、こ の機能を有効にしている間は、今までの Cookie 情報を引き継ぐことなく、また終了時には 新たに保持した Cookie を破棄するようになります。プライベートブラウジングを有効にし てから第三者のウェブサイトに訪問することで、本脅威によるアカウント名の特定を防ぐ ことができます。 ■SWS からのログアウト 本脅威では、ユーザが SWS にログインしているという状態に基づいて、アカウント名の 特定が実現します。SWS にログインしてサービスを利用した際は、終了時に毎回ログアウ トを行うなどの手段によってログイン状態を破棄することで、本脅威によるアカウント名 の特定を防ぐことができます。 4. 対外発表と対策への取り組み 本研究の成果については、セキュリティ・プライバシー分野で著名な国際会議 IEEE Euro S&P'18(※10)に採択され、2018 年 4 月に登壇発表を行いました。また、国内最大級の研 究会であるコンピュータセキュリティシンポジウム 2017(※11)にて最優秀論文賞を受賞 するなど、学術的に高い評価を得ています。 さらに、国際会議での発表に先駆けて、我々は本脅威の影響を受ける世界的サービスおよ びブラウザベンダと連携を図り、対策導入を促すことでセキュリティ機構の改善に努めて きました。この取り組みについては、ニュースリリースもあわせてご参照ください。

(5)

5 用語・参考文献 ※1 ソーシャルウェブサービス(SWS)…ユーザが投稿したコンテンツや、ユーザ同士のコ ミュニケーションに基づいて形成されるウェブサービス。ソーシャルネットワークサービ スや動画共有サイトのほか、ウェブフォーラム、マイクロブログ、オンラインゲーム、オー クションサイト等が該当する。 ※2 Cookie…ユーザ設定、ログイン、セッション等を管理するために、ウェブサービスが訪 問ユーザのウェブブラウザに情報を保存できる機能、あるいは保存された情報を指す。 ※3 Same-Origin Policy…あるオリジン(ホスト名、ポート番号、スキーム)から異なるオ リジンに対して通信が発生する際に、意図しない干渉や取得から情報を保護するためブラ ウザに搭載されている制約。 ※4 論文… https://arxiv.org/pdf/1805.05085 ※5 クロスサイトリクエストフォージェリ(CSRF)…ユーザが意図しない異なるサイトへの リクエストを強制的に送信させることで、データの奪取や悪性コードの実行、権限の取得な どを行う攻撃。 ※6 サイドチャネル攻撃…応答時間や電力消費量といった実空間の情報を活用し、センシ ティブなプライバシーの奪取や暗号解読を行う攻撃。 ※7「安全なウェブサイトの作り方」改訂第 7 版, pp.31-33 … https://www.ipa.go.jp/security/vuln/websecurity.html

※8 SameSite – OWASP… https://www.owasp.org/index.php/SameSite ※9 ニュースリリース… http://www.ntt.co.jp/news2018/1807/180718a.html

※10 T. Watanabe, E. Shioji, M. Akiyama, K. Sasaoka, T. Yagi, and T. Mori, “User Blocking Considered Harmful? An Attacker-controllable Side Channel to Identify Social Accounts,” Proceedings of the 3rd IEEE European Symposium on Security and Privacy (Euro S&P 2018), April 2018

※11 渡邉卓弥,塩治榮太朗,秋山満昭,笹岡京斗,八木毅,森達哉, “ユーザブロック機 能の光と陰: ソーシャルアカウントを特定するサイドチャネルの構成” コンピュータセキ ュリティシンポジウム 2017 論文集,2017 年 10 月

参照

関連したドキュメント

タップします。 6通知設定が「ON」になっ ているのを確認して「た めしに実行する」ボタン をタップします。.

パスワード 設定変更時にパスワードを要求するよう設定する 設定なし 電波時計 電波受信ユニットを取り外したときの動作を設定する 通常

新設される危険物の規制に関する規則第 39 条の 3 の 2 には「ガソリンを販売するために容器に詰め 替えること」が規定されています。しかし、令和元年

(a) ケースは、特定の物品を収納するために特に製作しも

・カメラには、日付 / 時刻などの設定を保持するためのリチ ウム充電池が内蔵されています。カメラにバッテリーを入

3000㎡以上(現に有害物 質特定施設が設置されてい る工場等の敷地にあっては 900㎡以上)の土地の形質 の変更をしようとする時..

・電源投入直後の MPIO は出力状態に設定されているため全ての S/PDIF 信号を入力する前に MPSEL レジスタで MPIO を入力状態に設定する必要がある。MPSEL

定的に定まり具体化されたのは︑