Video Screencast Help
Security Response

Facebook アプリケーションが意図せずアクセス情報をサードパーティに漏洩 - 更新

Created: 11 May 2011 10:14:51 GMT • Translations available: English
Nishant Doshi's picture
0 0 Votes
Login to vote

サードパーティ(主に広告主)が、意図せずにプロフィール、写真、チャットなどの Facebook ユーザーのアカウントにアクセスし、メッセージを投稿したり、ユーザーの個人情報を取得したりできるようになっていました。幸いなことに、これらのサードパーティは、この情報にアクセスできることを認識していなかったようです。この問題は Facebook に報告され、問題を排除するための是正措置がとられました。

Facebook アプリケーションは、Facebook プラットフォームに統合された Web アプリケーションです。Facebook によれば、毎日 2,000 万本の Facebook アプリケーションがインストールされています。

シマンテックでは、特定のケースで Facebook IFRAME アプリケーションから広告主や分析プラットフォームなどのサードパーティに、アクセストークンが意図せず漏洩することに気付きました。このような漏洩が可能になるアプリケーションは 2011 年 4 月時点で、100,000 本近くに上ると推測されます。長年にわたって、数十万本のアプリケーションによって、数百万件のアクセストークンが意図せずサードパーティに漏洩していたであろうと推測されます。

アクセストークンは、ユーザーが Facebook アプリケーションに渡す「合鍵」に当たります。アプリケーションでは、このトークン(鍵)を使用して、ユーザーに代わって特定の操作を実行したり、ユーザーのプロフィールにアクセスしたりします。各トークン(合鍵)には、ウォールの読み取り、友達のプロフィールへのアクセス、ウォールへの投稿など、選択した一定の許可が関連付けられます。

このような許可の一部を図 1 に示します。

図 1

アプリケーションをインストールする場合、ユーザーは、これらの操作を実行するための許可をアプリケーションに与えるよう要求されます。これらの許可を与えると、アプリケーションは、図 2 に示すようなアクセストークンを取得します。

図 2

この結果、アプリケーションでは、このアクセストークンを使用して、ユーザーの情報にアクセスしたり、ユーザーに代わって操作を実行したりできるようになります。

デフォルトでは、大部分のアクセストークンが短時間で期限切れになります。一方、アプリケーションでは、オフラインアクセストークンというトークンを要求できます。このトークンは、ユーザーがログインしていない場合でも使用でき、ユーザーがパスワードを変更するまで有効です。

アクセストークン漏洩のメカニズム

Facebook が現在デフォルトで使用している認証メカニズムは OAUTH2.0 です。一方、以前の認証スキームがまだサポートされており、数十万本のアプリケーションで使用されています。ユーザーが apps.Facebook.com/<アプリケーション名> にアクセスすると、まず、国、ロケール、年齢区分などのユーザーを特定できない一定限度の情報がアプリケーションに送信されます。アプリケーションでは、この情報を使用してページを個人設定できます。

アプリケーションでは、続いて、次のような許可ダイアログページにユーザーをリダイレクトする必要があります。

図 3

アプリケーションではクライアントサイドリダイレクトを使用して、一般的なアプリケーション許可ダイアログボックスにユーザーをリダイレクトします。このような間接的な漏洩は、アプリケーションで従来の Facebook API を使用しており、リダイレクトコード内で図 4 に示す非推奨のパラメータの「return_session=1」と「session_version=3」を使用している場合に発生します。

図 4

これらのパラメータが使用されている場合、Facebook では、アクセストークンを URL に含む HTTP 要求をアプリケーションホストに送信することによって、アクセストークンを返します。

この結果、その Facebook アプリケーションでは、アクセストークンをサードパーティに意図せず漏洩できることになります。この漏洩は、意図的な場合もありますが、あいにくほとんどが意図しないものです。具体的には、アクセストークンが含まれるこの URL を HTTP 要求の referrer フィールドに加えて、サードパーティの広告主に渡されます。

たとえば、このアプリケーションの先頭ページで広告主の iframe タグを使用して外部 URL からのリソースを要求していた場合、referrer フィールドによってアクセストークンが漏洩します。この内容を図 5 に示します。

図 5

まとめ

言うまでもなく、このアクセストークンの漏洩は至るところに影響します。この問題は Facebook に伝えられており、漏洩が確認されています。Facebook からは、これらのトークンを漏洩させないための変更を完了したとの報告がありました。

2007 年の Facebook アプリケーションのリリース以降に漏洩したアクセストークンの数を推測する手っ取り早い方法はありません。シマンテックでは、このトークンの多くがサードパーティサーバーのログファイルでまだ使用可能であることや、広告主によってまだ盛んに利用されていることを懸念しています。心配な場合は、Facebook のパスワードを変更すれば、漏洩したアクセストークンを無効化できます。パスワードの変更によりこれらのトークンは無効になります。これは、Facebook プロフィールでロックを変更することに相当します。

シマンテックの Nishant Doshi および Candid Wueest がこの問題の発見に貢献しました。

先日、Facebook は、Developer RoadMap の更新情報を公表しました。この更新情報について詳しくは、https://developers.facebook.com/blog/post/497 を参照してください。

2011 年 5 月 17 日更新: シマンテックは、Facebook プラットフォームに統合された一部のアプリケーションが、Facebook ユーザーによって共有された情報にアクセスすることをサードパーティに許してしまう場合があるというリスクに関して、過去数週間 Facebook と連絡を取り合ってきました。この問題の報告を受けた Facebook は、リスクを排除するための是正措置をすぐに講じたことを繰り返しお伝えしておきたいと思います。シマンテックの確認しているかぎり、この問題の影響を受けた Facebook ユーザーはいませんでした。また、Facebook は開発者に対してもこのような記事を投稿し、安全なコーディング標準の指導に努めています。

 

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。