Безопасность мобильных приложений: как проверить?

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

Что означает проверка безопасности и где проходят границы

Цель проверки — подтвердить, что приложение защищает данные «в покое» и «в пути», не раскрывает лишнего о пользователе, устойчиво к базовым атакам и соответствует требованиям платформы и бизнеса. Сразу определите рамки: кто дал разрешение на тесты, какие окружения и учётные записи использовать, какие хосты трогать, допустим ли перехват трафика на тестовом стенде, где хранить результаты. Чёткая договорённость экономит время и помогает действовать в правовом поле.

Подготовка и правовые рамки

Любой аудит начинается с согласования. Нужно письменное разрешение владельца приложения и инфраструктуры, список разрешённых действий и окно времени. Готовим стенд: тестовые учётные записи, данные-заглушки, отдельный контур серверов или «песочница», а также устройства — минимум один реальный Android-телефон и один iPhone. Эмуляторы помогают на старте, но часть уязвимостей проявляется только на «железе».

Стандарты и критерии: на что опираться

Чтобы проверка была объективнее, используйте открытые стандарты:

• OWASP MASVS — стандарт проверки безопасности мобильных приложений (архитектура, хранение данных, сеть, аутентификация, кодовая база и др.).
• OWASP MSTG — практическое руководство по тестированию с примерами и сценариями.
• Документация платформ: Android Security и Apple Security.

Сформируйте собственный список проверок под ваш домен — финтех, здравоохранение, образование, корпоративные сервисы — у каждого свои акценты.

Инвентаризация: что именно тестируем

Соберите факты до активных действий: версии приложения, список библиотек и SDK, способы входа (пароль, биометрия, одноразовые коды), типы хранимых данных, сетевые точки (API, аналитика, сторонние сервисы), запрашиваемые разрешения, механизмы защиты от реверса. Если возможно, получите SBOM — перечень состава программного обеспечения (Software Bill of Materials) — и конфигурации сборки.

Статический анализ: что видно без запуска

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

Android

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

• Манифест: только необходимые разрешения; нет «широких» прав без обоснования; компоненты не экспортируются без нужды; для Android 12+ — PendingIntent с флагами защиты.
• Хранение: пароли и токены не лежат открыто; используются Keystore и зашифрованные хранилища.
• Сеть: корректный networkSecurityConfig, запрет незашифрованных соединений, верные корневые сертификаты.
• Логи: нет чувствительных данных; подробное логирование отключено в релизе.

iOS

Проверьте Info.plist, права (entitlements), политику транспортной безопасности и работу Keychain.

• App Transport Security (ATS): запрет HTTP; исключения — только при необходимости и по конкретным доменам.
• Keychain: корректные атрибуты доступа; секреты не живут «вечно» без привязки к биометрии или коду.
• Entitlements: только нужные права; аккуратная работа с группами доступа и фоновыми режимами.

Инструменты для старта: MobSF (быстрая первичная оценка), jadx и apktool для Android; Frida и Objection для динамики; Xcode/LLDB для iOS.

Зависимости и секреты: слабые звенья чаще снаружи

Значительная часть кода — внешние библиотеки. Риски: уязвимости, лишний сбор данных, неожиданные сетевые обращения.

• Соберите SBOM и проверьте его на известные уязвимости.
• Исключите «секреты в коде»: ключи API, токены, пароли в строках и ресурсах.
• Разберитесь с SDK аналитики и рекламы: какой объём данных уходит и куда.

Данные на устройстве: где и как хранить

Данные «в покое» должны быть защищены даже при потере телефона.

• Android: используйте EncryptedSharedPreferences, шифрование БД, Keystore для ключей; при необходимости блокируйте снимки экрана на чувствительных экранах; не храните важное в общей памяти.
• iOS: секреты — в Keychain с правильным классом защиты; чувствительные файлы — с атрибутами, исключающими ненужное резервирование и синхронизацию.
• Журналы и отладка: без токенов и персональных данных в логах; отладка отключена в релизной сборке.

Сеть и шифрование: транспорт без сюрпризов

Большинство серьёзных инцидентов начинаются в сети. Проверяем строго.

• TLS 1.2/1.3, запрет незашифрованного HTTP.
• Строгая проверка сертификата и имени хоста; никаких заглушек «принять любой сертификат».
• На iOS — ATS; на Android — корректный networkSecurityConfig.
• Закрепление сертификата или публичного ключа — при необходимости и с запасными ключами для плановой ротации.

