ベストプラクティスでは、iPhoneアプリのみWebサービスのアクセスを検出しますか？

Question

私はWebサービスと一緒にiPhoneアプリを開発しています。 iPhoneアプリはGETまたはPOSTを使用して、http://www.myserver.com/api/top10songs.jsonなどのWebサービスからデータを取得し、上位10曲のデータを取得します。

iPhoneアプリのユーザーアカウントとパスワードはありません。私のiPhoneアプリだけがWeb API http://www.myserver.com/api/top10songs.jsonにアクセスできるようにするためのベストプラクティスは何ですか？ iPhone SDKのUIDeviceのuniqueueIdentifierは、誰でもwget、curl、またはWebブラウザを使用してAPI呼び出しを行うパラメータとしてデバイスIDを偽装できるため、十分ではありません。

ウェブサービスAPIは公開されません。 Webサービスのデータは秘密ではなく、私的なものではなく、使用ログなどのサーバーにデータを書き込むAPIもあるため、悪用を防止したいだけです。

Answer 1

あなたができることはあなただけが知っている秘密鍵を取得することです。これをmd5ハッシュシグネチャに含めると、通常、署名とその最後に追加された秘密がパラメータとして取り込まれますそのmd5ハッシュ...クライアントとサービス側の両方でこれを行い、署名が一致する場合にのみ署名文字列にマッチします。秘密は署名にのみ存在するためリバースエンジニアリングとクラックが発生しにくい。

Answer 2

ご要望により、digital signaturesという形式を使用してください。これを完全に不正な証明にするのはむしろ難しいです（セキュリティに関しては何でも）。ほとんどの虐待を防ぐために、それを「十分に」得ることは難しいことではありません。

もちろん、これはデータの機密性に大きく左右されます。データトランザクションに100万ドルのトランザクションが含まれている場合は、単純な使用統計ログよりも安全です。あなたを怒らせることを除いて攻撃者にほとんど利益を得ない、人々が気にしないと仮定するのは安全です...）

Answer 3

これを行うには非常に安価な方法は、たとえば、誰かがフィードにアクセスできないように長いパスワード文字列などです。

ネットワークを介して送信されたデータを聞いてリバースエンジニアリングしたり、帯域幅の制限がある場合は、単純なパスワードで十分です。

もちろん、この方法には問題があり、証明書ベースの認証は実際には安全ですが、コード化するのは難しくなります。

Answer 4

ここでの解決策のすべてではないにしても、ほとんどの問題は、プロキシをミックスに追加した後ではかなり壊れやすいということです。プロキシがWebサービスに接続している場合は、それは問題ありませんか？結局のところ、おそらく中国のどこかで、おそらくiPhoneの代わりにそうしているだろうか？プロキシがiPhoneを偽装しても問題ない場合は、どの偽装がOKかをどのように判断するのですか？

Answer 5

最も安全な解決策は、おそらく要求のデジタル署名である。あなたはiPhoneアプリの中に秘密の鍵を保持し、それを使ってリクエストに署名することができ、それをサーバ側で確認することができます。これにより、サーバーにキー/パスワードを送信することが回避され、誰かがネットワークスニファでそれを取得できるようになります。

単純な解決策は、HTTPSを使用することだけかもしれません。潜在的な盗聴者が存在するにもかかわらず、メッセージの内容を安全に保つことがHTTPSの重要なポイントです。標準NSURLConnectionのもので自己署名証明書を実行できるかどうかはわかりませんが、サーバーサイド証明書を持っている場合は、少なくとも盗聴から保護されています。そして、あなたが書き込むコードがずっと少なくなっています（実際には、何もありません）。

HTTPSを唯一のセキュリティとして使用すると、URLを推測している人に公開されている可能性があります。それが問題であれば、Webサービスにあらゆる種類のパラメータ検証を追加するだけで対応できます。

Answer 6

ここではダニエルの提案についての拡張です。

サーバーとクライアントが知っている共有秘密があります。いくつかの長いランダムな文字列を言う。

クライアントが接続すると、クライアントに別のランダムな文字列を生成させ、共有文字列の最後に追加してからMD5ハッシュを計算します。

ランダムに生成された文字列とハッシュの両方を要求のパラメータとして送信します。サーバは秘密の文字列を知っているので、それ自身のハッシュを生成し、それがクライアントから受け取ったものと一致することを確認することができます。

誰かがあなたのアプリを逆コンパイルして秘密の文字列を判断できるので、完全に安全ではありませんが、余分な作業をすることなく最高の状態になるでしょう。

Answer 7

アップルのセキュリティエンジニアにWWDCでこれを尋ねました。彼はこれを達成するための方法がないと言いました。あなたができることは、努力をする価値がないようにすることです。

私はまた、これを行う方法としてプッシュ通知を使用する可能性について尋ねました。彼は非常に良いアイデアだと思っていました。基本的な考え方は、最初のアクセスがユーザーのiPhoneに送信されるサーバーでプッシュ通知をトリガーするということです。アプリケーションが開いているので、application:didReceiveRemoteNotification:メソッドが呼び出され、自分が選択したペイロードを配信します。そのペイロードをnonceにすると、アプリケーションは次のリクエストでnonceを送信し、サークルを完成させることができます。

UDIDを保存して、未検証のUDIDを持つリクエストを破棄することができます。限り、ブルートフォースは、必要なパラメータの推測、あなたはレート制限アルゴリズムを実装する必要が何であっても。

Answer 8

現在の時刻（GMT）を使用するアルゴリズムに基づいて、5分ごとに何らかの種類のキーが変更されます。最後の2つのキーを常に許可します。これはもちろん完璧ではありませんが、目標を動かし続けるので、他の戦略や戦術と組み合わせることができます。

あなたのサービスの使用を断念したいと思っています。明らかに、アプリを安全に設定していない。