Android oauth 2.0クライアントアプリケーションにクレデンシャル(クライアントIDとクライアントシークレット)がハードコーディングされている場合、アプリケーションを逆コンパイルしてクレデンシャルを取得するのは非常に簡単です。クライアントIDとシークレット
を公開するとどうなりますか?
3 に答える
これはStackOverflowの適切な回答ではないことはわかっていますが、脅威モデルとセキュリティの考慮事項(RFC 6819)よりもうまく説明できるとは思いません。したがって、ここにクライアントシークレットの取得とその相対的な結果に関する段落があります。
Androidアプリはパブリッククライアント(より具体的にはネイティブアプリケーション)であるため、あなたが言うように、その資格情報の機密を保持することはできませんが、トークンと認証コードを保護することはできます。
また、あなたのケースで興味深いのは、スマートフォンに関する例です。
RFCが最も面白い読み物ではないことは知っていますが、RFCはかなり明確です。
これによると、これはセキュリティの問題です: http ://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation
リンクが機能しなくなった場合は、次のように表示されます。
OAuthがブラウザベースの承認に依存しているため、モバイルまたはデスクトップアプリケーションの実装の継承に問題が発生します。これらのアプリケーションは、デフォルトではユーザーのブラウザでは実行されません。さらに、純粋なセキュリティの観点から、主な懸念事項は、実装者がクライアントアプリケーション自体にキーとシークレットの組み合わせを保存して難読化する場合です。これにより、キーのローテーションがほぼ不可能になり、コンシューマーシークレットが保存されている逆コンパイルされたソースコードまたはバイナリへの不正アクセスが可能になります。たとえば、Android上のTwitterのクライアントのクライアント資格情報を侵害するために、攻撃者はAndroidの逆アセンブラーツールであるdexdumpを使用してclasses.dexを簡単に分解できます。
dexdump - d classes.dex
上記はより詳細になり、かなり素晴らしい読み物です。
ただの注意:クライアントIDは設計上秘密ではないため、実際には保護する必要はありません。
RFC 6749(「OAuth2.0認証フレームワーク」)のセクション2.2を参照してください。
クライアント識別子は秘密ではありません。リソース所有者に公開されており、クライアント認証に単独で使用してはなりません。