Анализ защищённости мобильных приложений
Приложение работает на устройстве, которое может быть потеряно, заражено вредоносным ПО, иметь root или jailbreak либо целиком находиться под контролем злоумышленника. Проверяем, что защита сохраняет эффективность и в этих сценариях, а критичные решения принимает сервер, а не клиент.
- Клиент и backend в одном объёме
Проверка только APK или IPA даёт неполную картину: многие критичные ошибки связаны с авторизацией, бизнес-логикой и доверчивостью серверной части к данным клиента.
- Android и iOS по OWASP MASVS/MASTG
Статическое и динамическое тестирование по признанной методике: согласованный профиль проверки и перечень выполненных контролей, а не свободный набор наблюдений.
- Глубина — по модели угроз
Для финансовых, медицинских и корпоративных приложений профиль проверки заметно глубже, чем для информационного сервиса без учётных записей.
Проверяем приложение так, как его увидит злоумышленник с полным доступом к устройству.
Приложение — не единственное, что проверяется
Риски мобильного продукта находятся одновременно в приложении, операционной системе, сторонних SDK, локальном хранении, механизмах deep link и серверном API. Одна и та же ошибка может выглядеть безобидно в коде и стать критичной в связке с платформой.
Проверка только APK или IPA без backend даёт неполную картину. Многие критичные ошибки связаны с авторизацией, бизнес-логикой и доверчивостью серверной части к данным, которые пришли от клиента, — в самой сборке их не видно.
Поэтому в работу берутся оба контура сразу: то, что происходит на устройстве, и то, как сервер реагирует на изменённый клиент.
Само приложение
Код, конфигурация сборки, ресурсы, встроенные секреты и криптография.
Операционная система и устройство
Root и jailbreak, вредоносное ПО, потеря устройства, снимки экрана и буфер обмена.
Локальное хранение
Файлы, базы, Keychain и Keystore, логи, кеш и резервные копии.
Сторонние SDK и зависимости
Аналитика, реклама, push, платежи: чужой код с правами вашего приложения.
Deep link, IPC и WebView
Точки, через которые в приложение попадают данные из внешнего мира.
Серверное API и бизнес-логика
Слой, где принимаются решения о правах, цене, статусе и критичных операциях.
Нижний уровень выделен намеренно: если сервер доверяет клиенту, усиление защиты в приложении проблему не закрывает.
Глубина проверки подбирается по чувствительности данных и по тому, что злоумышленник сможет сделать в случае успеха. Ниже — два типовых профиля; итоговый объём фиксируется на скоупинге.
Информационный сервис без учётных записей
Проверяются хранение, сетевое взаимодействие, разрешения, сторонние компоненты и типовые ошибки платформы.
Финансовые, медицинские и корпоративные приложения
Дополнительно — криптография и управление ключами, биометрия и сессии, устойчивость к реверсу и подмене, серверная авторизация и бизнес-логика.
Что берём в работу
Статическое и динамическое тестирование Android- и iOS-клиента вместе со связанными API. Ниже — типовой объём; итоговый состав фиксируется на скоупинге под конкретный продукт.
-
Сборки Android и iOS
APK и AAB для Android, IPA для iOS: манифест, права, ресурсы, конфигурация сборки.
-
Хранилище, Keychain и Keystore
Локальные данные, защищённые хранилища платформы и резервные копии устройства.
-
Аутентификация и биометрия
Вход, биометрия, сессии, токены, повторная аутентификация и выход.
-
TLS и сетевой трафик
Настройка TLS, проверка сертификатов и то, что реально уходит с устройства.
-
Внешние ссылки и обмен с другими приложениями
Открытие приложения по deep link и межпроцессное взаимодействие на устройстве.
-
WebView и JavaScript-интерфейсы
Встроенный веб-контент и мосты между веб-слоем и нативной частью приложения.
-
Устойчивость к реверсу и подмене
Анализ и модификация сборки, работа на устройствах с root и jailbreak.
-
Backend, push и сторонние SDK
Серверное API, push-уведомления, аналитика и внешние компоненты в сборке.
Работы опираются на практики OWASP MASVS и MASTG. Это значит, что объём проверки не зависит от вкуса конкретного специалиста: профиль контролей согласуется заранее, а в отчёт попадает перечень выполненных тестов — с ним удобно проходить аудит заказчика или магазина.
Чем эта услуга отличается от смежных работ
Три работы, с которыми анализ защищённости мобильного приложения чаще всего путают. Каждая из них полезна — но ни одна не закрывает связку «устройство + клиент + сервер» целиком.
-
от веб-тестирования
Клиент живёт на чужом устройстве
Дополнительно проверяются само устройство, локальные данные, межпроцессное взаимодействие, platform API и возможности реверса — того, чего в браузерном сценарии просто нет.
—Веб: сервер и браузерная сессия✓Мобильный: плюс устройство, хранилище, IPC и сборка -
от проверки API
Ошибки бывают и на стороне клиента
Мобильное приложение может раскрывать секреты, неправильно использовать криптографию или обходить локальные ограничения — по одному только API это не видно.
—API: корректность и защита эндпоинтов✓Клиент: секреты в сборке, ключи, обход проверок -
от формальной обфускации
Обфускация повышает цену, но не заменяет защиту
Она делает анализ дороже для злоумышленника — и только. Серверную авторизацию и безопасное хранение данных она не подменяет.
—Обфускация: усложняет разбор сборки✓Анализ: проверяет, что защита работает и после разбора
Когда услуга особенно актуальна
Каждый из этих моментов меняет поверхность атаки приложения — и в каждом дешевле найти проблему до релиза, чем после него.
-
Перед публикацией или крупным обновлением
Пока сборка ещё не ушла в магазин и правки не стоят внепланового релиза.
-
После изменений входа, биометрии, платежей или токенов
Механизмы доступа переписываются редко — и почти всегда с новыми ошибками.
-
При добавлении стороннего SDK или deep link
Чужой код получает права вашего приложения, а внешняя ссылка — вход в него.
-
Если приложение работает с персональными, финансовыми или медицинскими данными
Компрометация таких сведений влечёт не только технические, но и серьёзные финансовые, правовые и репутационные последствия — для этих продуктов профиль проверки изначально глубже.
-
Перед поставкой корпоративному заказчику или аудитом магазина
Когда результат проверки нужно предъявить внешней стороне в виде документа.
Какие задачи решает для бизнеса
Технические находки переводятся в понятные бизнесу вопросы: что можно забрать с устройства, кем можно притвориться и что сервер разрешит сделать изменённому клиенту.
-
Защита данных на устройстве
Секреты не должны без необходимости попадать в открытое хранилище, логи, буфер обмена, снимки экрана или резервные копии. Проверяем, что останется доступным, если устройство потеряно или заражено.
-
Серверная авторизация
Backend не должен доверять роли, цене, идентификатору или статусу, которые пришли от клиента. Это ключевая проверка: клиент можно изменить, сервер — нет.
-
Надёжная аутентификация
Проверяются токены, биометрия, блокировка, повторная аутентификация и выход из учётной записи.
-
Безопасная платформа
Проверяются exported-компоненты, deep links, WebView и межпроцессное взаимодействие на устройстве.
-
Контроль сторонних компонентов
Оцениваются SDK, зависимости, запрошенные разрешения и связанные с ними риски приватности.
Что проверяется в ходе анализа
Восемь направлений, сгруппированных по четырём контурам — от архитектуры приложения до серверной логики. В согласованном профиле каждое направление превращается в конкретный перечень контролей MASVS.
Приложение и данные
- ✓Архитектура и модель угрозС чего начинается проверка: что приложение хранит, кому доверяет и что теряет при компрометации устройства.
- ✓Локальное хранение и утечки через ОСФайлы, базы, кеш, логи, буфер обмена, снимки экрана и резервные копии.
Криптография и доступ
- ✓Криптография и управление ключамиАлгоритмы, генерация и хранение ключей, использование Keychain и Keystore.
- ✓Аутентификация, биометрия и сессииВход, токены, время жизни сессии, повторная аутентификация и корректный выход.
Платформа и сеть
- ✓Сетевое взаимодействие и TLSНастройка TLS, проверка сертификатов и содержимое реального трафика приложения.
- ✓IPC, deep links, WebView и разрешенияТочки входа на устройстве и запрошенные приложением права.
Устойчивость и сервер
- ✓Реверс, tampering и runtime-инструментацияНасколько дорого разобрать, изменить и запустить приложение в изменённом окружении.
- ✓API, бизнес-логика и сторонние SDKСерверная авторизация, доступ к объектам, критичные операции и внешние компоненты.
Клиент нельзя считать доверенной зоной. Поэтому каждое направление проверяется в двух режимах: как приложение ведёт себя на обычном устройстве — и что меняется, когда устройство имеет root или jailbreak, а сборка изменена.
Как проходит проект
Шесть этапов: от согласования профиля до подтверждения исправлений. Команда заказчика видит промежуточные результаты по ходу работы, а не только финальный документ.
- 1
Скоупинг и профиль проверки
Согласуем платформы, сборки, роли, backend, тестовые данные и глубину проверки по модели угроз.
- 2
Статический анализ
Изучаем манифест, права, код, ресурсы, зависимости и конфигурацию сборки.
- 3
Динамический анализ
Наблюдаем файловую систему, память, журналы, межпроцессное взаимодействие и сетевой трафик на работающем приложении.
- 4
Проверка защитных механизмов
Оцениваем хранение, криптографию, аутентификацию и устойчивость к подмене и запуску в изменённом окружении.
- 5
Тестирование API и логики
Проверяем серверную авторизацию, доступ к объектам, роли и критичные операции — со стороны изменённого клиента.
без разрушительных действий - 6
Отчёт и повторная проверка
Передаём находки отдельно по клиенту и по backend, разбираем их с командой, затем подтверждаем исправления.
Re-test входит в работу. После правок мы проверяем именно те находки, которые команда закрыла, — и фиксируем результат письменно. Это важно, когда исправления нужно предъявить корпоративному заказчику или магазину приложений.
Что заказчик получает в отчёте
Документ рассчитан на две аудитории сразу: мобильную и серверную команды — чтобы каждая сразу видела свою часть работы, а руководитель — общую картину.
-
Покрытие MASVS/MASTG
Перечень выполненных контролей и тестов в согласованном профиле — видно не только что нашли, но и что проверяли.
-
Реестр уязвимостей
Доказательства, влияние, затронутая платформа и конкретные рекомендации по каждой находке.
-
Разделение client / backend
Понятно, где требуется исправление мобильной команды, а где — серверной. Задачи не «зависают» между отделами.
-
Чек-лист релиза
Контрольные проверки для сборки, QA и публикации — чтобы закрытые вопросы не возвращались в следующей версии.
Что вы получаете по итогам работ
Отчёт собран так, чтобы им можно было пользоваться на двух уровнях: руководству — картина риска и приоритеты, командам ИТ и ИБ — конкретные хосты, права и настройки.
- Карта внутренней поверхности атаки
Ключевые активы, зоны доверия и проблемные взаимодействия между сегментами.
- Реестр технических проблем
Уязвимости, ошибки конфигурации и избыточные права — с оценкой значимости и владельцем.
- Сценарии развития инцидента
Понятные цепочки от исходной точки до критичных ресурсов — шаг за шагом.
- План hardening
Приоритетные настройки, сегментация, контроль привилегий и мониторинг — в порядке выполнения.
Цепочку разрывает шаг 2: закрытие административного SMB-доступа из пользовательского сегмента.
Пример оформления. Названия систем и цифры условные.
Почему работу важно повторять или актуализировать
Мобильные приложения, сторонние компоненты и операционные системы постоянно обновляются. Проверка, актуальная полгода назад, могла относиться к другой сборке, другому набору SDK и другой версии платформы — поэтому анализ имеет смысл привязывать к событиям в жизни продукта, а не к календарю.
-
Перед крупными релизами
-
После изменения механизмов аутентификации и API
-
При существенном обновлении сторонних SDK
-
При адаптации к новым версиям Android и iOS
Клиент может быть изучен и изменён — поэтому критичные решения должны проверяться на сервере
Расскажите, что за приложение, какие данные оно обрабатывает и на каком этапе находится релиз, — предложим профиль проверки и объём работ под вашу модель угроз.