0

私は自分のサイトのFacebookログインを検討しています。Facebookベースの認証に基づいて、ユーザーはサイトにログインします。また、Facebookのログイン状況に関係なく、サイトからログアウトするまで使用し続けます。他のほとんどのサイトと同じように。

FBのクライアント側のログイン方法を調べていると、fbsr_{app_id}Cookieから受信したsigned_requestデータに基づいていることがわかりました。そしてFBは、認証要求を検証するために、発行から10分以内に有効な短期間のaccess_tokenと交換されることを望んでいます。（この10分は、セキュリティホールを最小限に抑えるためのFBによる最善の努力のようです。）

ただし、この10分以内に、他の誰かがCookieをコピーして、問題なく被害者としてログインを試みることができます。これは私にとって懸念事項であり、次の質問をしたいと思います。

  1. FBのクライアント側認証のセキュリティ面に関してここで何かが欠けているのでしょうか、それとも実際にこの弱点がありますか？

  2. ギャップを埋めるために実装でできることはありますか、それともFBのサーバー側認証に移行することが唯一の答えですか？

4

1 に答える 1

1

サーバー側フローまたはクライアント側フローのどちらを使用する場合でも、正しく使用すれば、どちらも完全に安全です。おっしゃるとおり、ssl ベースでないサイトで Cookie オプションを使用することは確かに脆弱性ですが、これは Facebook によって制御されていない脆弱性です。

この攻撃ベクトルを完全に回避したい場合は、cookie オプションを使用せず、代わりに、選択したメカニズム (SSL 経由の XHR など) を使用して、フロントエンドからバックエンドに署名付きリクエストを渡します。これを行うには、関連するイベントをサブスクライブするだけです。ハンドラーは、署名されたリクエストをレスポンスの一部として呼び出します。

signed_request は、改ざんや誤った使用を避けるために、常にサーバー上で検証する必要があります。signed_request には、issued_at 時刻も含まれており、過去 10 分以内であることを検証する必要があります。(FB のユーザー ID には、FB で提供される user_id を使用します)。

于 2013-01-11T05:32:01.807 に答える