Pull to refresh

Comments 37

Хорошая статья! :)

pdf — обычно для того чтобы cloudflare корректно кешировал билд и бандли, еще можно юзать swf.

почему авторы где-то не закрыли ту или иную дырку? наверное тупо из-за нехватки времени и заняты остальной частью продукта :).
Спасибо, буду знать теперь про pdf и swf

Тоже пилил игру(сервер) и на первом месте стояла безопасность(не путать с паранойей). Видимо подход к выпуску продукта у всех разный.
На первом месте должна стоять миссия проекта. У них — денег заработать. А у вас в безопасности попрактиковаться.
Есть много аудит. компаний, анализ безопасности стоит дешево около 20-40 тыщ, но никто не покупает, потому что финансовых потерь от этих дыр у владельцев нет. А программисты.. ну да нынче такие программисты.
знаем мы этот аудит за 20 тысяч, скажут что надо ssl 2ой версии поставить, убрать пару старых шифров оттуда же и капчу на авторизацию — все, секурити окончено
ну вообще-то нет. Я являюсь руководителем проектов и часто по долгу службы вынужден сдавать работу, при этом один из этапов завершения проекта является аудит безопасности. Мне часто пишут очень не тривиальные штуки и вещи связанные с XSS и инъекциями. Все находят, пишут отчет обычно страниц на 20-30 какие вещи проверяют. Я рекламировать субподрядчиков не буду, как минимум потому что нет постоянных и работают с затягиванием сроков, но в целом услуга на рынке существует и дефицита особого нет
скрипткиддисы, прогоняющие сайты сканерами не в счет, максимум что они могут — вставить или кавычки в гет параметры)
хотя если это аудит сайта на готовом жвижке, то почему бы и не взять 20-30 тысяч и ничего не делать)
ssl 2ой версии поставить

Э?
просто чтобы вы представляли масштаб: Анализ юзабилити обойдется в 100-300 тыщ. за проект а в Юзабилити Лаб и во все 400-600 тыщ. Это рынок.
замечательная фраза про миссию :)
Я конечно извиняюсь, но может не стоит тестировать игры которые сделаны на коленке? Почему бы не протестировать действительно профессиональные продукты?
Это «игры вконтакте», у которых даже сервак зачастую является прослойкой между БД и клиентом, а сами игры ломаются модификацией памяти. О каком «анализе безопасности» может идти речь?
Что вы имеете ввиду под «прослойкой между БД и клиентом»? Т.е. есть вариант сервер<->БД<->клиент?)

Кстати о модификации памяти — в 3 из 4 игр была защита вида cryptValue=value^cryptoKey(XOR) и насколько я понял, это спасает от простого поиска «видимых пользователю» значений в памяти, так что прощай ArtMoney(поправьте, если ошибаюсь).
прослойкой между БД и клиентом

Думаю имелось в виду ситуация, когда сервак сейвит данные напрямую в БД вместо обработки информации о действиях, а вся логика реализована на клиенте.
>>Что вы имеете ввиду под «прослойкой между БД и клиентом»?

Если сказано что «A» стоит между «B» и «C», то, как ни странно, «A» находится между «B» и «С». Вы же изобразили всё в порядке расположения слов, проигнорировав слово, указывающее на другой порядок расположения этих объектов. Почему? Как ещё можно понять слово «между», кроме как «между»?

p.s. Даже XOR не катит, ибо среди детей находятся умельцы, которые находят такие вещи, и выкладывают маны с тем, какие адреса менять, или как находить (по какому-то другому значению, например, которое статично относительно поксоренного). Иногда доходит даже до хардварных бряков и изменения инструкций.
Дело в том, что сервер всегда будет прослойкой между БД и клиентом, а не «зачастую». Потому автор и спросил — есть разве другие варианты?
Как ни странно, другие варианты есть. Проявите фантазию. Как вариант, можно иметь конструкцию, в которой есть игровые сервера, которые получают информацию с сервера баз данных, а не из БД напрямую. Прослойкой же я назвал сервер, который совершает минимум манипуляций с данными (как вариант — собирает запрос из популярного для этих целей JSON), т.о. клиент абсолютно авторитарен.
Не нужно дерзить мне.
Мне не нужно знать, что вы подразумевали под прослойкой, этот вопрос задал автор, и получил хамский ответ.
Также не нужно притягивать за уши аналогии — ваши слова «сервак зачастую является прослойкой между БД и клиентом» в корне неверны, так как между БД и клиентом всегда будет сервер, обзывайте его как хотите — «сервер баз данных», «сервер, дающий из базы клиенту JSON».
Клиент-серверные приложения так потому и называются — там может не быть БД или быть много чего еще, но клиент и сервер всегда.
Пока от вас много воды и мало по делу. Что вы мне пытаетесь доказать? Ответьте, что может быть между БД и клиентом, как не сервер?
>>Что вы мне пытаетесь доказать?

Вы спрашиваете, я отвечаю, и никто никому ничего не доказывает.

>> Ответьте, что может быть между БД и клиентом, как не сервер?

Сервер, несколько серверов, другие клиенты.

>>Мне не нужно знать, что вы подразумевали под прослойкой, этот вопрос задал автор, и получил хамский ответ.

