RESTサービスの「パブリック」部分をスパムから保護するにはどうすればよいですか？

Question

私は合理的に完了し、iOSアプリケーションで使用されるRESTサービスを持っています。 Ruby/Sinatraを使用して構築されていますが、実際にはそれは重要ではないと思います。

私はさまざまなエンドポイントでSSLを介したHTTP基本認証を使用しており、その部分は非常にうまく動作しています。

質問：HTTP基本認証で保護されていないRESTサービスの呼び出し部分からスパマーなどを停止する方法を教えてください。

例：ユーザー登録

はのは、REST呼び出しが体内にJSONオブジェクトを渡し（POST）.../register_accountであると仮定しましょう。

明らかな理由から、この呼び出しでは、ユーザーアカウントにリンクされたユーザー名/パスワードは期待できません。

アイデアは以下のとおりです。

1）アプリは、独自の「ユーザー名」/パスワードを持っており、いくつかの呼び出しは、アプリケーション・資格情報をチェックします。 問題：デバイスなどを起動すると、これらの資格情報が検出される可能性があります。

2）アプリは、HTTPヘッダを介して秘密トークンをRESTサービスに渡します。 問題：（1）と同じ

このようなスパムコールを防ぐために一般的に使用されている方法はありますか？私はおそらく、ミックスのiPhoneのデバイスIDを導入する考えているが、まだ明確なアプローチを特定していない。

おかげ

Answer 1

アプリ固有のコードはスパム対策の第一線では良いアイデアですが、懸念しているサービスにはまだレート制限を実装する必要があります。

たとえば、RESTサービスでセッションを使用すると、処理するコールの数を単一のセッションから簡単に制限できます。セッションは全く認証する必要はなく、要求を出している間に単一のクライアントを識別するためにのみ使用されます。開いているセッションなしで接続しようとすると、要求されたサービスに簡単にリダイレクトされ、必要なものだけがすべて必要です。実質的にすべてのWebフレームワークまたはスタックに組み込まれています。

IPまたはユーザーエージェントのフィンガープリントが含まれますが、これらはセッションベースの方法より信頼性が低くなります。

Answer 2

あなたでしrequest.ipを使用して、その周りにいくつかのロジックを記述トラックIPアドレス。

Answer 3

一般的なアプローチはAPIキーです。これは上記で説明した秘密トークンと同じです。これをアプリケーションにハードコードして、誰かがそれをリバースエンジニアリングするのを難しくします（非表示にする、アプリケーション内のさまざまな場所に格納されたさまざまなパーツからビルドするなど）。あなたは、決定された攻撃者がキーを回復することができるという点で正しいです（あなたのアプリがそうすることができれば、あなたのアプリにアクセスできる他の人も同様です）...しかし、うまくいけば、そうする時間と努力の価値がある。

相互認証されたSSLを展開することもできます。これにより、サーバーはアプリケーションからの着信接続のみを受け付け、アプリケーションはサーバーとの通信のみを行います。

ここには、高度なアプローチがあります。自己署名入りのサーバーSSL証明書を作成し、Webサーバーに展開します。次に、自己署名付きクライアントを作成し、アプリケーション内でリソースとして展開します。クライアント側のSSL認証を要求し、生成したクライアント証明書のみを受け入れるようにサーバーを構成します。そのクライアント側の証明書を使用して自分自身を識別し、その部分のサーバーにインストールしたサーバー側の証明書を1つだけ受け入れるようにクライアントを構成します。

アプリ以外の誰かがあなたのサーバーに接続しようとすると、サーバーはあなたのアプリに含まれているクライアント証明書を提示しない受信SSL接続を拒否するため、SSL接続は作成されません。