許可されたアプリケーションのみがアクセスするWebサービスを確保する
序文
私のモバイルアプリでは、ユーザーが私のサービスでアカウントを作成できます。 Facebookなどの外部認証プロバイダーを使用してログインできることに加えて、ユーザーに電子メールアドレスを使用してアカウントを作成するオプションを提供したいと考えています。
通常、私のWebサービスへのすべての呼び出しは、HTTPS経由の基本認証を介して認証されます。ただし、ユーザーの資格情報がまだないため、アカウント作成機能（HTTPSを介しても）は認証されません。
Webサイトを作成している場合は、Captchaを使用して、スクリプトを介してデータベースが偽のアカウントでいっぱいになるのを防ぎます。
質問
新しいユーザーリクエストがボットからではなく、アプリケーションのインスタンスからのものであることを確認するにはどうすればよいですか？
すべてのデータがHTTPS経由で送信される場合、アプリケーションが「ねえ、それは私です！」このようなことをするためのベストプラクティスは何ですか？
詳細
サーバーはJavaで記述されており、Spring FrameworkとSpring Securityを使用しています。サーバーはApp Engineでホストされています。コストは問題です（ネットワークと計算の両方）。アプリはモバイルゲームです。クレジットカード番号などの機密情報は保存しません。ただし、Apple and Android Stores）でのユーザーの購入を追跡します。私の最大の懸念はプレーヤーのエクスペリエンスです。ハッカーがシステムをダウンさせて誰かのゲームの楽しさを台無しにしたくはありませんし、アカウントを作成する際にプレイヤーができるだけ障害に直面しないようにする必要もあります。
更新/説明
サービスへのすべての呼び出しがアプリケーションのインスタンスからのものであることを確認する方法を探しています。ステートレスサービスでは、要求ごとに資格情報を送信する必要があるため、ユーザーアカウントは既に保護されています。セッションもクッキーもありません。
Create-new-accountなどの保護されていない呼び出しでボットスパムを停止する必要があります。 captchaはアプリの流れに合わないので使えません。
要するに、アプリにシークレットを埋め込む必要があるということです。 [〜＃〜] drm [〜＃〜] （多かれ少なかれ達成しようとしていること）が不可能であるのは残念なことです。アプリにアクセスできる人は、常に埋め込まれた秘密を回復することができます。あなたがそれを保護するために何をしようとも関係ありません。
とはいえ、埋め込まれた秘密を回復するのを非常に困難にするためにできることはたくさんあります。
実行時に構築します-アプリ内のどこかに文字列や構成ファイルにシークレットを保存しないでください。代わりに、実行時に一連の計算から導出します。これにより、攻撃者がhexeditorを使用してアプリを単に閲覧することを防ぎます。
決して有線で送信しないでください-128ビット以上のノンスを使用したチャレンジ/レスポンスシステムを使用して、攻撃者がSSLストリームをMitMできないようにします（これは、モバイルデバイスを制御するときに簡単です）、その秘密を平文で確認してください。
いずれの場合も、実証済みのテスト済みの鍵スクランブルメカニズムと認証プロトコルを見つけてください。自分で転がしてはいけません。
ほとんどの場合、これが「あなたのアプリ」であることを確認することはできません： リバースエンジニアリング が機能するため、アプリにアクセスできる人（たとえば、電話でダウンロードできる人）は、内臓を盗み、エミュレートできます。 PC。 @Lynksは、このリバースエンジニアリングをいらいらさせる努力についてのヒントを提供しますが、だまさないでください。攻撃者が十分にやる気を持っている場合、これらのメカニズムは、せいぜい数日で彼を遅くします。
質問に対する適切な回答がない場合、質問を変更するために地面を変えることは価値があります。ここで、「アプリ」がクライアント側で実行されるものであることを確認しようとする際の核となる問題は、「アプリ」のようなものがあることです。誰かがそのアプリのコンテンツを開いた場合、彼はどこでもそのアプリのすべてのインスタンスについて学習します。
だからここにあなたの問題の解決策の試みがあります。 各アプリインスタンスに個別の値でタグを付けます。ここでの「タグ付け」とは、ユーザーがアプリをダウンロードすると、一部のトークンがアプリに埋め込まれ、ダウンロードごとに新しいトークン値が作成されることを意味します。各ユーザーがトークンを使用して自分のアプリを取得できるようにします。アカウントを作成するためにトークンをサーバーに提示する必要があるという考えであり、サーバーが同じトークンを使用する要求が多すぎる場合、サーバーはそれらを自動的に拒否して、その特定のトークンを禁止することができます。
次に、多くのアカウントを自動的に作成し続けるために、攻撃者は新しいアプリインスタンス（それぞれに独自のトークン値を持つ）のダウンロードとダウンロードしたアプリからのトークン値の取得も自動化する必要があります。サーバーがアプリのダウンロードの反対側にあると仮定すると、そのような大量ダウンロードを検出して、そこからブロックすることもできます。
このスキームが機能するためには、アプリダウンロードサーバーでオンデマンドでトークン値を作成できる必要があります（ただし、既存のスマートフォンのアプリインストールシステムで設定するのは難しい場合があります）。アカウント作成サーバーは、トークン値が本物であるかどうかを決定します。 [〜＃〜] hmac [〜＃〜] はそのための正しい暗号化ツールです。
この種のソリューションは、完璧に近いものではないことに注意してください。これらは、攻撃者のために「レベルを上げる」ためのゲームとトリックです。私が説明したようなシステムを設計してインストールした場合、成功する攻撃者は、多数の異なるIPアドレスからのアプリのダウンロードを自動化して、レーダーの下にとどまる必要があります。そのようなものを検出するためのヒューリスティックの;次に、リバースエンジニアリングを自動化してトークン値を回復します（@Lynksで説明されている手法を使用してください）。次に、アカウントを作成するボットに値を転送します。これらすべてはまだ理論的に実現可能です。結局のところ、人間のユーザーがアプリをダウンロードしてアカウントを作成でき、外部から実際に違いを生み出す方法はありません。平均的な人間のユーザー、チンパンジー、ボット。
しかし、攻撃者が攻撃を「努力に値しない」と考えるほど十分に複雑にすることができれば、勝利します。
Webサイトを作成している場合、Captchaを使用して、スクリプトを介してデータベースが偽のアカウントでいっぱいになるのを防ぎます。
それをAPIに含めます。ユーザーがアカウントを作成する場合：
- クライアントはCAPTCHAを要求します。
- サーバーはCAPTCHAを生成して保存し、コピーをクライアントに送信します。
- クライアントは、CAPTCHAとともにアカウント作成フォームを提示します。
- ユーザーはフォームに入力し、CAPTCHAに回答します。
クライアントは、新しいアカウントの作成を要求し、その要求と共にCAPTCHA応答を送信します。
- CAPTCHAの回答が間違っている場合、サーバーはCAPTCHAのコピーを削除し（クライアントは再試行できません）、エラーで応答します。
HashCash のようなものを使用して、誰かがブルートフォース攻撃を開始するのを難しくすることもできます。ユーザーがフォームを合理的に完成させるよりも速くHashCashを生成できることを確認してください。
必要なのは、同様のアプリケーション認証です。これは、Twitter、Facebook、FoursquareなどのサイトでのAPI呼び出しに対して行う認証と同じ概念です。彼らは誰もが自分のAPIをクエリすることを許可していません。代わりに、アプリのAPIキーとAPIシークレットを生成します。アプリケーションがこれらのキーをサーバーに提示する場合は、それらのAPIを使用できます。
アプリを通じてAPIを確実に使用したい場合は、定期的にすべてのエンドポイントを変更し、クライアントアプリでもそれらを変更する必要があります。 APIを使用して独自のクライアントアプリを作成したユーザーには、機能しないクライアントアプリが残ります。これで、正しいAPIエンドポイントを使用してアプリを再構築できるようになりますが、エンドポイントを変更し続けると、結局あきらめるだけです。
別の方法としては、誰かがそれらを呼び出そうとしたときにのみエラーメッセージを返す古いAPIエンドポイントと、更新されたクライアントアプリで使用されている新しい（変更された）APIエンドポイントの両方を使用することもできます。古いAPIエンドポイントを使用しているすべてのIPアドレスを禁止します。これにより、ハッカー/泥棒がサードパーティのクライアントアプリを更新して、更新されたエンドポイントに一致させると、古いAPIエンドポイントを使用していたすべてのユーザーが禁止されるため、ユーザーベースがなくなることになります。これにより、その人が自分のクライアントアプリにデータを表示してデータを盗み続けることも阻止されます