Вы спросили какие варианты есть — я назвал возможный, что вас не устраивает?
(по какому-то другому значению, например, которое статично относительно поксоренного)


Скрываемые значения вместо поля value хранятся как пара (pad, encryptedValue), откуда value рассчитывается перексориванием. Так вот, pad не обязан быть статичным, можешь его менять случайно хоть в каждом кадре (пересчитывая и encryptedValue).
еще есть клевый пакадж в ассет сторе от русского автора (Anti Cheat Toolkit) где есть практически полный фарш, в том числе и для защиты памяти.
Спасибо за отзыв! =)
Таким играм очень способствуют «быстроклепательные» сервисы к Unity, на подобии photon cloud. Когда ты по тутору и готовому комплекту из стора буквально за вечер, «ни о чем не думая», собираешь сетевую игру. В которой этот самый сервер, вовсе не сервер, а просто роутер передающий пакеты между клиентами. На которых и крутится вся логика. И как результат, игра ломается буквально пальцем.
С одной стороны, вроде как клево. Любой может на коленке собрать игру. А с другой имеем тонны треша и устойчивый миф (который некоторые компании постоянно культивируют), что «делать игры это очень просто». И вот уже простейший платформер или раннер требует не меньше гигабайта памяти и тормозит на 4-х ядрах по 2ГГц…
«Делать игры» — не так уж сложно. Так же просто, как и «писать программы», и «делать книги», да и что там, как и «писать тексты».
Делать — просто.
Делать хорошо — уже не так уж просто…
да, вот про хорошо согласен.
Сложновато даже со всеми упрощалками жизни типа юнити, фотон клауда, фотон чата, ассет стора, итд.
Я бы не сказал, что игры или сервисы плохие. Вы правильно заметили, что

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


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

Еще эти «быстроклепательные» сервисы к Unity позволяют быстро прототипировать игры. Однако есть практика прототип выкидывать в продакшн)

Сервисы призваны упростить жизнь разработчикам, но к делу нужно всегда подходить с умом.
фотон клауд отличная тема,
не надо ).
«ни о чем не думая» — это ж круто,
или принцип по жизни должен быть «в любой непонятной ситуации надо много подумать»? :)
Да никто вам не запрещает вообще не думать.
Большинство людей так и поступает.
Кстати, по исследваниям раличных учены, глупые люди, не думающие о том, что проиходит во круг, живут на много счастливее тех, кто задумываеся о том, что проиходит во круг)
Так что живите счастливо…
А я не говорю про вообще не думать.
Вон developer правильно говорит про миссию — миссия сделать хороший продукт или думать/делать упор на безопасность/whatever?

Если я могу не думать про сетевое решение и вместо этого потратить время чтобы игра получилась более качественная и интересная игроку — я лично рад :)
Как это не говорите? А вот это "«ни о чем не думая» — это ж круто" чьи слова?
Ну и если для вас «миссия, качество и интерес» = «толпа читеров и как следствие унылый геймлей с ботами»
То да, можете не думать про сетевое решение. Как я уже говорил, так действует большинство.
Нормальные разработчики, для которых все это не пустые слова. Да и вообще, просто нормальные, адекватные люди, не выключают мозг в процессе любой деятельности. И находят баланс между «закопаться в код на 10 лет» и «сделать интересный продукт для игроков».

Хотя всегда есть люди, которые предпочитают не думать над тем, что делают. И почему то считают, что если они тупо не будут думать над сетевым решением, то игра автоматом получится шедевром. Откуда такая логика берется неопнятно…
Ведь сетевое взаимодействие для многопользовательской игры это большая и неотъемлемая часть ее.
я не совсем понимаю как связан фотонклауд и унылый геймплей, если честно.

умеешь, хочешь и есть время-деньги — свое сетевое решение это ок.
нету каких-то составляющих — фотон клауд тоже ок.

для 99.9% команд — свои велосипеды фейл проекта ).

Интересно услышать мнения о способах защиты в ситуациях когда приложение предает на сервер не свою пару id-auth_key.
Если кто-то знает чужие viewer_id и auth_key это уже не излечимо. Разве что сменить app_secret, что в итоге должно привести к образованию нового auth_key для данного viewer_id в этом приложении(и вообще для всех игроков).
>2. В одной нашел App_Secret! Я не могу передать словами, насколько это эпично держать эту строку на клиенте…
А где вы посоветуете её держать? На сервере? Так клиент все-равно должен её получить каким то образом, чтобы собрать хеш-сумму, а перехватить пакеты от сервера, тоже как известно никакого труда не представляет.
App Secret нужен для проверки ключа авторизации, который передаётся при запуске приложения. Выдержка из документации:

auth_key вычисляется на сервере ВКонтакте следующим образом: auth_key = md5(api_id + '_' + viewer_id + '_' + api_secret). Чтобы не производить дополнительную авторизацию пользователя на своем сервере, всегда проверяйте ключ auth_key на правильность.


На клиенте App Secret не нужен.

Там же можно найти url для iframe, в котором можно узнать путь до .unity3d файла.

Что-то не получается найти. Подскажи, пожалуйста, как извлечь ссылку, по которой доступен .unity3d-файл (возможно, с другим расширением), и где браузер его кеширует.
Sign up to leave a comment.

Articles