Скрыть запросы POST / GET - Flash & PHP

Question

Я сейчас работаю с другом над флеш игрой.Он хочет вставить результаты в базу данных, когда игрок заканчивает игру.Он использует этот урок для вспышки - http://www.tizag.com/flashTutorial/flashforms.php.SWF, который он сделал, прекрасно работает - он публикует данные.Проблема в том, что я вижу запрос от firebug.Это открывает еще одну проблему - любой продвинутый пользователь может вставить свой собственный счет, не играя в игру ...

Так есть ли способ скрыть запросы, сделанные из флэш-игры?Каков будет правильный подход к этой проблеме?

Answer 1

Нет, фактически невозможно скрыть сделанные запросы. Это невозможно. Мало того, что firebug или Live HTTP-заголовки могут перехватывать его, если он запускается в веб-браузере, я могу загрузить Wireshark, найти весь входящий и исходящий трафик и проанализировать его. То, что вам нужно, это метод шифрования или отключения. Например, возьмите их оценку, base64_encode (), затем возьмите текущее время, измените его (и, возможно, добавьте ключ в конец), а затем возьмите MD5 этого. Отправьте все три части информации на сервер, если время превышает 5 секунд, они могли бы отредактировать запрос и отправить ложный. Проверьте правильность времени, поменяв его местами (а затем добавив к нему ключ, если вы его использовали), и взяв MD5, и убедитесь, что они совпадают. Конечно, вы можете запустить какой-нибудь сложный алгоритм шифрования, но в итоге это бессмысленно:

Нет надежного способа борьбы с этим. Я работал в области обратного инжиниринга. Я могу сказать вам, что я могу редактировать любое значение в любой флеш игре. Поэтому, хотя представление результатов может быть несколько безопасным, я могу декомпилировать вашу игру, посмотреть на код и посмотреть, что вы сделали, чтобы отрицать представление результатов. Или, что еще проще, я могу просто отредактировать значение, которое удерживает счет менее чем за 60 секунд. Adobe Flash Player хранит переменные в памяти, и в этом заключается их слабость, я могу легко редактировать эти переменные и значения в памяти.

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

Answer 2

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

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

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

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

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

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

Отчасти это бесполезное беспокойство, если ваша игра достаточно мала, чтобы не привлекать много внимания.Это абсолютная безопасность: создайте игру, в которую никто не хочет играть, и поэтому никто не потрудится взломать.;)

Все, что сказано / в итоге, вот несколько вещей, которые вы можете сделать:

1. Сохранять высокий балл в нескольких переменных, шифруя фактическое содержимое в памяти.То есть попробуйте сбросить читер, который смотрит на память, пытаясь найти счет.

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

3. Подтвердите, что оценка имеет смысл, учитывая количество сыгранного времени.,Вы можете периодически сообщать счет на сервер каждые пять секунд и т. Д.

4. Сделать клиента настолько глупым, насколько это возможно ... сделать сервер авторитетным.

5. Если кто-то публикует абсолютно неверный счет, забаньте этот IP-адрес и / или учетную запись пользователя.

6. Молитесь, чтобы ваша игра не пользовалась большой популярностью среди хакеров.

Answer 3

Помимо шифрования трафика, вы можете подумать о добавлении некоторых «контрольных точек» - время от времени отправлять некоторый статус с клиента на сервер.Это может привести к некоторым задержкам, но позволит отслеживать состояние клиента на сервере.Чтобы сделать его полностью (ну, почти полностью) безопасным, все решения о действиях каждого пользователя должны приниматься на сервере.Это не будет работать против сложных ботов, которые имитируют действия пользователя, хотя это будет доказательством против "отправителей счета".

Answer 4

Простой способ решения этой проблемы - передать в качестве дополнительного аргумента (при публикации на страницу, сохраняющего в db), который может быть, например, md5 счета плюс секретная строка.Например, если вы отправляете в качестве данных POST score:12345, вы можете сделать что-то вроде score:12345&key:119c8901b84be882530d60a45539705f

В моем примере я вычислил md5 12345_secret.Когда вы получаете свои данные на сервере, вы сохраняете их, только если md5(score+'_secret') == key

Answer 5

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

Вот некоторая информация, основанная на AES, которая выглядит мне правильно: http://www.lostinactionscript.com/blog/index.php/2009/11/29/aes-cryptography-for-actionscript-php/

PS: конечноЕсть намного более сложные решения, включающие алгоритм определения следующего общего ключа на основе некоторого теста, но это кажется слишком много для веб-игры.

Answer 6

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