Лутаем баунти с багбаунти
Всем привет! Сегодня на радостях пишу пост о том, как впервые у меня приняли отчёт с оплатой по вверху вилки из таблицы приоритетов. Так сказать, хвастаюсь)
Данный кейс показал мне, что лучше оформить отчёт с сомнениями, чем вовсе его не оформлять. Ведь если бы мои сомнения взяли верх, то ни принятого отчёта, ни баунти у меня бы не было.
В этом посте, кроме своих эмоций, я ещё поделюсь тем, как нашёл данную уязвимость — в обезличенном формате.
В чём же заключался данный кейс? Я изучал один из основных функционалов сервиса и обнаружил интересную реализацию. Она была нестандартной, а именно имела несколько состояний: ➤ в первом состоянии к объекту мы присваивали UID для сервера; ➤ во втором состоянии мы передавали данный UID, после чего функционал отрабатывал полноценно, как было заложено.
Вначале я обратил внимания на UID и решил базово проверить IDOR через заложенный флоу функционала, это не привело к успеху.
После этого я решил проверить: а что же будет, если после второго состояния снова обратиться к первому?
Вместо ошибки я получил информацию о том, что обновил уже существующий объект. Такое поведение не было заложено в функционале и позволяло мне произвести краш при нагрузке. Но, к сожалению, изменять состояния чужих объектов я не мог.
Как итог, я вынес для себя несколько правил: • если сомневаешься, то лучше всё равно зарепортить. Максимум, что могут сделать, присвоить статус инфо, особенно если отчёт составлен самостоятельно, а не полностью сгенерирован ИИ;
• проверять функционал не только по заложенному флоу, но и пробовать пропускать шаги, возвращаться назад и смотреть, как на это реагирует сервер;
• формирование размера баунти для меня всё так же остаётся загадкой)
