Facebookトークンハイジャックの脆弱性

Question

開発者用のFacebookマニュアル（https://developers.facebook.com/docs/facebook-login/security）によれば、Facebookアプリケーション用に特別に生成されたことを確認せずに、Facebook SDKクライアントからのaccess_tokenを使用する必要はありません。

ここにはどのような種類の脆弱性があるのでしょうか。 API呼び出しを使用してそれを使用してユーザーデータを取得できるのであれば、どのアプリがトークンを受け取ったのか気になる理由は何ですか？

トークンハイジャック

、この問題が発生したかを理解API呼び出しを行うために望んでいるネイティブiOSアプリを想像し、代わりにそれを直接行うことのためには、同じアプリやパスが所有するサーバーと通信しますそのサーバーは、iOS SDKを使用して生成されたトークンです。次に、サーバーはトークンを使用してAPI呼び出しを行います。

トークンを受信するためにサーバーが使用するエンドポイントが侵害され、完全に異なるアプリケーションのアクセストークンが他のユーザーに渡される可能性があります。これは明らかに安全ではないでしょうが、これを防ぐ方法があります - アクセストークンは、それらを使用しているアプリケーションからのものではなく、デバッグエンドポイントを使用してチェックする必要があります。脆弱性の

Answer 1

これらのタイプは、特定のアプリケーションです - 私は考えることができる1つのシナリオはこれです：

あなたはSSOメカニズムとしてFacebookの認証を使用していて、いくつかの個人情報を返すWebサービスとアプリケーションを作成している想像してみて認証されたユーザーに送信します。このウェブサービスは/secretdocuments/downloadと呼ばれ、アクセストークンをパラメータとして受け取ります。

Webサービスは、それが受信したアクセストークンは、（に私/、その後、DB検索呼び出しを介して）データベース内にそれが持っているユーザーのために、その後、悪意のある人は可能性があることを確認した場合：

1. 他の "餌"アプリを作成します。
2. そのアプリへのリンクをユーザーの1人に送信し、ユーザーにインストールを促す。
3. そのユーザーはベイトアプリで認証され、アクセストークンは です。ベイトアプリは、このアクセストークンを悪意のあるユーザーに送信します。
4. 悪意のあるユーザーがそのアクセストークンを受け取り、/secretdocuments/download Webサービスを呼び出します。
5. ウェブサービスでは、データベースにあるユーザ のアクセストークンのみがチェックされ、悪意のあるユーザーには という個人情報が返されます。

このシナリオでは、Webサービスは、提供されたアクセストークンがアプリケーションによって生成されたことを確認する必要があります。