Всем привет. Сегодня хочу описать свой небольшой опыт в тестировании мобильных приложений на Bug Bounty.

Ранее у меня уже выходила серия постов «Мобильный хакинг», где я рассказывал, как начать хантить мобилки: от подготовки AVD до прокидывания сертификата Burp в системное хранилище. Кто не видел первую часть — оставлю ссылку ниже: ➥ https://setka.ru/posts/019da636-008e-7a21-9a13-211b9a8f1b99

В этом посте хочу уже не про сетап, а про то, что реально встречается в мобильном хантинге, если смотреть на него глазами багхантера.

━━━━━━━━━━ Что говорит OWASP про мобилки ━━━━━━━━━━

Если смотреть на OWASP Mobile Top 10, то там всё довольно по-аппсечному: • неправильное использование credentials • небезопасная аутентификация и авторизация • недостаточная валидация входных и выходных данных • небезопасная передача данных • небезопасное хранение данных • проблемы с supply chain • слабая криптография

И всё это правда важно, особенно когда ты работаешь в формате white box.

White box — это когда у тебя есть исходники, тестовые учётки, доступы, документация, окружения и возможность нормально смотреть, как приложение устроено изнутри.

━━━━━━━━━━ Bug Bounty в мобилках ощущается иначе чем пишет OWASP ━━━━━━━━━━

В black box хантинге у тебя нет "чистых" исходников и контекста разрабов. Ты работаешь с тем, что можешь достать сам: • трафик приложения • APK приложения • поведение клиента • скрытые эндпоинты • отличия мобилки от веба • логику API • ответы сервера

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

Зато в мобилках часто есть другое — функционал, которого нет в вебе. • новый функционал, которого нет в вебе • новые эндпоинты • логику, которую не так много кто трогал

━━━━━━━━━━ Что я нашёл за пару месяцев на BB ━━━━━━━━━━

За пару месяцев хантинга мобилок у меня получилось найти 6 уязвимостей: • 4 приняли • 2 ушли в дубли

Раскрывать конкретного вендора и детали я, конечно, не могу, но по классам уязвимости были такие:

➤ DoS на стороне сервера и клиента Наверное, уже моя самая нелюбимая уязвимость, потому что именно её у меня почему-то принимают спокойнее всего)

➤ BAC / IDOR Классика: доступ к объектам пользователя без корректной проверки прав. Позволило читать обьекты всех юзеров в мессенджере

➤ Excessive Data Exposure Избыточные данные в JSON-ответе, которые позволяли обойти логику приложения и при минимальных правах раскрыть личность другого пользователя.

И вот здесь можно понять, что мобильное приложение это не просто “ещё один клиент” к тому же backend-у. Часто используется другие сценарии, другие параметры, другие эндпоинты и вообще другой взгляд на продукт.

━━━━━━━━━━ Мой личный вывод ━━━━━━━━━━

Мобильный хантинг — это не обязательно сразу “сложный реверс” SSL pinning. Иногда это просто внимательный анализ API, который почему-то оказался менее проверенным, чем веб.

#AppSec #BugBounty #MobileSecurity #AndroidSecurity #Pentest #WebSecurity #IDOR #DoS #CyberSecurity