сегодня в 13:11
Продукт без тестирования
Всем привет, друзья. Немного детектива вам в ленту.
Не так давно я загуглился и наткнулся на один интересный проект в интернете. Правда, интересен этот проект оказался не идеей или функциональностью, а ходом разработки. Проект разрабатывается уже более года, все это время над проектом работают программисты, вкладываются деньги в рекламу. Проект даже насчитывает несколько десятков активных пользователей. Мой интерес данный проект привлек тем, что он не проходил какое-либо тестирование функционала.
В данной статье хочу рассказать о том, к чему приводит отказ от тестирования продукта. Думаю, материал будет полезен тем, кто начинает работать над стартапом; людям, занимающимися организацией проектов, дабы не совершать ошибки при выборе команды разработчиков и методов работы над проектом; и всем тем, кому интересно узнать, как проект смог прожить более года и как обычный юзер может потерять деньги просто потому, что мы часто доверяем сайтам, подозревая их только в мошенничестве, не задумываясь, что сайт может быть просто некачественно разработан.
Сразу стоит оговориться: к проекту или людям с проекта я не имею никакого отношения. До написания статьи я связался с CEO проекта и предложил ему обсудить уязвимости, которые удалось мне найти, а также решение этих проблем.
О проекте
Сам проект не столь интересен, как способ его разработки. Ребята копируют одну довольно известную биржу игровых ценностей ставя на более низкие проценты комиссии проекта (на момент 19.06.2021 комиссия проекта составляет 0%, однако, как выяснилось позднее, обычный пользователь все равно платит комиссию платежки как в случае оплаты товара, так и в случае вывода средств с платформы).
Проект на рынке уже около 6 месяцев, в общем чате на платформе раз в 6 часов появляется объявление о продаже того или иного товара. На платформе лежит около 500 товаров (в среднем по 5 товаров на игру).
Разработкой занималось несколько команд в разное время. Только последней командой проект разрабатывается уже более года. Большую часть проекта создала последняя команда из 7 человек, в последствии сокращенной до 4 человек.
Стоит отметить, что по словам разработчиков проекта, тестирование не проводилось из-за невозможности договориться с основателем. Команда разработки работала на freelance основе, то есть поблочно. При этом основатель категорически был против финансировать тестирование проекта, считая это пустой тратой времени.
P.S. Перед написанием статьи я вбил на GitHub в поиске GameValues - таким образом я вышел на разработчика проекта (ник на GitHub совпадал с ником в telegram). Через него уже получил остальных ребят. Вся информация, представленная выше, с уст разработчиков или основателя проекта.
С основателем проекта мне удалось связаться через сайт биржи. Контакты получил оставив обратную связь.
Проводим собственное тестирование. Начало пути
Думаю, пора перейти к самому сладкому.
В начале я просто зарегистрировался на сайте, потыкал функциональность и уже заметил интересный момент. Чат на главной странице отображает только первые 20-25 сообщений при этом со смешным ограничением от флуда - необходимо подождать 5 секунд перед тем, как написать в чат сообщение. Чат работает на вебсокетах. Залезаем в консоль и получаем всю необходимую информацию для скрипта флуда чата.
Из консоли узнаем url адрес и формат сообщений. Так как вся наша защита - это ожидание в 5 секунд - все, что нам необходимо сделать - это поставить таймер в скрипте на 5 секунд. С задачей зафлудить чат справиться и ноутбук под рукой. Что же делать с блокированием пользователя админами? Думаю, к этому вернемся позднее.
Хотя стоит отметить, что, несмотря на жалобы пользователей, меня так и не заблокировали - спишем это на недостаток функционала администраторов.
Итак, вот злоумышленник или конкурент испортил первое впечатление пользователей о платформе.
Искал медь, а нашел золото
Идем далее. При тестировании продукта стоит проверять и абсурдные идеи: зачастую разработчики упускают столь простые моменты. Особенно когда разработка идет без тестирования. Я решил проверить наличие документации в открытом доступе. Из той же консоли вытаскиваем первый попавшийся url, на который делает запрос сайт https://transaction.gamevalues1.ru. Проверяем на нем самый дефолтный путь - /swagger-ui/ (проверял также /swagger-ui/index.html, /swagger-ui.html, /api-docs и с добавлением /v{цифра}/). И неожиданно натыкаемся на золотую жилу.
Таким образом находим документации к следующим сервисам:
Сервис, отвечающий за оплату товаров и вывод средств с платформы https://transaction.gamevalues1.ru/swagger-ui/
Сервис, отвечающий за хранящуюся информацию об играх и товарах на сайте https://game.gamevalues1.ru/swagger-ui.html
Сервис, отвечающий за регистрацию, авторизацию пользователей (в том числе администраторов) https://auth.gamevalues1.ru/v3/api-docs
Сервис, отвечающий за хранение конфиденциальной информации о пользователе https://profilerus.gamevalues1.ru/swagger-ui/index.html
То же самое, что и выше https://profile.gamevalues1.ru/swagger-ui/index.html
Сервис, отвечающий за хранение сообщений на портале https://chat.gamevalues1.ru/v3/api-docs
Не удалось найти документацию к следующим сервисам: https://proxy.gamevalues1.ru/, https://online.gamevalues1.ru/ . Думаю, не большая потеря.
Хочу обратить внимание, что документацией я практически не пользовался: большую часть информации можно взять из консоли разработчика изучив запросы, которые отправляет сайт.
Изучаем документацию
Из документации к сервису авторизации узнаем, что при регистрации нового пользователя нет проверки капчи (она есть на сайте).
Получаем простое дополнение к скриптам для генерации нового пользователя при блокировке старого.
Смотрим в сторону наполнения сайта
Сильно в документацию не стал копать. В доке по товарам находим способ добавлять неограниченное количество товаров в игру.
Пишем простенький скрипт на python, чтобы проверить нет ли ограничений на количество товаров на 1 пользователя. Токен вытаскиваем из консоли разработчика, структуру данных подсматриваем ту, которую отправляет сайт.
import requests
headers = {
'Authorization': 'Bearer ...',
'Content-Type': 'application/json'
}
# data
s = """{"count": 1,"description": "1","gameId": "5fa14541600e1d790eff6cb2","date": null,"lang": "rus","name": "flud","minCount": 1,"priceWithoutCommission": 2,"priceWithCommission": 2,"available": true,"productTypeId": "5fa14541600e1d790eff6cb1","server": "Aion-Classic.net 1.2","userId": 3519,"valuesContainer": {"values": {"rangeProperties": {},"listProperties": {"Сторона": "Асмодиане"}}}}"""
while True:
r = requests.post(
'https://game.gamevalues1.ru/product',
data=s.encode('utf-8'),
headers=headers)
print(r)
Запускаем, ждем пару минут и убеждаемся, что зафлудить систему просто.
Из той же самой документации получаем запрос на получение всех игр платформы - и вот мы уже добавляем товары во все игры, во все категории. Справимся и на своем ноутбуке.
Все, что делали до этого - это весело и может сделать так, что системой не будет возможно пользоваться. Флуд в чат и в товары, в случае бана создание нового аккаунта. Для этого даже не надо будет находиться около ноутбука - все будет происходить автоматически. Но это пока не подвергает опасности обычного пользователя.
Смотрим систему работы с финансами
Перейдем к системе оплаты товаров и вывода средств. Как удобно, когда все разделено на логические блоки :)
Залезаем в консоль разработчика. Проследив за запросами, получаем примерную логику работы системы: при оплате происходит запрос на бэк, на бэке создается новая transaction, к которой генерируется ссылка на оплату (оплата происходит через сторонний эквайринг, в ссылке указывается id сущности transaction). И подмечаем интересную вещь - при повторном запросе на создание сделки генерируется новая transaction, но старая не удаляется. Вероятнее всего это сделано на случай, если человек перешел по 2 ссылкам и оплатил более раннюю - эквайринг должен уведомить по какой transaction произошла оплата. Зачем каждый раз создавать новую transaction - сложно понять, наверное есть способ изменения некоторых параметров транзакции (количества покупаемого товара и прочее).
Из интересного подмечаем, что при переходе на страницы “Сделки”, “Аккаунт продавца” и страницу самой сделки происходит подгрузка transaction. А, соответственно, если создать у пользователя transaction на пару гигабайт - страница будет грузиться очень медленно.
Делаем из этого вывод, что простенький скрипт на питоне может повалить возможность оплачивать товар.
Из все той же открытой документации берем запросы на получение всех товаров и для каждого товара производим запрос на оплату огромное количество раз для создания большого количества транзакций.
Ставим асинхрон, кладем все это на вдс и ждем. Проверять количество информации, которое загрузилось, можно прямо у себя на странице “Сделки”. После того, как запрос стал весить около 150 мб, с сервера начала приходить 500-ка на запрос получения сделок. Видимо, уперлись в какие-то ограничения железа.
Еще около 150 мб данных на 1 пользователя - и перестал работать вывод средств - та же 500-ая ошибка. Думаю, эти транзакции учитываются при подсчете количества денег на счету.
Таким образом, если загрузить в систему к каждому товару по 300 мб данных - можно лишить возможности всех продавцов выводить средства с счета, а всех остальных пользователей - что-либо покупать.
Немного советов по исправлению
Нанять в штат полноценного тестировщика. Когда твое api содержит такие баги, а документация лежит в открытом доступе - это уже даже не звоночек, а целый колокольный звон.
На просмотр системы и написание скриптов я потратил около 3 часов. + еще ночь для проверки гипотезы с сущностью transaction (оставил просто ноут спамить). Думаю, что в системе еще множество недостатков, найти которые было некому;
Для избавления от возможности флуда - поставить более серьезные ограничения;
Пересмотреть алгоритм работы с финансами;
Провести аудит безопасности;
Чаще прислушиваться к советам команды.
Выводы
Тестирование - это важно. Если вы начинаете разрабатывать стартап или какой-то проект на freelance основе - не поленитесь и выделите отдельного человека для тестирования. Если вы - основатель it проекта, то, подбирая команду на проект, обязательно обращайте внимание, чтобы в команде был человек, ответственный за тестирование системы.
В данной статье я рассмотрел лишь поверхностно платформу. Я не проводил полноценное тестирование системы или аудит безопасности. Вполне возможно, что в системе есть и более серьезные уязвимости
P.S. Приведенный в статье код не обязан быть написан по best practices - это тот минимум, который можно было написать за минимальное время.
В статье я никого не призываю заниматься черным хакингом и использовать обнаруженные вами или кем-либо другим уязвимости в корыстных целях. Я считаю, что можно зарабатывать помогая
Связаться со мной можно в telegram: @python_ma
Комментарии 0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.