Перейти к основному содержанию
Блог

Мобильные

Что строго проверяют на экспертизе мобильного приложения: MASVS, MASWE и OWASP Mobile Top 10

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

· 7 мин. чтения

Фото: Zuko.io Images, CC BY 2.0 · Wikimedia Commons

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

В этой статье разберём, на какие стандарты опирается мобильная экспертиза, и 9 находок из проверки нашего собственного продукта — Android- и iOS-приложений налогово-финансовой SaaS-платформы, написанных на Flutter. Все находки закрыты.

На какие стандарты опираются

В мобильной экспертизе обычно используются мобильные документы проекта OWASP:

  • OWASP MASVS (Mobile Application Security Verification Standard) — определяет, каким требованиям должно соответствовать приложение. Требования разбиты на группы: хранение данных (STORAGE), криптография (CRYPTO), аутентификация (AUTH), сеть (NETWORK), взаимодействие с платформой (PLATFORM), качество кода (CODE), устойчивость к реверс-инжинирингу (RESILIENCE) и приватность (PRIVACY).
  • OWASP MASTG (Mobile Application Security Testing Guide) — практическое руководство по проверке каждого требования.
  • OWASP MASWE (Mobile Application Security Weakness Enumeration) — пронумерованный перечень мобильных слабостей. В отчёте экспертизы находка обычно идёт с этим номером, например MASWE-0097 (не реализовано обнаружение root или jailbreak).
  • OWASP Mobile Top 10 (2024) — самые распространённые категории рисков, от M1 до M10. Находку часто привязывают и к ним, например M7 Insufficient Binary Protections.
  • CWE — общая классификация слабостей, особенно для вопросов криптографии и проверки сертификатов.

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

Что нашли на практике: 9 находок

Ниже — находки из отчёта экспертизы по нашему приложению, сгруппированные по уровню риска.

Android — высокий (HIGH)

  1. Не реализовано обнаружение root. Приложение работало на рутованном устройстве без каких-либо предупреждений. В отчёте отмечено как MASWE-0097 и OWASP Mobile Top 10 2024 M7.
  2. Чувствительные данные хранились во внутреннем хранилище без шифрования. Человек с правами root мог открыть папку приложения и прочитать токены.
  3. Не проверялась целостность приложения (tamper). Если APK пересобрать и установить с другой подписью, приложение этого не замечало.
  4. Недостаточная проверка сертификатов. Приложение принимало любой сертификат, которому доверяет система, то есть трафик можно было перехватить через установленный на устройство сторонний CA.
  5. Нет защиты от инструментов динамического анализа. С помощью Frida и подобных инструментов можно было менять функции приложения во время выполнения.

Android — средний (MEDIUM)

  1. Не реализовано обнаружение эмулятора. Приложение полноценно работало на эмуляторе, что упрощает анализ и автоматизированные атаки.

Android — низкий (LOW)

  1. Небезопасные (http) ссылки. В коде остались нешифрованные адреса.

iOS — высокий (HIGH)

  1. Нет защиты от динамического анализа. Как и на Android, iOS-приложение не обнаруживало инструменты перехвата вызовов.
  2. Не реализовано обнаружение jailbreak. Аналог root на iOS.

Как видно, большинство из 9 находок — не ошибки в коде, а отсутствие защитного слоя. Приложение работает правильно, но не защищает себя.

Как закрыли

Вместо отдельного решения под каждую находку применили несколько взаимодополняющих слоёв:

  • RASP-библиотека (freeRASP) — обнаруживает root, jailbreak, эмулятор, хуки, отладчик и модификацию приложения. При обнаружении угрозы пользователю показывается блокирующий экран с предупреждением.
  • Закрепление сертификатов — приложение доверяет только выбранным корневым CA: на стороне Dart SecurityContext только с доверенными корнями, на Android — pin-set в network_security_config.
  • Безопасное хранение — flutter_secure_storage поверх Android Keystore и iOS Keychain.
  • Обфускация — R8 minify для Android и --obfuscate для Dart-кода.
  • Защита от резервного копирования — allowBackup=false и data_extraction_rules.
  • Сеть — cleartext (http) трафик полностью отключён, адреса API не хранятся в коде открытыми строками.
  • Очистка при выходе — данные WebView удаляются, когда пользователь выходит из системы.

По каждой из этих тем в блоге есть отдельная статья: обнаружение root/jailbreak, SSL pinning, Keystore и Keychain, Frida и RASP.

Что ещё нужно перед подачей на экспертизу

Экспертиза также запрашивает контрольные суммы поданных APK и IPA: MD5, SHA1 и SHA256. Они нужны, чтобы подтвердить, что проверенный файл — именно тот, который выйдет в магазин. Получить их можно простыми командами:

md5sum app-release.apk
sha1sum app-release.apk
sha256sum app-release.apk

На macOS используются shasum -a 1 и shasum -a 256. Помните: при пересборке файла значения меняются, поэтому берите контрольные суммы именно с финальной сборки, которую подаёте.

Практический чек-лист

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

  1. Что делает приложение на устройстве с root или jailbreak?
  2. Запускается ли оно на эмуляторе и ожидаемо ли это?
  3. Где хранятся токены, пароли или персональные данные — в SharedPreferences, UserDefaults или в Keystore/Keychain?
  4. Можно ли перехватить трафик, если установить на устройство сторонний CA?
  5. Заметит ли приложение, что APK пересобран с другой подписью?
  6. Остались ли в коде адреса, начинающиеся с http://?
  7. Обфусцирована ли релизная сборка?
  8. Отключён ли allowBackup?

Если ответ на любой из этих вопросов неочевиден, экспертиза найдёт именно это место.

Вывод

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

Если хотите узнать, насколько ваше приложение готово к экспертизе, оставьте заявку на сканирование. Claude AI агент и наш специалист изучат APK или IPA, покажут найденные уязвимости и помогут их закрыть.