1

I'm programming an Android application and want to define rooms. The rooms would hold all the users of certain game. This is like poker with 4 players, where each room can hold 4 users. I also want to use rabbitmq for scalability and customobility. The problem is that the Android application uses the same username:password to connect all users to a RabbitMQ server (specific virtual host).

I guess I'm worried that one user might be able to read/write messages from different queues that it should. There are multiple solutions that are not satisfactory:

  1. Use a different user in each Android application: This really can't be done, because the Android Market doesn't allow different applications for each user that downloads it. Even if it did, it's a stupid idea anyway.

  2. Set appropriate access controls: http://www.rabbitmq.com/access-control.html . I guess this wouldn't prevent the problem of a malicious attacker reading/writing messages from/to queues it doesn't have access to.

  3. Set appropriate routing keys: I guess if each user creates another queue from which it can read messages and published messages to specifically defined queue, this can work. But I guess the problem is the same, since users will be connecting to the RabbitMQ with the same username:password: therefore this user can read all queues and write to them (based on the access rules).

My question is: how to allow an attacker from reading/writing to queues that represent only the rooms he's currently joined in, and preventing access to other queues?

4

2 に答える 2

2

私は自分でポーカー アプリケーションに取り組んでいます =)

私は Akka/Actors (Erlang をチェックしてください) のようなストリーミング Web ソケット経由のトラフィックに依存しており、それがうまくいくことを願っています (まだ安全な Web ソケットについて心配しています)。

とは言っても、プレイヤーのアクションを受け取るRabbitMQも検討中です。ユーザー名やパスワードをウサギのキューにさらしたくないと思います。実際のところ、外の世界からキュー サーバーにアクセスできるようにしたくない場合もあります。

代わりに、ユーザーが接続を確立できるサーバーをセットアップします。これは、Android クライアントが通信する「フロント エンド」になります。各ユーザーは、安全な TCP 接続を介してサーバーに接続し、システムにログインします。これは、ユーザーが独自のユーザー名とパスワードを持つ場所です。認証が成功した場合は、ソケットを有効に保ち (これは、TCP に関する私の知識が弱いところです)、ユーザー情報をこのソケットに関連付けます。

プレーヤーがフォールドやレイズなどのアクションを実行すると、そのアクションが安全な TCP 接続を介して「フロント エンド」に送信されます (この接続は引き続き確立されます)。次に、「フロントエンド」は、どのユーザーがこのソケットに接続されているかを確認し、理想的にはユーザー ID、実行されたアクション、およびテーブル ID を含むメッセージをキューに発行します。つまり、キューにアクセスできる唯一の IP はフロント エンド サーバーであり、フロント エンド サーバーは単一のユーザー名/パスワードをウサギ キューに使用するだけです。

キューメッセージの交換を処理し、メッセージを適切なテーブルにルーティングするのはあなた次第です (または、テーブルが責任のあるメッセージのみを処理するようにします。これが、私が今 Akka を愛している理由です :) メッセージが到着したらメッセージ内のユーザー ID が実際のターンのユーザー ID であることを確認し、送信されたアクションがテーブルの状態に基づいて受け入れられるものであることを確認します。たとえば、CHECK リクエストを受け取り、ユーザーが CALL/FOLD/RAISE しかできない場合、無効なアクションを返信するか、メッセージ全体を破棄します。

一般人を列に並ばせないでください。また、特に実際の通貨の取引を開始する場合は、常にセキュリティ ホールがないことを確認してください。

お役に立てれば...

編集:明確にしたいだけです。クライアントがアクションを実行するときはいつでも、アクションとテーブル ID、または必要な情報を送信するだけです。ユーザー ID やユーザー固有の情報を送信させないでください。「フロントエンド」サーバーは、リクエストが入ってくるソケットに基づいてユーザー ID を自動的に関連付ける必要があります。要求とともにユーザー情報を送信する場合は、ログに記録してからデータを破棄することをお勧めします。不正行為をしようとする人が好きではないという理由だけでログに記録します。予期しないデータが送信された場合は、おそらく彼らが行っていることです.

于 2012-10-16T22:31:03.277 に答える
2

おそらく私はアプリケーションをあまりよく理解していませんが、私の経験では、RabbitMQ は通常バックエンドで使用されます。たとえば、データベースとアプリケーション サーバー、およびその他の疎結合エンティティを含む分散システムを作成する場合です。メッセージ キューイングは、非同期アプリケーション設計の重要なツールであり、RabbitMQ によって各メッセージング キューを理論的に個別のプロセスに生成できるという事実により、非常にスケーラブルになります。

あなたの質問でほのめかしているのは、ユーザーのアクセス制御メカニズムのようです。これはシステムのフロントエンドで見られます。たとえば、メッセージをメッセージング キューに渡す前に、受信メッセージにフィルター メカニズムを適用します。ユーザーごとのレート制御による DoS 防止を検討することもできます。

乾杯!

于 2012-08-14T15:09:44.070 に答える