スクロールレベルのあるスペースシューターを想像してみてください。悪意のあるプレーヤーがゲームを自分たちの利益のために変更するのを防ぐためにどのような方法がありますか？サーバー側を制限するのが難しい彼ができることは、自動照準、可視領域の外側の覗き見、スピードハッキングなどです。
これを防ぐにはどのような方法がありますか？サーバーは任意の言語であり、クライアントはWebSocketを介して接続されていると想定します。
コードは100％ハッキング可能であると常に想定してください。（不正行為の目的で）完全に書き直されたクライアントが不正行為をしないようにする方法を考えてください。これらは、安全なゲームプロトコルを作成する方法、サーバー側の検出などです。
サーバーは王様です。クライアントはハッキング可能です。
あなたがしたいことはあなたのwebsocketで2つのことです。
サーバーにゲームアクションを送信し、サーバーからゲームの状態を受信します。
ゲームの状態をレンダリングします。そして、サーバーに入力を送信します。
コードを縮小してこれらの問題を解決することはできません。クライアントのコードは、入力と表示出力を処理するためだけにあります。すべてのロジックはサーバー上で実行する必要があります。
サーバー側の検証を作成するだけです。唯一のことは、複雑さのために、ゲーム入力を検証してからフォーム入力を検証するのが非常に難しいということです。これは、フォームを安全にするために行うのとまったく同じことです。
ただし、「入力は有効」の検出には十分注意する必要があります。あなたはあなたのゲームから高度に熟練したプレーヤーを蹴ったり禁止したりしたくありません。ボットの検出が緩すぎることと、ボットの検出が厳しすぎることのバランスをとることは非常に困難です。ボット検出の領域全体は、全体的に非常に困難です。たとえば、Quakeには自動照準検出機能があり、合法的に熟練したプレーヤーをその日に蹴り返しました。
ボットがWebSocketに接続するのを阻止することに関しては、セキュリティを強化するために、マルチプレイヤーゲームに個別のHTTPまたはHTTPS検証チャネルを直接設定します。複数のHttp/https / wsチャネルを使用して、クライアントが「公式」であり、何らかの形のハンドシェイクとして機能していることを検証します。これにより、wsへの直接接続が難しくなります。
例：
単純なマルチプレイヤーゲームを考えてみてください。2Dルームベースのレーシングゲーム。最大n人のユーザーがフラットな2Dプラットフォーマーマップにアクセスし、AからBに移動するために競争します。
議論のために、HTTPSチャネルを介して複雑な認証が行われ、ユーザーがWebSocketチャネルに直接アクセスできず、ブラウザーを経由することを余儀なくされる、絶対に安全なシステムがあるとします。認証を処理するChrome拡張機能があり、ユーザーにそれを使用するように強制する場合があります。これにより、問題のあるドメインが減少します。
サーバーは、クライアントが画面をレンダリングするために必要なすべてのビジュアルデータを送信します。このデータを隠すことはできません。何をしようとしても、愚かなハッカーはコードを取得し、デバッガーでコードを編集する際に速度を落とすことができます。彼はあなたに認証全体を実行させますが、あなたが書いたJavaScriptが彼の実行を阻止するのを阻止するために、彼にできることは何もありません。それで達成できるのは、WebSocketにアクセスするのに十分なスキルを持つハッカーの数を制限することだけです。
これで、ハッカーはWebSocketをクロームサンドボックスに入れました。彼は入力を見ます。もちろん、あなたのレースコースは動的かつユニークに生成されます。あなたがそれらの設定された量を持っていれば、ハッカーは最適なレースルートを事前に設計することができます。このマップを視覚化するために送信するデータは、ゲームとの人間の相互作用よりも速くレンダリングでき、レーシングゲームに勝つための最適な動きを計算してサーバーに送信できます。
マップデータに反応が速すぎるプレーヤーを禁止してボットと呼ぶ場合、ハッカーはこれを調整して遅延を追加します。完璧にプレイしすぎるプレイヤーを禁止しようとすると、ハッカーはこれを調整し、ランダムな数字を使用して完璧とは言えないプレイをします。アルゴリズムボットのみが該当するトラップをマップに配置する場合は、試行錯誤または機械学習アルゴリズムを通じて、それらについて学習することでトラップを回避できます。絶対に安全にするためにできることは何もありません。
ハッカーを絶対に回避するための選択肢は1つだけです。それは、ハッキングされない独自のブラウザを構築することです。ブラウザにセキュリティメカニズムを組み込みます。ユーザーが実行時にリアルタイムでJavaScriptを編集することを許可しないでください。
サーバー側には、次の2つのオプションがあります。
1）完全なサーバーサイドゲーム
各クライアントは、「アクション」をサーバーに送信します。サーバーはそれらを実行し、関連するデータを送り返します。たとえば、船が北に移動したい場合、サーバーは新しい位置を計算して送り返します。サーバーは、表示されている船のリスト（maphacksを解決する）なども送信します。
2）完全なクライアントサイドゲーム
各クライアントは引き続きアクションをサーバーに送信します。ただし、サーバーの作業負荷を軽減するために、サーバーはアクションを実行せず、他のすべてのクライアントにアクションを転送します。その後、クライアントはすべてのアクションを同時に解決します。結果として、各クライアントは同じゲームで終わるはずです。定期的に、各クライアントは絶対データ（船の位置など）をサーバーに送信し、サーバーはすべてのクライアントデータが同一であるかどうかを確認します。そうしないと、ゲームが同期しておらず、誰かがハッキングしている必要があります。
2番目の方法の欠点は、一部のハックが検出されないままになることです。たとえば、maphackです。詐欺師はコードを挿入してすべてを見ることができますが、それでも通常は見ることができるはずのデータのみをサーバーに送信します。
-
クライアント側には、1つのオプションがあります。ゲームコードをスキャンして、何かが変更されているかどうかを確認するjavascriptコンポーネント（たとえば、表示されていないが異なる検証データをサーバーに送信するオブジェクトをレンダリングするようにコードが変更されている）。
明らかに、ハッカーはこのコンポーネントを簡単に無効にすることができます。これを修正するには、クライアントにサーバーからコンポーネントを定期的にリロードするように強制できます（サーバーは、スクリプトファイルがユーザーから定期的に要求されたかどうかを確認できます）。これにより、新しい問題が発生します。ハッカーはAJAXを介してコンポーネントを定期的に要求しますが、実行できません。これを回避するには、コンポーネントにそれ自体を再ダウンロードさせますが、それ自体のバージョンを少し変更します。
例：コンポーネントをyoursite / cheatdetect.js？control=5に配置します。サーバーはわずかに変更されたcheatdetect.jsを生成するため、次の反復でcheatdetect.js？control = 22（たとえば）をダウンロードする必要があります。制御メカニズムが十分に複雑な場合、ハッカーは次に要求する制御番号を予測できず、ゲームを続行するにはcheatdetect.jsを実行する必要があります。
クライアント側のコードに触れる必要はありません。Websocketプロトコルをスニッフィングして実装し、人間のプレーヤーになりすました小さなエージェントを作成するだけです。
更新：問題にはいくつかの部分があり、頭の中で答えはありませんが、次の質問を念頭に置いてさまざまなオプションを評価できます。
Sure many of the roadblocks you throw up can be side-stepped, but what is the cost to the player and you? See "Attrition warfare".
誰かがJSを変更したり、GreaseMonkeyスクリプトを記述したりするのを防ぐために実際にできることは何もありません。ただし、スクリプトを縮小し、コードを可能な限り不可解にすることで、彼らを困難にすることができます。たぶん、攻撃者を追い払うために使用されるだけの偽のメソッドや変数を投入することさえあります。しかし、十分な時間があれば、これらのメソッドはどれも完全に確実なものではありません。コードがクライアントに渡されると、それはもはやあなたのものではなくなるからです。
これを実装することを考えることができる唯一の方法は、クライアントとして機能するようにJavascriptを変更し、そのクライアントから送信されたデータを検証する中央サーバーメカニズムを設計することです。これはおそらく実装するのに大きな変更であり、プロジェクトをより複雑にする可能性があります。ただし、前述のように、アプリケーションが完全にクライアント上で実行されている場合、クライアントはスクリプトを使用してほとんど何でも実行できます。信頼できるマシンを使用して検証を処理するためにそれを保護する唯一の方法。
実装できる他のいくつかのメソッド：
ミニファイとAJAXを組み合わせて使用します。すべての関数とデータがページにロードされていない場合、チートするのはより困難になります。
一方、モッディングはIdSoftwareのような企業にとって非常に有益なツールであることが判明しました。おそらく、システムの変更を許可することで、コミュニティ全体にとってゲームがはるかに楽しくなる可能性があります。
クライアントに公開されたコードを可能な限り難読化します。さらに、いくつかの魔法を使用します。
ブラウザでJavaScriptを編集して、機能させることができます。サーバーに確認するために電話をかけることを提案する人もいます。したがって、サーバーを呼び出した後、サーバーで検証されます。検証されると、クライアント側に到達してアクションを実行します。しかし、これでも絶対確実ではないと思います。
たとえば、。基本的なログインアクションの場合：サーバーへの呼び出し中にAngularで、バックエンドはユーザー名とpwdを検証し、検証された場合、クライアントに戻って、ユーザーがAngularを使用してログインできるようにします。
Angularを使用してログインすると言うと、ユーザーオブジェクトなどのCookieに保存されます。ただし、ユーザーはバックエンドを呼び出しているJSコードを削除し、TRUE（必要な場合）を返し、ユーザーオブジェクト（ダミー）をCookieやその他のオブジェクト（必要なもの）に挿入してログインできます。それは非常に難しいことですが、実行可能です。多くのシナリオでは、コードの編集/ハッキングに数時間かかる場合でも、これは望ましくありません。
これは、JSファイルがページごとにリロードされないシングルページアプリケーションで可能です。ハッキングされる可能性を軽減するために、縮小されたコードを使用できます。そして、このようなアクションがバックエンドで行われる場合（Djangoでのログインなど）、はるかに安全だと思います。
私が間違っている場合は訂正してください。