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

私たちの製品は私たちのサービスに新しいプレーヤーを登録し、それをAzure（私たちは.NETを使用しています）でホストすることを選択しました。

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

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

1. ユーザーは、ユーザーのパスワードを要求せずに、匿名でサービスにログインします
2. 水平スケーリングを可能にするには、WSは完全にステートレスである必要があります
3. サードパーティのスヌーピングを防ぐためにHTTPS（SSL）を使用して接続しています

編集：

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

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

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

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

ありがとう！

2回目の更新：

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

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

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

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

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

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

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

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

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

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

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

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

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