предотвращение читерства для браузерной игры xmlhttp/js/perl/php

Ничто не сможет помешать им сделать это, если вы реализуете свою игру так, как предлагаете.

Вам нужно реализовать игровую логику на сервере и назначать баллы только после того, как сервер подтвердит действие.

Например: на SO, когда кто-то голосует за ваш вопрос, это не отправляется как команда для повышения вашей репутации. Веб-приложение просто сообщает пользователю сервера X, что он проголосовал за вопрос Y. Затем сервер проверяет данные и присваивает баллы, если все проверено. (Не сказать, что это игра, но требуемая логика похожа.)

Краткая версия: вы не можете. Каждая часть данных, которую вы получаете от клиента (браузера), может быть вручную подделана кем-то, кто знает, что делает.

Вам нужно принципиально переосмыслить структуру приложения. Вам нужно кодировать серверную часть приложения таким образом, чтобы оно рассматривало каждую часть данных, поступающих от клиента, как набор грязной грязной лжи, пока оно не сможет доказать себе, что данные на самом деле правдоподобны. Вы должны избегать создания у сервера мысли «Если клиент говорит мне сделать это, очевидно, ему разрешено сказать мне сделать это».

НЕПРАВИЛЬНЫЙ ПУТЬ:
Клиент: Игрок Стив говорит дать Игроку Стиву тысячу очков.
Сервер: Хорошо!

ПРАВИЛЬНЫЙ СПОСОБ:
Клиент: Игрок Стив говорит дать Игроку Стиву один миллиард очков.
Сервер: Хорошо, позвольте мне сначала проверить, находится ли Игрок Стив в данный момент в время, позволенное дать себе одну тысячу очков ... ах. Это не так. Пожалуйста, покажите это сообщение «Иди к черту, мошенник» игроку Стиву.

Что касается сообщения о том, кто вошел в систему, это просто вопрос передачи клиенту файла cookie с чертовски почти невозможным для угадывания значением, которое вы отслеживаете на сервере, но я предполагаю, что вы знаете, как с этим бороться с управлением сессиями. :-) (А если нет, Google ждет.)

Логика игры (приложения) должна основываться на правиле не доверять ничему, что исходит от пользователя.

HTTP_REFERER можно подделать с помощью любого веб-клиента.

Токен с файлом cookie/сеансом.

Вы можете сделать ссылку динамической и изменить хэш в конце. Убедитесь, что хэш правильный с учетом этого периода времени.

Это будет различаться по сложности в зависимости от того, как часто вы разрешаете клики.

Несколько вещей, на которые следует обратить внимание.

Во-первых, запросы вашего сервера на что-то подобное должны быть POST, а не GET. Только GET-запросы должны быть идемпотентными, и несоблюдение этого фактически является нарушением протокола HTTP. спецификация.

Во-вторых, здесь вы видите классическую проблему доверия клиентов. Вы должны доверить клиенту отправку результатов или другой информации об игровом интервале на сервер, но вы не хотите, чтобы клиент отправлял незаконные данные. Предотвратить запрещенные действия легко, но гораздо сложнее предотвратить нечестную игру данных в разрешенном действии.

Ben S очень хорошо говорит о том, как вы разрабатываете протоколы связи между клиентом и сервером. Разрешить отправку значений точек в качестве доверенных данных, как правило, будет плохой идеей. Предпочтительно указать, что действие имело место, и позволить серверу выяснить, сколько очков должно быть назначено, если вообще. Но иногда вы не можете обойти это. Рассмотрим сценарий гоночной игры. Клиент должен отправить время пользователя, и его нельзя абстрагировать каким-либо другим вызовом, например «completedLevelFour». Так что вы будете делать теперь?

Токеновый подход, предложенный Ахметом и Дином, логичен, но не идеален. Во-первых, токен все еще должен быть передан клиенту, что означает, что он может быть обнаружен потенциальным злоумышленником и может быть использован злонамеренно. Кроме того, что, если ваш игровой API должен быть без сохранения состояния? Это означает, что аутентификация токена на основе сеанса отключена. А теперь вы попадаете в глубокие темные недра проблемы доверия клиентов.

Вы мало что можете сделать, чтобы сделать его на 100% надежным. Но вы можете сделать обман очень неудобным. Рассмотрим модель безопасности Facebook (каждый запрос API подписан). Это очень хорошо и требует, чтобы злоумышленник действительно покопался в коде на стороне вашего клиента, прежде чем он сможет понять, как подделать запрос.

Другой подход — повтор сервера. Как и в гоночной игре, вместо того, чтобы просто отправлять значение «время» на сервер, используйте контрольные точки, которые также записывают время и отправляют их все. Установите реалистичные минимумы для каждого интервала и проверьте на сервере, что все эти данные находятся в установленных границах.

Удачи!

Похоже, что одному компоненту вашей игры потребуется регулирование запросов. По сути, вы отслеживаете, насколько быстро конкретный клиент получает доступ к вашему сайту, и вы начинаете замедлять свои ответы этому клиенту, когда их скорость превышает то, что вы считаете разумным. Существуют различные уровни этого, начиная с низкоуровневых IP-фильтров и заканчивая тем, что вы обрабатываете на веб-сервере. Например, в веб-приложении Stackoverflow есть часть, которая улавливает то, что, по его мнению, слишком много правок слишком близко друг к другу. Он перенаправляет вас на капчу, на которую вам нужно ответить, если вы хотите продолжить.

Что касается других битов, вы должны проверить все входные данные не только на их форму (например, это число), но и на разумность значения (например, меньше 100 или что-то еще). Если вы застанете клиента за чем-то забавным, помните об этом. Если вы часто замечаете, что один и тот же клиент делает что-то смешное, вы можете заблокировать этого клиента.

Расширяя ответ Ахмета, каждый раз, когда они загружают страницу, генерируется случайный ключ. Сохраните ключ в сеансе пользователя. Добавьте случайный ключ к каждой ссылке, чтобы новая ссылка для получения этих 100 баллов была следующей:

increase_score.pl?amount=100&token=AF32Z90

При переходе по каждой ссылке убедитесь, что токен соответствует маркеру в сеансе, а затем создайте новый ключ и сохраните его в сеансе. Один новый случайный ключ каждый раз, когда они делают запрос.

Если они дают вам неправильный ключ, они пытаются перезагрузить страницу.

Я бы предложил сделать URL-адрес, специфичный для каждого действия. Что-то вроде:

/score/link_88_clicked/
/score/link_69_clicked/
/score/link_42_clicked/

Каждая из этих ссылок может делать две вещи:

1. Отметьте в сеансе, что ссылка была нажата, чтобы она больше не отслеживала эту ссылку.
2. Добавьте к их счету.

Если вы хотите, чтобы игра запускалась только на вашем сервере, вы также можете определить, откуда отправляется сигнал, в своем приеме получения и игнорировать все, что не исходит из вашего домена. Будет очень сложно вмешиваться в ваши коды, если вам нужно бежать со своего выделенного домена, чтобы отправить результаты.

Это также блокирует большинство трюков CheatEngine.