Пентест мобильных приложений: как выявить уязвимости, которых вы не видите

Ваш код скомпилирован, подписан и загружен в стор. Но пользователь, который его установит, уже через час запустит приложение на рутованном устройстве под управлением Frida. Он увидит ваш API-ключ в дампе памяти, снимет SSL Pinning одной командой и скопирует токены авторизации из SharedPreferences. Пентест мобильных приложений — это единственный способ узнать, сколько именно времени у него на это уйдет, и успеть закрыть дыры до публичного релиза.

Что такое пентест мобильных приложений

Пентест мобильного приложения — это контролируемая симуляция действий злоумышленника, направленная на получение несанкционированного доступа к данным, функциям или инфраструктуре через клиентское мобильное ПО. В отличие от стандартного аудита кода, пентест моделирует реальную атаку: специалист действует в условиях, приближенных к боевым, используя те же инструменты (Burp Suite, Frida, Objection), что и хакер, но в рамках заранее согласованных границ и без причинения ущерба.

Для чего нужен пентест мобильного приложения

Бизнес редко интересуют абстрактные «дыры в безопасности». Ему важны конкретные риски: штрафы, остановка сервиса, уход клиентов. Причины, по которым стоит провести анализ защищенности мобильного приложения, лежат именно в этой плоскости:

1. Прямые убытки от фрода и махинаций. Уязвимости бизнес-логики позволяют злоумышленникам накручивать бонусы, оформлять заказы с фейковой геолокацией или совершать транзакции без списания средств. Пентест выявляет такие сценарии до того, как ими начнут пользоваться в промышленных масштабах.
2. Штрафы за нарушение ФЗ №152-ФЗ. Утечка персональных данных (ФИО, паспорт, геолокация, биометрия) из-за небезопасного хранения на устройстве — все это может привести к штрафу в 20 млн рублей, при повторном нарушении — 1-3% годового оборота, минимум 25 млн, максимум — 500 млн рублей (ст.13.11 КоАП РФ). 
3. Потеря эквайринга по PCI DSS. Если приложение обрабатывает платежные данные и проваливает аудит на соответствие стандарту, платежные системы вправе отключить прием карт. Для интернет-магазина или онлайн-кинотеатра это коллапс бизнеса.
4. Репутационный ущерб и отток клиентов. 95% пользователей банковских приложений готовы сменить банк, если узнают, что их данные были скомпрометированы по вине разработчиков.
5. Срыв сроков выхода в продакшн. Обнаружение критической уязвимости в приложении, уже прошедшем модерацию App Store или Google Play, означает экстренный выпуск патча и повторное ожидание модерации (до 7 дней), что убивает маркетинговые кампании.

Причины уязвимостей мобильного приложения

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

1. Полный контроль устройства со стороны атакующего. На рутованном Android или джейлбрейкнутой iOS любой встроенный механизм защиты может быть нейтрализован за минуты. Злоумышленник снимает дамп оперативной памяти, читает ключи из SharedPreferences и Keychain, перехватывает TLS-трафик через Burp Suite — даже если на устройстве установлен корпоративный сертификат. В таких условиях пентест мобильных приложений отвечает не на вопрос «можно ли взломать?», а на вопрос «сколько времени это займет?».
2. Фрагментация платформ и устаревшие версии ОС. Экосистема Android включает миллионы устройств с вендорскими прошивками, где производитель не закрыл публичные уязвимости ядра. На iOS версий ниже 15.6 эксплойты для джейлбрейка доступны в открытом репозитории. Разработчик не может полагаться на безопасность платформы — криптографическая защита должна быть самодостаточной.
3. Доступность хакерского инструментария. Frida, Xposed, Objection, Magisk, Corellium — это не спецсредства спецслужб, а открытое ПО с подробными гайдами. Обход Root Detection или Jailbreak Detection выполняется скриптом из трех строк. SSL Pinning срывается автоматическими инструментами (SSL Kill Switch 2). Пентестер использует тот же арсенал, поэтому результат пентеста мобильного приложения прямо коррелирует с временем, которое злоумышленник готов потратить на анализ.
4. Небезопасное локальное хранение данных. Токены доступа, ключи API, слепки сессий, отладочные логи, кэшированные ответы сервера — все это остается в файловой системе устройства. Согласно статистике OWASP, 70% протестированных приложений хранят чувствительные данные в открытом виде или с обратимым шифрованием. Даже кратковременное попадание такого устройства в чужие руки (кража, ремонт) ведет к компрометации учетной записи.
5. Перенос критической логики на клиент. Если проверка прав доступа («является ли пользователь администратором», «доступен ли тариф») выполняется на стороне мобильного приложения, это не ошибка кодирования — это архитектурный провал. Атакующий всегда может модифицировать JavaScript в WebView, подписать патченный APK или внедрить Frida-хук, возвращающий «true» в функцию проверки роли. Сервер обязан принимать решение самостоятельно.
6. Индустриализация фрод-сценариев. Современный злоумышленник автоматизирует атаки. Он не взламывает одно приложение ради пары аккаунтов — он разворачивает ботнет из тысяч эмуляторов Android, обходит captcha, подменяет GPS-координаты и выводит бонусы через API напрямую, имитируя легитимные запросы. Бизнес-логические уязвимости в этом сценарии приносят убытки, сопоставимые с прямым хищением средств.

Методы пентеста мобильного приложения

В индустрии закрепились несколько основных моделей: 

