Всем привет! Подвёл итоги выходных — так сказать, снова на страже Сетки)

За два дня получилось найти и отправить 4 уязвимости Low-уровня, две из которых уже приняли.

Недавно мы обновили большую часть функционала и визуала проекта pentester-dashboard что позволило по максимум оценить его в работе по исследование через структуру записей и как видно по 1 скрину успешно, а пример подхода видно на втором скрине.

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

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

И как раз один такой вопрос привёл к одному из четырёх отчётов.

Представим функционал отзывов о товаре. Пользователь сначала оставляет первое впечатление о покупке, а спустя какое-то время может дополнить его вторым отзывом — уже после реального использования товара.

Для обоих текстов установлен лимит в 500 символов. По API это условно выглядит так: ① POST /v1/add/product-recall-first → создаёт первый отзыв ② POST /v1/add/product-recall-two → добавляет второй отзыв

Если тестировать каждый эндпоинт отдельно, всё выглядит нормально. Первый не принимает больше 500 символов. Второй тоже не принимает больше 500 символов.

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

То есть через запрос создания первого отзыва можно передать поле второго. А через запрос добавления второго — изменить поле первого.

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

В результате через «чужое» поле получилось передать значение значительно больше установленного ограничения. При дальнейшей обработке это приводило к ошибкам 500 и позволяло создавать повышенную нагрузку на сервер.

Получается довольно интересный паттерн: два безопасных по отдельности эндпоинта → пересекающиеся модели данных → недокументированные параметры → другой флоу валидации

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

Low но зато ещё один паттерн поиска в копилку. А копейка, как известно, рубль бережёт :)

#AppSec #BugBounty #Setka #CyberSecurity #Pentest #standoff365