Пентест мобильных приложений от А до Я: особенности проведения и критерии выбора подрядчика

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

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

В отличие от серверов и веб-интерфейсов, которые работают в предсказуемой среде, мобильные приложения живут в условиях, где разработчик не управляет ни устройством, ни системой, ни тем, что пользователь может с ними делать. Это создаёт дополнительные риски. Чтобы защитить продукт, данные и деньги, компании проводят пентесты (тестирования на проникновение) — комплексную проверку безопасности мобильного приложения.

1. Приложение находится на устройстве пользователя
Главная особенность мобильного клиента, в том что вы не контролируете среду, в которой он работает. Телефон может быть рутованным, зараженным или настроенным так, что приложение становится прозрачным для атакующего. Даже идеальная серверная логика не спасает, если злоумышленник может вмешаться в работу клиента.

2. Фрагментация платформ и прошивок
На Android работают тысячи моделей устройств с разными прошивками, модификациями ядра и уровнем безопасности. На iOS проще, но джейлбрейк полностью ломает модель защиты. В итоге разработчик не может опираться на то, что система сама защитит данные.

3. Рут, эмуляторы, снифферы, MITM-прокси
Проблема не в теоретических атаках — все это находится в открытом доступе. Любой желающий может:
— Перехватывать и расшифровывать трафик приложения,
— Обойти SSL-pinning,
— Подменять параметры,
— Модифицировать приложение перед запуском,
— Внедрять хуки в рантайме,
— Запускать приложение в эмуляторе с инструментами анализа.

Если приложение не готово к такому сценарию, уязвимости появляются автоматически.

4. Локальное хранение данных
Токены, ключи API, кэш, журналы запросов, временные данные. Многие приложения оставляют следы, которые позволяют злоумышленнику получить доступ к личному кабинету, внутренним API или административным функциям. Если данные не шифруются, не защищаются или хранятся в открытом виде, их могут прочитать за минуту.

5. Ошибки архитектуры
Частая проблема — перенос части логики на клиент. Приложение решает, можно ли выполнить ту или иную операцию. Атакующий может изменить параметры запроса, подделать роль, изменить лимит или выполнить операцию, которая должна быть запрещена.

6. Рост фрод-сценариев
Многие мобильные сервисы страдают от:
— Фарма бонусов и купонов,
— Обхода лимитов,
— Повторных транзакций,
— Фейковых заказов,
— Махинаций с геолокацией,
— Автоматизации действий,
— Подделки акций,
— Манипуляций с тарификацией.

Это тоже часть пентеста, потому что бизнес-логические уязвимости могут быть опаснее технических.

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

Чем мобильный пентест отличается от веб-пентеста?
Веб-сервис живёт у компании на серверах, где все под контролем, все в рамках инфраструктуры. Там понятно, что к чему, и ты тестируешь то, что компания реально контролирует.

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

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

Приходится разбирать и сам клиент. Как он хранит токены, что записывает в память, как ведет себя при ошибках, можно ли изменить параметры и получить другой результат. Часто именно в логике клиента-сервера и прячутся уязвимости, которых в вебе просто не бывает. Это более широкий тип проверки, где много завязано на поведении приложения, а не только на том, что происходит на backend.

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

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

Не обходят стороной локальные хранилища — базы, настройки, кеш. Анализируют сторонние SDK, которые участвуют в работе приложения, и проверяют, как обрабатываются push-уведомления, переходы по deep-link и другие механики, которые могут стать точкой атаки.

По сути, в область пентеста попадает все, что формирует поведение приложения — и на устройстве, и на стороне сервера.

В мобильных пентестах обычно используют два подхода: чёрный ящик и серый ящик (Black box и Grey box). Разница между ними в том, сколько информации получает специалист перед началом работы.

● Чёрный ящик — это когда дают только саму сборку приложения и ничего больше. Тестировщик ставит его на устройство и смотрит на продукт глазами обычного пользователя: без документации, без подсказок, без дополнительных данных. Такой режим помогает увидеть, что может сделать человек, имея только файл APK или IPA.
● Серый ящик — более информативный вариант. Здесь предоставляют тестовые учетные записи, роли или короткое описание ключевых процессов. Иногда дают минимальную документацию по API. Это ускоряет работу и позволяет глубже копнуть в критичные сценарии, но при этом все еще сохраняет реальную модель атаки, где у специалиста нет исходников и полного доступа к внутренней архитектуре.

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

При мобильном пентестинге обычно ориентируются на OWASP MASVS. Это такой общий список требований к безопасности приложений, который помогает не упустить важные моменты и проверить продукт по единым правилам. На практике это удобная точка отсчета, по которой проще понять, насколько глубоко нужно копать и какие области смотреть в первую очередь.

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

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

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

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

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

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

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

Ниже — основа полноценного тестирования.

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

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

Чем яснее картина на этом этапе, тем легче потом ловить ошибки и понимать, где может скрываться риск.

2. Статический анализ
На этом этапе приложение разбирают на составляющие без запуска, просто открывают сборку и смотрят, что в ней лежит. Обычно смотрят какие модули внутри, как упакованы ресурсы, какие файлы используются. Часто в них находят конфигурации, внутренние адреса API, вспомогательные параметры или вещи, которые изначально не планировалось показывать наружу.

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

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

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

3. Динамический анализ
Динамический этап — это когда приложение наконец-то запускают и начинают проверять на практике. Не только смотреть, что внутри сборки, а как оно ведёт себя вживую. Обычно тестер ставит приложение на устройство или эмулятор и начинает гонять разные сценарии.

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

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

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

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

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

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