1. Черный ящик (Black box). Специалисту передается только дистрибутив (.apk или .ipa). Нет доступа к исходному коду, серверной архитектуре, документации. Это взгляд внешнего хакера, который нашел файл приложения на торрентах. Такой подход максимально приближен к реальной атаке, но не гарантирует 100% покрытия кода: некоторые участки функционала могут быть недоступны без определенного статуса аккаунта.
2. Серый ящик (Grey box). Пентестер получает тестовые учетные записи, описание бизнес-логики или частичную документацию API. Это позволяет глубже протестировать ролевую модель, транзакционные сценарии и авторизацию. Стоимость пентеста мобильного приложения методом Grey box выше, но и результат точнее: выявляются уязвимости, которые в черном ящике могли остаться незамеченными из-за ограниченного времени теста.
3. Белый ящик (White box) — полноценный аудит исходного кода. Хотя формально это тоже пентест, на практике White box часто выделяют в отдельную услугу SAST (Static Application Security Testing)

Что проверяется при пентесте мобильного приложения

Промышленным стандартом верификации является OWASP MASVS (Mobile Application Security Verification Standard). Версия 2.0 включает профили безопасности, а MASTG (Mobile Application Security Testing Guide) содержит более 82 обязательных тестов.

Проверка хранилищ и кэшей. Анализируются директории приложения, базы данных SQLite, SharedPreferences, Keychain (iOS), Keystore (Android). Ищутся пароли, токены, остаточная информация из WebView, снимки экрана, уходящие в фон.

Сетевая безопасность. Тестируется корректность SSL Pinning: можно ли подменить сертификат на лету через прокси. Проверяется поддержка TLS 1.2/1.3, запрет на смешанный контент (HTTP + HTTPS).

Криптография. Выявляются жестко зашитые ключи шифрования, использование алгоритмов MD5, SHA1, ECB-mode в AES, небезопасная генерация случайных чисел.

Бизнес-логика. Это самый дорогой и сложный этап. Проверяется, можно ли провести транзакцию дважды, обойти лимиты, сменить роль пользователя, подменить ID в запросе.

Устойчивость к реверсу. Проверяется наличие обфускации, защита от отладки, Root Detection, Jailbreak Detection. Важно: обход защиты за 5 минут не считается пройденным тестом, если это не документировано как задача.

При этом пентест мобильного приложения не включает нагрузочное тестирование, поиск уязвимостей в серверной инфраструктуре и полный аудит кода (если это не White box). Это проверка именно клиентской части и ее взаимодействия с API.

Чем пентест мобильного приложения отличается от веб-пентеста

Принципиальное отличие мобильного пентеста от веб-пентеста кроется в модели угроз. В вебе вы защищаете сервер, который контролируете. В мобильной среде вы защищаете клиента, которого не контролируете. Устройство пользователя может быть рутованным (Android) или подвергнутым джейлбрейку (iOS), трафик — перехвачен через публичный Wi-Fi, а само приложение — модифицировано и пересобрано. Поэтому пентест мобильных приложений всегда включает анализ устойчивости к реверс-инжинирингу, защищенности локального хранилища и корректности работы SSL Pinning.

Смешивание этих двух практик — одна из самых частых ошибок. Внешне мобильное приложение общается с API, как и браузер, но модель угроз и точки контроля различаются кардинально: 

1. Среда исполнения. Веб-приложение выполняется в браузере, где действуют Same-Origin Policy и CSP. Браузеры обновляются автоматически, и у вас нет 100% контроля над ними, но они хотя бы стандартизированы. Мобильное приложение работает в нативной среде, где защита целиком зависит от разработчика. Вы не можете заставить пользователя обновить iOS с 14-й версии до 17-й. Следовательно, ответственность за криптографию и хранение секретов перекладывается с платформы на код.
2. Возможность модификации клиента. Веб-клиент можно инспектировать через DevTools, но модифицировать его сложно — браузер не даст переписать JavaScript на лету и сохранить изменения (persistence). Мобильное приложение — это исполняемый файл на диске. Злоумышленник может дизассемблировать его, снять защиту отладчика, пропатчить байт-код и переподписать. Бороться с этим можно только обфускацией и проактивными проверками целостности, что само по себе является отдельным направлением пентеста.
3. Векторы входа. Веб-приложение принимает данные через HTTP-запросы. Мобильное приложение — через десятки векторов: Intent’ы (Android), URL-схемы, универсальные ссылки, Deep Links, NFC, Bluetooth, сканер QR-кодов, файловый менеджер, буфер обмена. Каждый такой вектор может стать точкой входа для атаки (например, отправка вредоносного Intent, вызывающего открытие WebView с JavaScript-инъекцией).
4. Режим доступа к данным. Веб-пентестер видит только то, что приходит на сервер. Он может подменять параметры запроса, но не может увидеть, какие данные реально хранятся на устройстве пользователя. Пентест мобильных приложений работает иначе: мы снимаем дамп БД, читаем кэш, анализируем временные файлы, оставшиеся после авторизации.
5. Процесс исправления уязвимостей. Нашли XSS на сайте? Поправили код, сделали деплой — пользователи сразу защищены. Нашли небезопасное хранение токена в мобильном приложении? Разработчик исправил код, но пользователи не получат обновление, пока:

• команда не соберет билд;
• пройдет внутреннее тестирование;
• Apple/Google не одобрят обновление (от 2 часов до 7 дней);
• пользователь не нажмет «Обновить».

Чтобы заказать пентест мобильного приложения, обратитесь в компанию, специализирующуюся на информационной безопасности. Только специалисты могут провести полноценное тестирование, выявить уязвимости и дать рекомендации по их устранению.