Как стать автором
Обновить

Продукт без тестирования

Время на прочтение7 мин
Количество просмотров8.7K

Всем привет, друзья. Немного детектива вам в ленту.

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

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

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

О проекте

UPD: Так как данная статья не несет информацию рекламного характера здесь и далее я удалил какие-либо упоминания конкретной платформы.
Хочу еще раз обратить внимание на то, что в первую очередь цель этой статьи - на примере показать, что бывает с проектом, когда его не тестируют.

Сам проект не столь интересен, как способ его разработки. Ребята копируют одну довольно известную биржу игровых ценностей ставя на более низкие проценты комиссии проекта (на момент 19.06.2021 комиссия проекта составляет 0%, однако, как выяснилось позднее, обычный пользователь все равно платит комиссию платежки как в случае оплаты товара, так и в случае вывода средств с платформы).

Проект на рынке уже около 6 месяцев, в общем чате на платформе раз в 6 часов появляется объявление о продаже того или иного товара. На платформе лежит около 500 товаров (в среднем по 5 товаров на игру).

Разработкой занималось несколько команд в разное время. Только последней командой проект разрабатывается уже более года. Большую часть проекта создала последняя команда из 7 человек, в последствии сокращенной до 4 человек. 

Стоит отметить, что по словам разработчиков проекта, тестирование не проводилось из-за невозможности договориться с основателем. Команда разработки работала на freelance основе, то есть поблочно. При этом основатель категорически был против финансировать тестирование проекта, считая это пустой тратой времени.

P.S. Перед написанием статьи я вбил на GitHub в поиске {UPD: название компании} - таким образом я вышел на разработчика проекта (ник на GitHub совпадал с ником в telegram). Через него уже получил остальных ребят. Вся информация, представленная выше, с уст разработчиков или основателя проекта.

С основателем проекта мне удалось связаться через сайт биржи. Контакты получил оставив обратную связь.

Проводим собственное тестирование. Начало пути

Думаю, пора перейти к самому сладкому.

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

Из консоли узнаем url адрес и формат сообщений. Так как вся наша защита - это ожидание в 5 секунд - все, что нам необходимо сделать, это поставить таймер в скрипте на 5 секунд. С задачей зафлудить чат справиться и ноутбук под рукой. Что же делать с блокированием пользователя админами? Думаю, к этому вернемся позднее.

Таким образом какой-то злоумышленник или конкурент может испортить первое впечатление пользователей о платформе.

Искал медь, а нашел золото

Идем далее. При тестировании продукта стоит проверять и абсурдные идеи: зачастую разработчики упускают столь простые моменты. Особенно когда разработка идет без тестирования. Я решил проверить наличие документации в открытом доступе. Из той же консоли вытаскиваем первый попавшийся url, на который делает запрос сайт https://transaction.{UPD: url платформы}1.ru. Проверяем на нем самый дефолтный путь - /swagger-ui/ (проверял также /swagger-ui/index.html, /swagger-ui.html, /api-docs и с добавлением /v{цифра}/). И неожиданно натыкаемся на золотую жилу.

Таким образом находим документации к следующим сервисам:

  • Сервис, отвечающий за оплату товаров и вывод средств с платформы https://transaction.{UPD: url платформы}1.ru/swagger-ui/ 

  • Сервис, отвечающий за хранящуюся информацию об играх и товарах на сайте https://game.{UPD: url платформы}1.ru/swagger-ui.html 

  • Сервис, отвечающий за регистрацию, авторизацию пользователей (в том числе администраторов) https://auth.{UPD: url платформы}1.ru/v3/api-docs 

  • Сервис, отвечающий за хранение конфиденциальной информации о пользователе  https://profilerus.{UPD: url платформы}1.ru/swagger-ui/index.html 

  • То же самое, что и выше https://profile.{UPD: url платформы}1.ru/swagger-ui/index.html 

  • Сервис, отвечающий за хранение сообщений на портале https://chat.{UPD: url платформы}1.ru/v3/api-docs 

