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

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

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

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

СПОСОБ:
Клиент: Игрок Стив говорит дать Игроку Стиву один миллиард очков.
Сервер: Что ж, позвольте мне сначала проверить, может ли игрок Стив в данный момент набрать себе один миллиард очков ... ах. Он не такой. Пожалуйста, покажите это сообщение «Go Fsck Yourself, Cheater» игроку Стиву.

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

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

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

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

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

Похоже, что для одного компонента вашей игры потребуется регулирование запросов. По сути, вы отслеживаете, насколько быстро конкретный клиент получает доступ к вашему сайту, и начинаете замедлять свои ответы этому клиенту, когда его скорость превышает то, что вы считаете разумным. Существуют различные уровни этого, начиная с низкоуровневых 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. Добавить к их счету.

Здесь следует отметить несколько моментов.

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

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

Бен С очень хорошо подходит к тому, как вы разрабатываете протоколы связи между клиентом и сервером, например этот. Разрешение отправки значений баллов в качестве доверенных данных, как правило, будет плохой идеей. Желательно указать, что действие имело место, и позволить серверу определить, сколько очков должно быть назначено, если вообще. Но иногда это не удается. Рассмотрим сценарий гоночной игры. У клиента есть для отправки времени пользователя, и его нельзя абстрагировать в какой-либо другой вызов, такой как "completedLevelFour". Так что же теперь делать?

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

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

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

Удачи!

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