2011年2月20日：
今日Facebookによって、access_tokenがオープンでブロードキャストされる呼び出しが1つあることが確認されました。。。これは、アプリケーションデータベースに保存する前に、ユーザーがまだログインしていることを確認するために使用する1回の呼び出しです。彼らの推奨は、先月の時点で提供されているSSLオプションをcanvasとfacebook全体に使用することでした。ほとんどの場合、AuthとAuthは安全です。
調査結果：
私の投稿に続いて、これは実際には問題ではないという発言がありましたが、私は確かにそれを仮定したと思いました。ここに曖昧さがないように、次のような質問があります。
Canvas Loadプロセス中にFacebookから送信されたデータは、access_token、セッション、およびユーザーを一意に識別できるその他のデータなど、ある時点で公開されていないため、レイヤーを1つ追加する以外の方法はありません。つまり、access_toeknとともにHTTPSを介してネットワーク経由で送信されるパスワードで、ユーザーによるセキュリティが改ざんされていない一意のデータを保証しますか？
Wiresharkを使用して、Canvasアプリケーションページの読み込み中にローカルブロードキャストをキャプチャしました。access_tokenの放送が公開されていて、誰でも見ることができるのを見て、私は非常に驚きました。このaccess_tokenは、FacebookOpenGraphAPIへのhttps呼び出しに追加されます。
フェイスブックをシングルクリックログオンとして使用することは、今私にとって大きな懸念を引き起こしています。これはメモリ内のセッションオブジェクトに保存され、アプリの終了時とFBの確認後にCookieがクリアされます。Init呼び出しでは多くのHTTPS呼び出しが見られたため、access_tokenは常に暗号化されていると想定しました。
しかし、昨夜、ステータスバーに、App IDを含む単なるhttp呼び出しからの呼び出しが表示されたので、ApplicationCanvasのロードシーケンスをスニッフィングする必要があると感じました。
今日、私はブロードキャストをスニッフィングしました。添付の画像では、access_tokenがオープンでクリアにブロードキャストされているhttp呼び出しがあり、誰でもアクセスできるようになっていることがわかります。
私は何かが欠けていますか、私が見ているものであり、私の解釈は本当に正しいです。誰かがaccess_tokenをスニッフィングして取得できる場合、コールバックはFacebookのアプリケーション設定で確立されたサイトである必要がありますが、理論的にはhttps経由でGraphAPIを呼び出すことができます。
しかし、本当にセキュリティの脅威となるのは、自分のサイトへのアクセスにaccess_tokenを使用している人です。安全であると確立された唯一のものがaccess_tokenである場合、Facebook経由のシングルサインオンの価値はわかりません。はっきりと見えるのは安全ではないからです。有効期限のないアクセストークンは変更されません。Access_tokensはユーザーごとに異なります。別のサイトへのアクセスは、1人のユーザーだけに制限される可能性がありますが、1人のユーザーのデータを危険にさらすことは許されません。
http://www.creatingstory.com/images/InTheOpen.png
戻って、これについてさらに調査を行いました。
調査結果：
キャンバスアプリケーションを再実行して、ブロードキャストされていないコードがないことを確認しました。
この呼び出しでは：HTTP GET /connect.php/en_US/js/CacheData HTTP / 1.1
ユーザーIDはCookieにはっきりと表示されます。したがって、USER_IDは完全に表示されますが、すでに表示されています。誰でもほとんどすべてのページに移動し、画像にカーソルを合わせてユーザーIDを確認できます。したがって、大きな脅威はありません。APP_IDも簡単に取得できますが、。。。
http://www.creatingstory.com/images/InTheOpen2.png
上記のファイルは、Facebookが開始した通話を介してOPENでフルアクセストークンを明確に示しています。
私が間違っている。私はこれについて間違っているので、私は間違っていると言ってください。
その後、アプリのシークレットをリセットしたので、読み込まれているCanvasページの実際のスニフを表示しています。
追加データ2011年2月20日：
@ifaour-回答をまとめるのに時間を割いていただきありがとうございます。
私はOAuthプロセスに精通しており、signed_requestの解凍とaccess_tokenの利用についてかなりしっかりと理解しています。私はサーバー上でかなりの量の処理を実行し、Facebookサーバー側のフローはすべて完全であり、私が知っている欠陥なしに機能しています。アプリケーションシークレットは安全であり、フロントエンドアプリケーションに渡されることはなく、定期的に変更されます。私はできる限りセキュリティに熱狂的であり、戻ってきて私を噛む可能性があることを私は知らないことがたくさんあることを知っています。
2つの大きなaccess_tokenの問題：
問題は、ユーザーエージェント（ブラウザー）からのaccess_tokenの使用の可能性に関するものです。Facebook JavaScript SDKのFB.INIT（）プロセス中に、セッションオブジェクトと呼ばれるメモリ内のオブジェクトと同様にCookieが作成されます。このオブジェクトは、Cookieとともに、access_token、session、secret、uid、および接続のステータスを含みます。セッションオブジェクトは、新しいOAuthとレガシーフローの両方をサポートするように構成されています。OAuthを使用すると、access_tokenとstatusは、セッションオブジェクトで使用されるものとほぼ同じです。
最初の問題は、access_tokenを使用してGRAPHAPIへのHTTPS呼び出しを行うことです。access_tokenがあれば、どのブラウザからでもこれを行うことができます。
https://graph.facebook.com/220439?access_token= ..。
そしてそれはユーザーに関する大量の情報を返します。したがって、アクセストークンを持っている人は誰でもFacebookアカウントにアクセスできます。また、access_tokenに関連付けられたアプリケーションへのアクセスをユーザーが許可した情報に対して追加の呼び出しを行うこともできます。最初は、GRAPHへの呼び出しには、アプリのセットアップで確立されたURLへのコールバックが必要だと思いましたが、以下のようにテストすると、情報がブラウザーに返されます。そのコールバック機能を追加することは、私が思うに良い考えであり、物事を少し引き締めます。
2番目の問題は、サードパーティのデータベースに対してユーザーを識別するいくつかの一意のプライベート保護データの利用です。つまり、私の場合のように、この一意の保護データ項目を使用してユーザー情報をデータベースに入力するためにシングルサインオンを使用します（つまり、APP ID、USER ID、および秘密のシーケンスでハッシュされたものを含むaccess_token）。これはサーバー側の問題ではありません。あなたはsigned_requestを受け取り、それを秘密で解凍し、HTTPS呼び出しを行い、HTTPS応答を取り戻します。ユーザーがユーザーエージェント（ブラウザ）を介して入力された情報をPOST経由で保存する必要がある場合、この一意の保護されたデータ要素は、データベース挿入前に検証されるようにHTTPS経由で送信されます。
ただし、シングルサインオンプロセスを介して提供される保護された一意のデータがない場合、不正アクセスを保証する方法はありません。access_tokenは、FacebookがGRAPHAPIへのHTTPS呼び出しを行うために使用する1つのデータです。これは、ユーザーとアプリケーションの両方に関して一意であると見なされ、signed_requestパッケージを介して最初は安全です。ただし、その後、平文で送信され、ワイヤーを盗聴してaccess_tokenを取得できれば、アプリケーションのふりをして、アプリケーションに表示を許可した情報を取得できます。上記の例をSafariおよびIEブラウザーから試したところ、ブラウザーにすべての情報が返されました。
結論として、access_tokenはsigned_requestの一部であり、それがアプリケーションが最初に取得する方法です。OAuth認証と承認の後、つまり、ユーザーがFacebookにログインしてアプリを実行した後、access_tokenは上記のように保存され、ネットワーク経由で送信されるCookieに保存されていることを確認するためにスニッフィングしました。データベースとの対話をサポートするために使用できる一意のセキュリティで保護された識別可能な情報はありません。つまり、access_tokenとともにデータベースに送信された安全なデータがもう1つない限り、つまりパスワードです。それが正当な呼び出しであるかどうかを見分けることができません。幸い、POSTを介して安全なAJAXを利用し、呼び出しは同じドメインから発信される必要がありますが、それを乗っ取る方法があると確信しています。
このシングルサインオンプロセスを介して別のレイヤー（パスワード）を追加する以外に、ユーザーを一意に識別する方法、またはデータを誤って読み取って分析したことを誰かが私と共有する場合、 access_tokenは、常にネットワーク上で安全です。
事前にマハロヌイロア。