![]() |
О некоторых багах (раскрытие информации от 04.12.2017)
Доброго времени суток!
(Прошу прощения за не одно сообщение, но увы, форумный движек не мог обработать весь текст как один пост) Представляю вашему вниманию небольшой отчет, по обнаруженным мной и заботливо отправленным администрации проблемам. При нахождении уязвимостей их можно (зачеркнуто)продать и получить за это денег(/зачеркнуто) опубликовать, т.е. раскрыть с целью решения проблем. Зачем нужно раскрытие? Ответ приведу из вики: Цитата:
Итак, мной обнаружены проблемы и проверены в определенной степени. 4.12.2016 - мной было написано сообщение на почту админам (я наивно полагал, раз в информации у человека ![]() ![]() Письмо написано, и я полный оптимистичных ожиданий (зачеркнуто)"обновляю" каждую минуту почтовый ящик(/зачеркнуто) ожидал ответа. 15.12.2016 - пищу личное сообщение игроку ![]() ![]() ![]() В тот же день, буквально через пару часов получаю ответ: Цитата:
Ну что же, сказано - сделано. Повторил письмо администрации дописав еще пару моментов и вопросов по существу и указал свою почту. Стал ждать... (зачеркнуто)Смеркалось(/зачеркнуто) Наследующий день, обратился к игроку ![]() ![]() ![]() ![]() ![]() Что же, берем, просим "подписать NDA" и человек в работе. ![]() Дальнейшие дни до примерно 9 апреля 2017 года, наверно самые ужасные, пару раз в неделю, появлялся я и писал игроку ![]() ![]() Примерно 9.04.2017, может быть это был понедельник уже - я пишу игроку ![]() ![]() 16.04.2017 - неожиданно, в 21-42 игрок ![]() ![]() ![]() 24.04.2017 - первая публикация проблем и отчета о том как пытался добраться до админов. |
2 проблема:
Нет лимита на запрос картинок "капчей", по ссылке "http://haddan.ru/inner/img/gc.php" можно выкачивать картинки капчей в достаточно великом количестве при этом ограничения на количество картинок не получено, картинки выкачиваются для одного вопроса. Что это значит? По факту тут две стороны, первая очевидная, каждый запрос принуждает сервер генерировать картинку, а это все-таки нагрузка, т.е. теоретически можно почти все CPU камня забить генерацией картинок, а так же сильно нагнуть базу данных, где они сохраняются (в зависимости от базы, либо IO-дисков можно забить, нафигачив знатную очередь (привет лаги на ровном месте), либо "зажрать" всю оперативку (привет лаги и в худшем случае ребут), либо и то и то) Вторая менее очевидная, данный метод позволит загрузить много картинок себе, и на них уже обучать ИНС (искусственные нейронные сети). Что это значит для игрока? В первом случае - нет комфортной игре, ребуты, откаты и просто лаги. Во втором случае - создание правильного бота для игры, который мог бы профать. Как решать такой вопрос? Учитывая, что при всем желании, человек не сможет больше 1 картинки в секунду запрашивать (а учитывая сеть, то и больше), да и по большому счету, при неудачном вводе ответа на капчу, либо же нажатие кнопки "другая", генерится новый вопрос, т.е. перезапроса для этого вопроса в целом нет, то достаточно ограничить запрос таких картинок по времени, либо, что более правильно, генерировать каждый раз новый вопрос, это не позволит автоматически обучать ИНС. 3 проблема: Во время боя, может появиться вопрос на проверку человек это или нет (та же капча) данный момент обходится путем постановки деятельности на паузу примерно на 1,5 часа (ничего не делать вообще, просто бросить игру), после чего вопрос сам собой пропадает и можно дальше играть. Что это значит для игрока? По большому счету, для игрока это не известно и незаметно, это больше относится к ботоводам и прочим не сильно хорошим людям. Как решить такой вопрос? При выявлении подозрения на бота в базе у указанного игрока выставлять флаг на "требовать капчу" и не сбрасывать его до тех пор, пока человек не ответит, не важно сколько времени пройдет с момента появления запроса на капчу, дешево и сердито. |
4 проблема:
Капчи с вопросами малостойки, простыми алгоритмами весьма не плохо очищаются от шума и восстанавливаются буквы. После очистки буквы находятся (без особых проблем первое слово почти всегда успешно находит буквы, пример ![]() Вместе с тем, вопросы различаются первыми буквами и количеством слов, что упрощает анализ и уменьшает случаи при которых надо распознавать буквы. Что это значит для игрока? По большому счету, так же как и в пункте 3. Как решить такой вопрос? Тут нет однозначного ответа, появились всякие рекапчи, всякие капчи-игры и прочее, к сожалению, хорошо натренированная ИНС может решить почти любую неитерактивную капчу, т.е. (зачеркнуто)больше "экшона" больши пиу-пиу!(/зачеркнуто) решить такой вопрос не переделывая систему капчей не выйдет, т.о. привет ботоводам :) 5 проблема: Баг, связанный с тем, что можно призвать защитника не на свою сторону, признаюсь честно, баг порожден тем что я просто брал и призывал защитника, где в качестве цели был указан враг, благодаря такому багу, я получал практически "бесконечный" бой, потому что бил "врага который мертв" (данные вещи изменяются путем указания разных айди существ) Что это значит для игрока? По большому счету, так же как и в пункте 3, однако вам может повезти так же, что скрипт отработает некорректно (или вы сами через инструменты разработчика у браузера так сделаете) и вместо призыва защитника на свою сторону, вы его призовете на сторону врага, и он будет защищать не вас (грустно, да?) Как решить такой вопрос? Добавить проверку, "на какую сторону" призывается такой защитник. Кстати говоря, скорее всего такой же трюк может быть выполнен и для всяких иных призываемых существ, так что, да настанет эра боя человек vs мышь и куча ос! Муха-ха-ха-ха!:crazy: --- Дополнительные вопросы, что были во втором письме: - почему не используете более агрессивное кеширование, скриптов/картинок и прочего? - почему не используете пакетирование (объединение в один пакет нескольких запросов/ответов)? - онлайн до 300-х человек, и думаю около половины - пассивные игроки, что сидят медитируют, работают и прочее, почему ваш сервис не может держать 300 конектов, насколько вижу, не слишком велика должна быть нагрузка, в чем просадка? - у вас в БД содержится хренова туча "умерших игроков", у вас применяется архивирование и "урезание" базы? - какова фрагментация баз? - в таблицах используется принцип инсерт/делит или инсерт/дисейбл принцип? (удаление строк, когда данные не актуальны, или же проставление в соответствующим столбце выключено)? - какая СУБД используется? - как понимаю резервирования нет? |
1. У нас есть https://haddan.ru. Опасающимся - использовать его.
2. Это не грузит сервер от слова никак. Технология кэширования и все такое. Впрочем, во избежание активности от "активистов" воткнем проверку. 3. Посмотрим что там с целями, какой-то странный баг. Его правили уже раза 2. Но вообще он мало критичен P.S. Вообще, письмо товарища напомнило вот эту историю: https://xakep.ru/2006/12/16/35784/ |
Часовой пояс GMT +4, время: 17:58. |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd. Адаптация Архивариус & dukei