このソリューションはRESTfulで安全ですか？

Question

私たちの製品は新しいプレーヤーをサービスに登録し、それをAzure（.NETを使用しています）でホストすることを選択し、ステートレス（スケーラビリティのため）で比較的安全であることを望みました。

これは私が書いている最初のREST WSなので、それが確実な解決策であるかどうかについて、いくつかのフィードバックを得たいと思いました。

私たちのアプリについて知っておくべきいくつかの仮定：

ユーザーは、ユーザーにパスワードを要求することなく、匿名でサービスにログインします。
水平スケーリングを可能にするために、WSは完全にステートレスでなければなりません
サードパーティのスヌーピングを防ぐためにHTTPS（SSL）を使用して接続しています

編集：

ネイティブiOS/Androidデバイスを対象としています
私たちの主な懸念は、改ざんされていないクライアントのみがリクエストを送信できるようにすることです

そして抽象的な認証プロセス：

クライアントは単純なハッシュ（UDID：Timestamp）を作成し、タイムスタンプを使用して基本的なアルゴリズムで暗号化します（たとえば、秘密鍵はハッシュの2番目の文字ごとです）
クライアントはUDID、タイムスタンプ、ハッシュをサーバーに送信します
サーバーはハッシュを再構築し、ユーザーから送信された暗号化されたハッシュを復号化します
2つが等しい場合-実際にはクライアントから送信されたことがわかります（悪意のある送信者からではないことを願っています）

どんな入力/提案も素晴らしいでしょう-明らかに私がこの問題を扱っているのは初めてなので、私はそれを間違って設計したかもしれません。

ありがとう！

2回目の更新：

OAuthのセキュリティ仕様を読むと、クライアントとサーバーは秘密鍵を知っている必要があり、クライアントはユーザーのモバイルデバイス（ウェブアプリではなく）にローカルに保存されているため、私の質問に対する実際の回答はないようです。

OAuthセキュリティガイド（ http://hueniverse.com/oauth/guide/security/ ）から：

OAuthを実装する場合、対称または非対称の共有シークレットの制限を理解することが重要です。クライアントシークレット（またはプライベートキー）は、サーバーがクライアントの身元を確認するために使用されます。 WebサーバーなどのWebベースのクライアントの場合、クライアントの秘密（または秘密鍵）の機密を保持することは比較的簡単です。

ただし、クライアントがデスクトップアプリケーション、モバイルアプリケーション、またはブラウザーアプレット（Flash、Java、Silverlight）やスクリプト（JavaScript）などの他のクライアント側ソフトウェアである場合、クライアントの資格情報をアプリケーションの各コピーに含める必要があります。。これは、クライアントシークレット（またはプライベートキー）がアプリケーションと共に配布される必要があることを意味します。

これは、そのようなアプリケーション内でOAuthを使用することを妨げませんが、そのようなパブリックシークレットでサーバーが持つことができる信頼の量を制限します。シークレットは信頼できないため、サーバーはそのようなアプリケーションを次のように扱う必要があります。不明なエンティティであり、アプリケーションに関する統計情報の収集など、信頼のレベルを必要としないアクティビティにのみクライアントIDを使用します。一部のサーバーは、そのようなアプリケーションを禁止したり、さまざまなプロトコルや拡張機能を提供したりします。ただし、現時点では不明ですこの制限の解決策。

Usman Ismail · Accepted Answer

これは正接では多少ずれていますが、セキュリティの観点からは、クライアントにある秘密は秘密ではありません。あなたはあなたの質問にそれを述べます。

私たちの主な関心事は、改ざんされていないクライアントのみがリクエストを送信できるようにすることです。

ゲーム業界で働いてきた人として、これは失われた原因です。任意の要求を送信できる十分な値がある場合、ユーザーはそれらの要求を送信する方法を理解します。信頼できるクライアントからのリクエストかどうかを判断できるとは限りません。ここに私の経験からいくつかのヒントがあります。

サーバーにゲームの状態の正規のコピーを保持する
各ユーザーが行うことができる状態の変化を把握し、サーバー側で違反をチェックします。
スクリプトをキャッチするためにユーザーが通貨/アイテムをレベルアップまたは獲得する速度にレート制限があります。
詐欺師が悲しむことができない場合、他のプレイヤーはそれらを禁止しません。詐欺師の多くは消費者でもあります。
つまり、詐欺師が友人に明らかになるように、詐欺師を社会的に管理します。あなたが一致するロジックを持つことができるならば、詐欺師は彼らの友人と対戦することから削除されます。

guysherman · Answer

RESTに関する重要な点は、httpの固有の機能を使用していることです。

GET：単にデータを取得するため
POST：新しいデータポイントを挿入するため
PUT：データポイントの更新用
DELETE：データポイントを削除します

他のガイダンスのいくつかは、あなたのURLは直感的でなければならないということです。つまり、プレーヤーのURLがhttp://example.com/api/player次に、スコアの最後の履歴を公開するための賢明な方法はhttp://example.com/api/player/1/scores（プレーヤーID 1のスコア）。

セキュリティに関しては、OAuth仕様から読み取ったものは非常に当てはまります...他の人が手に入れることができるバイナリにある種の秘密鍵を埋め込む場合は、それが完全に秘密であると仮定します。コードに何らかの秘密鍵がある場合は、期限切れになるように設定し、更新をプッシュして変更することをお勧めします。必ず、暗号化などでそれを保護する機会がありますが、ハッキングされた場合は簡単に無効にすることができます。実際には、Twitterなども同じ問題を抱えており、公式アプリの秘密鍵が時々発見され、投稿されます。インターネット上で、彼らは彼らのアプリを更新する必要があります。