3

アプリから Facebook への呼び出しを検証できるように、アプリの署名を Facebook サーバーに保存する必要がある Facebook Android SDK を Android アプリに実装しています。このシステムを独自のバックエンドに使用して、アプリでのみ使用されるようにしたいと考えています。これに関して、次の質問があります。

(関連するクラスを見つけるには、https://github.com/facebook/facebook-android-sdk/tree/master/facebook/src/com/facebook/androidを参照してください)

  1. 明らかに、署名を照合して呼び出しを検証するには、アプリの署名をサーバーに送信する必要があります。SDK内で、これがどこで行われているのかわかりませんか?
  2. httpsが使用されていないようですが、そうですか？(Util.java)
  3. このシステム全体を無意味にして、署名を盗聴することはできませんか?
  4. Facebook.java は、ファイルの下部に Facebook アプリの署名を保持します。これを変更するのは簡単なことのように思えるかもしれません。ただし、インテントを送信するアプリの署名を理解する限り、そのインテントを介して解決できます。Android システムがこれを管理するため、署名を偽造することはできません。しかし、URL を呼び出すとき、Android システムは不変の方法で署名をプロトコルに追加できますか? そうではないと思うので、上記の質問について疑問に思います。

[nitzan & zapl に返信して編集]

私が達成しようとしているのは、facebook SDK がサーバーに署名を保存する必要がある理由と同じです。バックエンドへの呼び出しがアプリから送信され、それ以外のものがないことを確認します。ボットや他のアプリがサーバー API にアクセスすることを許可したくありません。facebook SDK には、インテントが Facebook アプリから発信されているかどうかを確認するメソッドがあります。これは、Android システムによる署名とインテントのクローズド管理により安全です。これを妥協する唯一の方法は、アプリの署名をオーバーライドできるようにする変更された Android バージョンを実行することですが、人々が構築して実行する可能性は無視できます。ただし、アプリを実行し、https 以外のプロトコルで送信された署名をスニッフィングし、API 呼び出しでこの署名を使用するアプリを構築することはできません。このようなシステムを機能させるには、https を使用するしかないようです。

上記で説明したインテント検証メソッドは、Facebook サーバーへの URL 呼び出しとは異なることに注意してください。インテントは、デバイス上の Facebook アプリが SDK を実装するアプリと通信するために使用されます。Android システムは、着信インテントで送信される Facebook アプリの署名が偽造できないことを保証するため、Facebook アプリからアプリへの通信システムは安全です。この内部システムとは対照的に、私の質問は、サーバーへの送信 URL 呼び出しの外部システムに関するものです。呼び出しに沿って署名を不変に送信できれば安全であり、基本的にインテント システムと同じシステムを実装します。

[編集2]

私たちが想定していたものとは対照的に、アプリの署名は簡単に取得できることがわかりました。アプリは秘密開発者キーを使用して署名する必要がありますが、これは Android 上のアプリに関するセキュリティを損なうものではありませんが、API 呼び出しのサーバー側の検証には使用できないことは明らかです。

これにより、さらに疑問が生じます。

  1. 簡単に侵害されてしまうのに、なぜ Facebook はこのシステムを実装しているのでしょうか?
  2. サーバー API アクセスを特定のアプリのみに制限する既知の実装は他にありますか? （難読化以外）
4

2 に答える 2

1
  1. 知らない。
  2. はい、このコードを使用した接続には暗号化がないことを意味するfbconnect://Uri を置き換えているようです。http://
  3. はい、それを確認してみてください。
  4. それを変更しても問題ありません。必要に応じて、apk を逆コンパイルして一部のコードを変更し、コンパイルして戻すことができます。その場合にできない唯一のことは、apk に再度署名することです (そのために必要な秘密鍵がありません)。または、独自のコードで署名を使用できます。
    アプリの署名チェックはインストール時に行われ、署名が要件に一致しない場合、マニフェストで要求したアクセス許可は削除されます。apk を更新すると、新しい apk の署名が古い既存の apk に対してチェックされ、署名が一致しない場合、アップグレードは失敗します。ただし、古いものをアンインストールして、偽物をインストールすることはできます。
    アプリからインテントを送信する場合、システムには送信者のパッケージが含まれている可能性があり、それを変更するアクセス権はありません。

また、アプリを認証する完全な方法がないため、サーバーに対する検証の全体的なポイントは、最終的にはセキュリティの問題ではありません。他の人が API を悪用するのを困難にするために使用され、誰が API を使用しているかを追跡するために使用されます。

認証メカニズムでは、apk 内にある種の秘密鍵が必要です。しかし、その apk を潜在的に悪意のある顧客に出荷するため、それを制御できなくなり、キーを抽出して悪用することが可能になります。できることは、キーを難読化して、取得しにくくすることだけです。しかし、それは最終的に不可能です。

バックエンド サーバーと通信するアプリがあり、そのアプリを自分のデバイスにダウンロードしたとします。次に.apk、デバイスを取り出して逆コンパイルし、サーバーとの通信がどのように機能するかを確認します。https が作成される前のプレーンテキストです。また、アプリの署名が何であるかを確認できます。これは、デバイスの xml ファイルと apk にも保存されています。次に、アプリを変更するか、情報を使用して新しいアプリを作成し、アプリではないことを除いて、あなたのアプリとまったく同じように動作させます。https を使用しても問題ありません。署名も送信できます。

それを防ぐことはできません。それを難し​​くすることしかできません。

于 2012-04-29T13:55:31.890 に答える
0

信頼されていないデバイスで実行されているアプリを検証するには、アプリだけが保持するキーを使用して、アプリからの通信にデジタル署名を要求するなどの処理をサーバーで実行する必要があります。

アプリの作成者は、なりすましで使用するために抽出するのが比較的困難な方法で、アプリ内にキーを隠蔽する必要があります。しかし、抽出を不可能にすることはできません。

アプリの抽出されたキーで武装した偽者は、それだけで任意のユーザーになりすますことはできませんが、実際のパスワードを持つ実際のユーザーがアプリの偽装バージョンから (故意または無意識に) ログインできる可能性があります。 . 実際にサーバーにログインできることは、無意識のユーザーからパスワードを盗むだけの目的で設計された偽のアプリの要件ではない可能性があることに注意してください。

アプリは SSL が壊れているプラ​​ットフォームにインストールされたり、インターセプトを達成するために内部 SSL 実装を壊すようにパッチが適用されたりする可能性があるため、SSL はアプリ自体を保護するためにほとんど価値がありません。ただし、効果的な SSL は、侵害されていないデバイスでアプリのユーザーを保護するのに役立ちます。

于 2012-04-29T17:27:48.997 に答える