Facebook API：App Secret-誤用の可能性
私は最近、アプリケーションの1つのコンパイル済みコードを簡単にすばやく確認すると、Facebook APIのApp ID（API Key）とApp Secretの両方を取得できることを最近知りました。
私たちは本当にApp Secret（Wordから明らかにsecret）を保持して、誰もそれにアクセスできないようにする必要があると思いますが、これらのアイテムの漏洩に関連する主な脅威は何ですか？
evil guyがこれらのエントリを取得した場合、-彼が実行できる最悪の誤用は何ですか？
あなたは正しいです。アプリシークレットは秘密にする必要があり、クライアントコードをリバースエンジニアリングして簡単に取得することはできません。
FacebookはOAuthを使用するため、ここで言うすべてのことは、認証と認証にOAuthを使用するすべてのアプリケーションにも適用されます。アプリシークレットは、facebookに対してクライアントを認証します。ユーザー名/パスワードがWebサービスに対してユーザーを認証するのと同じように、モバイル/デスクトップクライアントは、サーバーの資格情報としてアプリの秘密鍵を使用して、その「実際の」正当なクライアントアプリであることを検証します。
悪者がこれらのエントリを取得した場合、悪者が実行できる最悪の悪用は何ですか？
クライアント/アプリケーションのように見えるスプーフィングされたクライアントを作成してリリースする可能性があります。無警戒なユーザーはそれをダウンロードし、それを使ってFacebookに接続します。ユーザーの資格情報の認証はFacebookのページで行われるため、偽のアプリはユーザーの資格情報を取得しません（これは良いことです）。ただし、ユーザーはFacebookでこの偽のアプリを承認することになります。 Facebookはその秘密を提示する誰もがあなたであると信じているので、喜んでそれを行います。その結果、偽のアプリはユーザーの「アクセストークン」を取得し、コメントの投稿を開始したり、実際のアプリが意図しない他のことを実行したりできます。
一言で言えば、ここで問題となっているのはあなたの評判の価値です。他のクライアントは、facebookのクライアントとしてなりすますことができます。
これは、コンシューマキー（アプリシークレットに相当）をプレーンテキストで格納した1つのTwitterクライアントの 完全なケーススタディ です。
私はそのブログから一行引用しています：
侵害された消費者秘密鍵がアプリケーションのユーザーのセキュリティを危険にさらすことはないことを理解することは非常に重要です。個々のアカウントにアクセスするには、認証プロセス中にユーザーの代わりにクライアントアプリケーションの個々のインスタンスが自動的に取得するアクセストークンが必要であるため、キーを使用して他のユーザーのアカウントにアクセスすることはできません。
では、クライアントシークレットをどのように保護しますか？
スタンドアロンのクライアント（モバイルアプリなど）の場合、何らかの形で埋め込む以外に選択肢はほとんどありません。エキスパートのリバースエンジニアにとっては残念ながら、デコードできるようになるのは時間の問題です。結局のところ クライアントのどこかに（何らかの形で）ある 。クライアントがそれを再計算/再アセンブルできる場合、リバーサーも可能です。
編集：アプリケーションアーキテクチャで許可されている場合、サーバーはクライアント/モバイルアプリに代わってOAuthステップを実行できます。このようにして、キーはサーバーに常駐し、すべてのOAuthステップを実行して、access_tokenをクライアントに渡し、それを使用してユーザーのFacebookデータにアクセスします。この時点で、ブラウザー-Webサーバー-Facebookの相互作用 ここで説明 と非常によく似た動作をしています。この図では、「ユーザーのブラウザ」を「クライアント/モバイルアプリ」に、「アプリ」を「サーバー」に置き換えてください。
これがWebアプリケーションの一種である場合、サーバー側にのみキーを保持し、Facebookの サーバー側のフロー を使用してアプリのシークレットが漏えいしないようにすることで簡単に実現できます。
Facebookの場合—他のOAuth対応サイトについては知りません—匿名のアプリケーションアクセストークンを使用する可能性があります。これは、appIdとappSecretを連結して作成されたトークンです。たとえば、504216299598238|59d273f6dddb0a2f72e727132f4a74a4。
このアクセストークンをモバイルアプリのソースから取得し、Graph APIに認証済みのリクエストを行うことができます。次に、Facebookは以前にこのアプリを承認したユーザーに関する情報を提供しますユーザーアクセストークンなしでも。
攻撃者は、この方法で機密のユーザーデータ（電子メールなど）にアクセスできます。ここに概念の証明があります：
このユーザーはアプリケーションを承認していません：
https://graph.facebook.com/100004668630549?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4
そして、これはそうしました：
https://graph.facebook.com/100004619894646?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4
それ以外の場合、電子メールフィールドは表示されません。結果：攻撃者は攻撃されたユーザーに関する機密情報を、そのユーザーからの対話なしに取得できます。