4. Тестирование API
Когда дело доходит до API, акцент смещается на то, как сервер реагирует на все, что приходит от клиента. Тут проверяют уже не внешний слой приложения, а то, что происходит внутри.

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

Параллельно изучают работу сессий и токенов. Что будет, если отправить просроченный токен? Или поддельный? Или токен другого пользователя? Как API реагирует на такие попытки и где валидация проваливается.

Отдельно проверяют моменты, где может возникнуть эскалация привилегий — ситуации, когда человек с минимальными правами получает доступ к действиям, которые для него не предназначены.

Если API ограничивает частоту запросов, это тоже тестируют. Как сервер ведет себя при быстром повторе, можно ли обойти лимиты. Иногда настоящая проблема всплывает не в очевидных местах, а в реакциях на нестандартные сценарии — нестабильное соединение, обрыв запроса, повторная отправка операции.

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

5. Проверка хранения данных
Дальше смотрят на то, что приложение оставляет на устройстве. Здесь уже важна не логика и не трафик, а то, какие следы остаются после работы клиента. Открывают стандартные хранилища. На Android это могут быть SharedPreferences или базы SQLite, на iOS — UserDefaults или локальные контейнеры. Если используются сторонние решения, вроде Realm или Room, их тоже разбирают.

Дополнительно проверяют, что лежит в Keychain или Keystore, если приложение использует защищенные способы хранения. Нередко туда кладут только часть данных, а остальное остается в открытом виде в обычных файлах или в кеше.

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

Главный критерий здесь простой. Если токен или другой чувствительный параметр можно вытащить напрямую из файлов приложения, значит аккаунт уже не считается защищенным. Даже без взлома сервера доступ можно получить просто через содержимое устройства.

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

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

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

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

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

И, конечно, анализируют поведение на стыке UX и API: что происходит, если шаги выполняются в другом порядке, если пользователь прерывает операцию в середине, возвращается назад, меняет значения после расчёта или отправляет запросы раньше времени. Именно здесь чаще всего появляются неожиданные дыры, которые не относятся к уязвимостям в классическом понимании, но напрямую бьют по деньгам.

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

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

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

8. Формирование отчёта
В финале нужно собрать все, что было найдено, в понятный и полезный документ. В отчет включают сами уязвимости, примеры того, как их можно использовать, и реальную оценку риска, насколько проблема опасна и при каких условиях она может привести к инциденту.

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

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

Здесь нет универсальной формулы, но есть адекватный минимум.

1. Перед первым релизом
Запускать новое мобильное приложение без проверки безопасности — это всегда игра на удачу. Первая версия почти всегда содержит скрытые уязвимости, просто потому что продукт только сформировался, а команда еще не видела, как он ведет себя вживую.

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

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

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

Это нормальная практика, которая экономит время и нервы после релиза.

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

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

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

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

5. При выходе на новые рынки
Когда продукт выходит на новый рынок, меняется не только аудитория, но и требования к безопасности. Где-то регуляторы смотрят строже, где-то выше требования к приватности, а иногда просто появляется другой набор угроз.

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

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

Важный момент нашего подхода в том, что мы смотрим не только на технические уязвимости. Бизнес-логика и фрод не менее критичная часть. Много денег теряется не через SQL-инъекции, а через хитрые сценарии, которые пользователь может провернуть «между строк»: повторная транзакция, обход лимита, странное поведение бонусной системы, подмена параметров в API. Мы анализируем, как приложение ведёт себя в реальных условиях, где именно возникают финансовые риски и какие операции можно использовать в обход правил.

Работа идёт сразу по трём направлениям: клиент, API и логика операций. Мы смотрим приложение как единый механизм. Не отдельно APK, отдельно эндпоинты, отдельно UX, а всё вместе — как реальный злоумышленник, который не делит систему на удобные части. Это даёт более честную картину и позволяет поймать то, что ускользает при изолированном тестировании.

Отчеты мы делаем такими, чтобы с ними можно было работать, а не складывать «в папку с документами». Разработчики получают понятные технические рекомендации и конкретные места, где нужно править. Менеджеры видят риски простым языком — что критично, что средне, что влияет на бизнес, а что не мешает жить. Нет размытых формулировок и «потенциально возможно при определённых условиях» — только конкретика.

После пентеста мы не исчезаем. Помогаем приоритизировать правки, подсказываем архитектурные решения, выстраиваем минимальные правила безопасной разработки, подключаемся к повторной проверке, чтобы убедиться, что всё закрыто корректно. Для многих клиентов АБП2Б — это не разовое тестирование, а постоянный партнёр по безопасности, который помогает держать продукт в рабочем и защищённом состоянии.

Это долгий цикл: регулярные проверки, анализ новых функций, экспертиза по логике, по API и по поведению мобильного клиента. Именно так строится нормальная культура безопасности — без паники, без хаоса, без «чинить завтра, иначе всё рухнет».

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

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

Когда пентест встроен в рабочий цикл — перед релизом, после крупных изменений и хотя бы раз в год — безопасность перестаёт быть пожарной задачей. Она становится нормальной практикой, которая поддерживает стабильность продукта и помогает ему расти без сюрпризов. В итоге выигрывают все: и команда, и бизнес, и люди, которые каждый день пользуются приложением.

Для связи с нами — abp2b.com/pentest.