Не удалось найти документацию к следующим сервисам: https://proxy.{UPD: url платформы}1.ru/, https://online.{UPD: url платформы}1.ru/ . Думаю, не большая потеря.

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

Изучаем документацию

Из документации к сервису авторизации узнаем, что при регистрации нового пользователя нет проверки капчи (она есть на сайте).

Получаем простое дополнение к скриптам для генерации нового пользователя при блокировке старого.

Смотрим в сторону наполнения сайта

Сильно в документацию не стал копать. В доке по товарам находим способ добавлять неограниченное количество товаров в игру.

В качестве Authorization используется JWT токен, который мы берем из любого запроса, который отправляет сайт
В качестве Authorization используется JWT токен, который мы берем из любого запроса, который отправляет сайт

Пишем простенький скрипт на python, чтобы проверить нет ли ограничений на количество товаров на 1 пользователя. Запускаем, ждем пару минут и убеждаемся, что кому-либо зафлудить систему просто.

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

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

Смотрим систему работы с финансами

Перейдем к системе оплаты товаров и вывода средств. Как удобно, когда все разделено на логические блоки :)

Залезаем в консоль разработчика. Проследив за запросами, получаем примерную логику работы системы: при оплате происходит запрос на бэк, на бэке создается новая transaction, к которой генерируется ссылка на оплату (оплата происходит через сторонний эквайринг, в ссылке указывается id сущности transaction). И подмечаем интересную вещь - при повторном запросе на создание сделки генерируется новая transaction, но старая не удаляется. Вероятнее всего это сделано на случай, если человек перешел по 2 ссылкам и оплатил более раннюю - эквайринг должен уведомить по какой transaction произошла оплата. Зачем каждый раз создавать новую transaction - сложно понять, наверное есть способ изменения некоторых параметров транзакции (количества покупаемого товара и прочее).

Из интересного подмечаем, что при переходе на страницы “Сделки”, “Аккаунт продавца” и страницу самой сделки происходит подгрузка transaction. А, соответственно, если создать у пользователя transaction на пару гигабайт - страница будет грузиться очень медленно.

Делаем из этого вывод, что простенький скрипт на питоне может повалить возможность оплачивать товар.

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

Ставим асинхрон, кладем все это на вдс и ждем. Проверять количество информации, которое загрузилось, можно прямо у себя на странице “Сделки”. После того, как запрос стал весить около 150 мб, с сервера начала приходить 500-ка на запрос получения сделок. Видимо, уперлись в какие-то ограничения железа.

Еще около 150 мб данных на 1 пользователя - и перестал работать вывод средств - та же 500-ая ошибка. Думаю, эти транзакции учитываются при подсчете количества денег на счету.

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

Немного личных советов по исправлению

  1. Нанять в штат полноценного тестировщика. Когда твое api содержит такие баги, а документация лежит в открытом доступе - это уже даже не звоночек, а целый колокольный звон.

    На просмотр системы и написание скриптов я потратил около 3 часов. + еще ночь для проверки гипотезы с сущностью transaction (оставил просто ноут спамить). Думаю, что в системе еще множество недостатков, найти которые было некому;

  2. Для избавления от возможности флуда - поставить более серьезные ограничения;

  3. Пересмотреть алгоритм работы с финансами и убрать загрузку лишней информации на страницах;

  4. Провести аудит безопасности;

  5. Чаще прислушиваться к советам команды.

Выводы

Тестирование - это важно. Если вы начинаете разрабатывать стартап или какой-то проект на freelance основе - не поленитесь и выделите отдельного человека для тестирования. Если вы - основатель it проекта, то, подбирая команду на проект, обязательно обращайте внимание, чтобы в команде был человек, ответственный за тестирование системы.

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

P.S. В статье я никого не призываю заниматься черным хакингом и использовать обнаруженные вами или кем-либо другим уязвимости в корыстных целях. Я считаю, что можно зарабатывать помогая

Теги:
Хабы:
Всего голосов 10: ↑8 и ↓2+8
Комментарии25

Публикации

Истории

Работа

Ближайшие события

25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань