ブラウザベースのゲームで、何らかのアクションを完了するとしましょう (簡単にするために、誰かがスコアを 100 上げるリンクをクリックするとします)。このリンクをクリックすると、たとえば、increase_score.pl?amount=100単純に送信する誰かからどのような防止策があるかなどの URL があります。このコマンドを実行するように Web サーバーに要求します。
私はチェックすることHTTP_REFERERを知っていますが、人々がそれを回避できることを知っています（正確にはわかりません）。2番目のオプションをチェックするいくつかの境界以外は、ちょっと困惑しています。誰も似たような問題を経験したことがありますか? ソリューション？
あなたが提案した方法でゲームを実装すれば、彼らがこれを行うのを止めることはできません。
サーバーにゲーム ロジックを実装し、サーバーがアクションを検証したときにのみポイントを割り当てる必要があります。
例: SO で誰かがあなたの質問に賛成票を投じたとき、これはあなたの評判を上げるためのコマンドとして送信されません。Web アプリは、サーバー ユーザー X が質問 Y に賛成票を投じたことを伝えるだけです。次に、サーバーはデータを検証し、すべてがチェックアウトされた場合にポイントを割り当てます。(SO がゲームであるとは言いませんが、必要なロジックは似ています。)
短いバージョン: できません。クライアント (ブラウザ) から取得するすべてのデータは、何をしているのかを知っている誰かによって手動で偽装される可能性があります。
アプリケーションの構造を根本的に考え直す必要があります。アプリのサーバー側は、データが実際にもっともらしいことを証明できるまで、クライアントからのすべてのデータを汚い汚い嘘のパックとして扱うようにコーディングする必要があります。サーバーに、「クライアントがこれを行うように指示した場合、これを行うように指示することは明らかに許可されている」という考え方を与えることは避ける必要があります。
間違った方法:
クライアント: プレイヤー スティーブは、プレイヤー スティーブに 1 兆ポイントを与えるように言います。
サーバー: わかりました！
正しい方法:
クライアント: スティーブ プレイヤーは、スティーブ プレイヤーに 1 兆ポイントを与えるように言います。
サーバー: ええと、最初にプレイヤー スティーブが現時点で 1 兆ポイントを自分に付与できるかどうかを確認させてください...ああ。彼は違います。この「Go Fsck Yourself, Cheater」メッセージをプレイヤー Steve に表示してください。
誰がログインしているかを知ることに関しては、サーバー上で追跡しているほぼ不可能な値を持つ Cookie をクライアントに渡すという単純な問題です。セッション管理で。:-) (そうでない場合は、Google がお待ちしています。 )
ゲーム（アプリケーション）のロジックは、ユーザーから来るものは何も信用しないというルールに基づいている必要があります。
HTTP_REFERER は、任意の Web クライアントでスプーフィングできます。
Cookie/セッションを含むトークン。
ここで注意すべき点がいくつかあります。
まず、このようなものに対するサーバー リクエストは、GET ではなく POST である必要があります。GET リクエストのみが冪等であるべきであり、そうしないと実際には HTTP 仕様に違反します。
第二に、ここで見ているのは、古典的なClient Trust Problemです。クライアントがスコアやその他のゲーム間隔情報をサーバーに送信することを信頼する必要がありますが、クライアントが不正なデータを送信することは望ましくありません。許可されていないアクションを防止するのは簡単ですが、許可されたアクションで不正なデータを防止することは、はるかに問題です。
Ben S は、このようなクライアントとサーバー間の通信プロトコルをどのように設計するかについて、優れた点を指摘しています。ポイント値を信頼できるデータとして送信できるようにすることは、一般的に悪い考えです。アクションが発生したことを示し、サーバーに割り当てる必要がある場合はいくつのポイントを割り当てるべきかを判断させることをお勧めします。しかし、それを回避できない場合もあります。レーシング ゲームのシナリオを考えてみましょう。クライアントはユーザーの時間を送信する必要があり、「completedLevelFour」などの他の呼び出しに抽象化することはできません。それで、あなたは今何をしますか？
Ahmet と Dean が提案するトークン アプローチは適切ですが、完全ではありません。まず、トークンをクライアントに送信する必要があります。つまり、潜在的な攻撃者によってトークンが発見され、悪意を持って使用される可能性があります。また、ゲーム API をステートレスにする必要がある場合はどうすればよいでしょうか? これは、セッションベースのトークン認証が廃止されたことを意味します。そして今、あなたはクライアントの信頼問題の深く暗い腸に入ります.
100% 誰にでもできるようにするためにできることはほとんどありません。しかし、チートするのは非常に不便です。Facebook のセキュリティ モデルを考えてみましょう (すべての API 要求は署名されています)。これは非常に優れており、攻撃者がリクエストを偽装する方法を理解する前に、クライアント側のコードを実際に掘り下げる必要があります。
もう 1 つのアプローチは、サーバー リプレイです。レーシング ゲームのように、「時間」の値をサーバーに送信するだけでなく、時間も記録してすべて送信するチェックポイントを設定します。各間隔の現実的な最小値を確立し、このすべてのデータが確立された境界内にあることをサーバーで確認します。
幸運を！
リンクを動的にして、最後に変更されたハッシュを持つことができます。その期間を考慮して、ハッシュが正しいことを確認します。
これは、クリックを許可する頻度によって複雑さが異なります。
ゲームの 1 つのコンポーネントでリクエスト スロットリングが必要になるようです。基本的に、特定のクライアントがサイトにアクセスする速度を追跡し、その速度が妥当と思われる速度を超えると、そのクライアントへの応答を遅くし始めます。低レベルの IP フィルターから始まり、Web サーバーで処理するものまで、さまざまなレベルがあります。たとえば、Stackoverflow の Web アプリケーションには、あまりにも多くの編集が近づきすぎていると思われるものをキャッチするビットがあります。続行する場合は、応答する必要があるキャプチャにリダイレクトされます。
他のビットに関しては、すべての入力をその形式 (例: 数値) だけでなく、値が妥当であること (例: 100 未満など) も検証する必要があります。クライアントが面白いことをしているのを見つけたら、それを思い出してください。同じクライアントが頻繁に面白いことをしているのを見つけたら、そのクライアントを禁止できます。
ゲームをサーバー上でのみ実行したい場合は、受信トリックで信号がどこから送信されたかを検出し、ドメインから送信されていないものを無視することもできます。スコアを送信するために専用ドメインから実行する必要がある場合、コードを改ざんするのは非常に困難です。
これにより、CheatEngineのトリックのほとんどがブロックされます。
Ahmet の応答を拡張すると、ページが読み込まれるたびにランダム キーが生成されます。キーをユーザー セッションに保存します。これらの 100 ポイントを取得するための新しいリンクが次のようになるように、すべてのリンクにランダム キーを追加します。
increase_score.pl?amount=100&token=AF32Z90
すべてのリンクがクリックされたら、トークンがセッション内のトークンと一致することを確認してから、新しいキーを作成してセッションに保存します。リクエストを行うたびに 1 つの新しいランダム キー。
彼らがあなたに間違ったキーを与えた場合、彼らはページをリロードしようとしています.
各アクションに固有の URL を作成することをお勧めします。次のようなもの：
/score/link_88_clicked/
/score/link_69_clicked/
/score/link_42_clicked/
これらの各リンクは、次の 2 つのことを行うことができます。