[解決済み] OAuthのコンシューマーシークレットを安全に保つ方法と、それが漏洩した場合の対処方法とは？

消費者秘密を漏らしたハッカーは何ができますか

また、次のように述べていることは正しいでしょうか。

• ハッカーは、私のアプリを模倣したアプリケーションをセットアップ/パブリッシュすることができます。 アプリケーションをセットアップして公開することができます。
• ハッカーは、OAuthフローを通過するユーザーを引き付けることができます。 OAuthフローを経由して アクセストークンはハッカーの OAuth ダンスを通じてアクセストークンを取得します (漏洩したコンシューマーキー/シークレットを使用)。 キー/シークレットを使用)。
• ユーザーは 私のアプリを扱っているのだと思うかもしれません。 見慣れた名前 (コンシューマー キー) が表示されるため を見るので、私のアプリを扱っていると思うかもしれません。
• を介してコンシューマがリクエストを発行すると ハッカーはアクセストークンを簡単に傍受することができます。 アクセストークンを傍受し コンシューマーシークレットと組み合わせることで 私の代わりにリクエストに署名して 私のリソースにアクセスできるようになります。

エンドユーザーへの影響

という前提で

• ハッカーが私の消費者秘密を使用してアプリケーション/サイトをセットアップした場合 サイトを構築している。
• 私のユーザーの一人が、そのアプリケーション/サイトへのアクセスを承認するように騙されました。 そのアプリケーション/サイトへのアクセスを承認させられた

次のようなことが起こるかもしれません。

• エンドユーザーが、何かおかしなことが起こっていることに気づき、サービス プロバイダ (例: Google) に悪意のあるアプリについて知らせる可能性があります。
• サービスプロバイダはコンシューマキー/シークレットを取り消すことができる。

OAuthコンシューマ(私のアプリケーション)の影響 :

私のアプリ（コンシューマーシークレットを含む）を更新する必要があります。そうしないと、すべてのクライアントが、彼らに代わって私のアプリケーションがリクエストを行うことを承認できなくなるからです（私のコンシューマーシークレットがもはや有効でなくなるため）。

すべての OAuth トラフィックを委譲する

OAuthのやりとりの多くを中間Webサーバ経由で委任することは可能ですが（OAuthダンスを行い、アクセストークンをユーザに送信する）、各リクエストに署名するためにコンシューマキー/秘密が必要なので、すべてのサービスのやりとりも委任しなければならないでしょう。コンシューマ キー/機密をモバイル アプリの外に置き、中間 Web サーバーのより安全な場所に保存するには、この方法しかないのでしょうか？

代替案

このプロキシに代わるものはありますか？中間ウェブサーバーに消費者秘密を保存し、（市場で公開され適切に署名された）Android アプリが中間ウェブサーバーに消費者秘密を取得しアプリ内部に保存するための安全なリクエストを行うことができる何らかのメカニズムを持つことは可能でしょうか？中間ウェブサーバーは、これが消費者秘密を取得するよう要求している公式のアンドロイド アプリであることを知っており、中間ウェブサーバーはその特定のアンドロイド アプリにのみ消費者秘密を提供するというメカニズムを実装できますか？

どのように解決するのですか？

概要 : 私なら、リスクをとってクライアントアプリで秘密を守るだけです。

プロキシサーバの代替 :

サードパーティの Web サービスのリソースを処理するためのすべてのビジネス ロジックをプロキシ サーバーに移動し、クライアント アプリを豊かな UI を備えたダム端末にすることです。この方法では、悪意のあるアプリがプロキシに代わって実行させることができる唯一のアクションは、あなたのビジネスロジックが正当に必要とするものだけになります。

しかし今度は、信頼性とスケーラビリティに対処しなければならない、他の多くの問題の領域に入っていくことになるのです。

単純なプロキシがなぜ機能しないかについての長い考察 :

ある人は、問題に直面したとき 問題に直面したとき、「そうだ、自分のプロキシサーバを追加しよう」と考える人がいます。 と考える人がいますが、この場合、2 つの問題があります。 の問題があります。(Jamie Zawinskiに謝りながら) Zawinski に謝意を表します)。

あなたの仮定はおおむね正しいです。サーバーが秘密を保持し、クライアント アプリの呼び出しをプロキシするか、アプリが正当かどうかを判断して秘密を与えるかについて考え始める時点までです。どちらのアプローチでも、「このリクエストは私が書いたコードの一部から来ているのか」という問題を解決しなければなりません。

もう一度言います。 は、特定のソフトウェアが実行されていることをワイヤー上で区別する方法はありません。メッセージ内のデータが正しく見えても、そのメッセージを送信しているのが別のアプリであることを証明するものは何もありません。 .

結局のところ、私が悪意のあるアプリを書いている場合、本当の秘密を実際に知っているかどうかは気にせず、それを知っている誰かに私の代わりに仕事をさせることができればよいのです。悪意のあるアプリがサード パーティの OAuth サーバーにあなたのアプリを偽装できると思うのなら、なぜプロキシにあなたのアプリを偽装できないと確信できるのでしょうか。

しかし、待ってください、まだあります。プロキシ サービスのあるドメインは、クライアントと OAuth プロバイダの両方に対して、あなたのアイデンティティとなります (OAuth プロバイダがエンド ユーザーに示すように)。悪意のあるアプリがあなたのサーバーに悪いことをさせたら、あなたの鍵が取り消されるだけでなく、あなたの公開ウェブ ID も信頼されなくなります。

特定のソフトウェアが実行されていることを、ワイヤ上で区別する方法はありません。メッセージ内のデータが正しく見える場合、そのメッセージを送信しているのが別のアプリであることを証明することはできません。

したがって、アプリ側の保存された秘密に依存するどんなアルゴリズムも、なりすますことができます。OAuth の強みは、ユーザーの認証情報をアプリに渡さない代わりに、アプリに一時的な認証情報を与え、ユーザーが必要に応じて取り消せるようにすることです。

もちろん、ここでの弱点は、十分に優れたアプリが、その悪事を終える前に、ユーザーに信用させ、クレデンシャルを取り消さないようにすることができるという点です。

しかし、これを軽減する1つの方法として、標準の2本足ではなく、3本足のOAuthを使用するというGoogleのアプローチがあります。3 レッグ OAuth では、事前に割り当てられた秘密はなく、認証のたびに、各アクセストークンとともに新しいアクセストークンの秘密が発行されます。これは、悪いアプリがそのプロセスから良いアプリのトークンシークレットを読み取ることができるという同じ欠点がありますが、新しいアクセストークンが必要になるたびに、ユーザーがそのアプリへのアクセスを承認する必要があるという結果になります。

そしてもちろん、これはユーザーにとって少し不便で煩わしいということも意味します。