Для анализа используйте mitmproxy или Burp Suite на тестовом стенде: включите прокси в доверенные сертификаты, фиксируйте домены и типы данных, сохраняйте сессии.

Аутентификация, сессии и биометрия

Смотрите на всю цепочку: ввод, хранение, передача, обновление и завершение сессии.

• Короткий срок жизни токена доступа и корректное обновление по «refresh»-токену.
• Хранение токенов только в Keychain/Keystore, а не в открытых файлах и БД.
• Биометрия — как удобный способ разблокировки локального сеанса, а не единственный барьер.
• Чёткий выход: очистка токенов, закрытие сессий на сервере, удаление кэшей.

Взаимодействие приложений и системные механизмы

Мобильные ОС позволяют приложениям обмениваться данными — это удобно и рискованно.

• Android: проверьте экспорт компонентов; передаваемые Intent не содержат секретов; ContentProvider закрыт или ограничен правами; нет открытых приёмников без фильтров.
• iOS: аккуратно работайте с URL-схемами, общим буфером обмена и группами общего доступа; не передавайте чувствительные данные через общедоступные механизмы.

Динамический анализ: поведение «вживую»

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

• Перехват и анализ трафика через прокси; проверка всех конечных точек и заголовков.
• Фаззинг — автоматическое переборное тестирование форм и полей ввода; клиентские проверки не считаем достаточными — сервер решает.
• Инструменты внедрения: Frida/Objection — только на согласованном стенде; цель — убедиться, что приложение не раскрывает секреты при попытке вмешательства.
• Проверка реакции на рут-права и джейлбрейк: защита не должна ломать работу добросовестного пользователя.

Защита от реверса и подмены: разумный уровень

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

Разрешения и приватность: не брать лишнего

Лишние разрешения — это риск и повод для отказа при публикации. Проверьте следующее.

• Запрашиваются только необходимые права и в момент, когда это понятно пользователю.
• Политика конфиденциальности доступна из приложения и отражает фактический сбор данных.
• Аналитика отключаема, объём персональных данных минимален, события анонимизируются.
• Соответствие требованиям магазинов: «Паспорт данных» в Google Play, «Этикетка конфиденциальности» и Privacy Manifest в App Store.

Автоматизация: чтобы безопасность была частью сборки

Единичный аудит полезен, но надёжность даёт конвейер. Включите проверки в CI/CD.

• SAST — статический анализ безопасности кода и проверка зависимостей; контроль SBOM.
• Поиск секретов в репозитории.
• Сбор «жёстких» настроек перед релизом: выключены отладочные флаги, закрыты логеры, включены обфускация и защита ресурсов.
• Автотесты для критичных сценариев: корректный выход, удаление токенов, запрет незашифрованного транспорта.

Отчёт и приоритизация: как донести результаты

Полезный отчёт — это не список проблем, а план улучшений. Для каждой находки укажите краткое описание, где обнаружено, пример эксплуатации (если есть), риск и конкретные шаги исправления. Разделите на «исправить срочно», «в следующем релизе», «наблюдать». Договоритесь о повторной проверке после исправлений.

Пошаговые сценарии

Быстрый аудит за 60 минут

1. Соберите сведения: версия, разрешения, сетевые домены.
2. Проверьте манифест/Info.plist на лишние права и открытые компоненты.
3. Запустите через прокси и оцените шифрование и перечень доменов.
4. Осмотрите локальные файлы приложения: нет ли открытых секретов.

Полная проверка за несколько дней

1. Инвентаризация, согласование сценариев и подготовка стенда.
2. Статика: код, зависимости, хранение, сеть, разрешения.
3. Динамика: перехват трафика, попытки подмен, анализ ошибок.
4. Отчёт, план исправлений, повторная проверка.

Короткий чек-лист

• Только необходимые разрешения.
• Данные шифруются; секреты — в Keychain/Keystore.
• Транспорт — на TLS; проверка имени хоста включена; нет «принять любой сертификат».
• Сессии короткоживущие; токены правильно хранятся и очищаются при выходе.
• Логи без чувствительных данных; отладка отключена в релизе.
• Зависимости известны и проверены; секретов в коде нет.
• Разумные меры против реверса без перегиба.
• Автоматизация в CI/CD: SAST, поиск секретов, контроль конфигурации.