OWASP Mobile Top 10 (2024): от M1 до M10 и что экспертиза проверяет в каждой категории

Если открыть отчёт экспертизы мобильного приложения, рядом с каждой находкой часто стоят две ссылки: идентификатор MASVS/MASWE и категория OWASP Mobile Top 10. Например, в отчёте по нашему собственному приложению находка «не реализовано обнаружение root» была помечена как MASWE-0097 и M7 (Insufficient Binary Protections). Mobile Top 10 — это список самых важных категорий рисков мобильных приложений; его составляет команда OWASP, последняя редакция вышла в 2024 году.

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

Как используется список

Mobile Top 10 — не стандарт и не методика тестирования, а карта рисков. Практическая проверка ведётся по OWASP MASVS (требования), MASTG (методы тестирования) и MASWE (каталог слабостей). А Top 10 раскладывает находки по понятным категориям и помогает расставить приоритеты. Поэтому при подготовке приложения к экспертизе Top 10 — хороший стартовый чек-лист.

M1: Improper Credential Usage

Что это: неправильное использование ключей, паролей и токенов — API-ключи в коде, общий статический токен для всех пользователей, хранение или передача учётных данных в открытом виде.

Что проверяет экспертиза: APK/IPA декомпилируется, в строках ищутся ключи, пароли, токены; отслеживается, какие учётные данные передаются между приложением и сервером.

Проверьте сами:

jadx -d out app-release.apk
grep -rniE "api[_-]?key|secret|password|bearer" out/
strings -n 8 lib/arm64-v8a/libapp.so | grep -iE "key|secret"

Исправление: секретные ключи только на сервере, приложение обращается к backend с короткоживущим токеном пользователя. Подробнее: ключи внутри APK и IPA.

M2: Inadequate Supply Chain Security

Что это: риск, приходящий через сторонние библиотеки, SDK и процесс сборки: уязвимые или заброшенные пакеты, недоверенные источники, незащищённый CI и ключи подписи.

Что проверяет экспертиза: библиотеки в приложении и их версии, компоненты с известными уязвимостями, лишние SDK (например, рекламные или аналитические, запрашивающие избыточные разрешения).

Проверьте сами: во Flutter — flutter pub outdated, на Android — ./gradlew app:dependencies, на iOS — просмотрите Podfile.lock. Для каждой зависимости: кто её поддерживает, когда было последнее обновление, действительно ли она нужна.

Исправление: lock-файлы в репозитории, зависимости регулярно обновляются, неиспользуемые SDK удалены, ключ release-подписи хранится в безопасном месте (Google Play App Signing или защищённые секреты CI).

M3: Insecure Authentication/Authorization

Что это: ошибки аутентификации и проверки прав — важные решения принимаются только в приложении, сервер не проверяет права, слабое управление сессией, PIN или биометрия применяются только на уровне UI.

Что проверяет экспертиза: API-запросы повторяются с идентификатором другого пользователя (IDOR), проверки внутри приложения отключаются через Frida, экспортированные экраны открываются без входа, проверяется срок жизни токена и его состояние после выхода.

Проверьте сами: отправьте через прокси свой запрос с ID другого пользователя; после выхода вызовите API старым токеном.

Исправление: права проверяются на сервере в каждом запросе, токены короткоживущие и аннулируются на сервере при выходе. Подробнее: IDOR и ошибки авторизации, deep link и экспортированные компоненты.

M4: Insufficient Input/Output Validation

Что это: данные извне (ввод пользователя, deep link, intent, ответ сервера, QR-код) используются без проверки. Результат — XSS в WebView, локальная SQL-инъекция, path traversal, открытие не той страницы внутри приложения.

Что проверяет экспертиза: параметры deep link и intent, URL, передаваемые в WebView, локальные запросы SQLite, работа с именами файлов.

Проверьте сами:

adb shell am start -a android.intent.action.VIEW \
  -d "myapp://open?url=https://evil.example.com"

Исправление: allowlist для каждого внешнего входа, в SQLite только параметризованные запросы, навигация WebView ограничена, на сервере та же валидация. Подробнее: безопасность WebView.

M5: Insecure Communication

Что это: недостаточная защита сетевого взаимодействия — использование http, неправильная проверка сертификата, игнорирование ошибок SSL, отсутствие pinning.

Что проверяет экспертиза: трафик перехватывается через прокси; принимает ли приложение сертификат прокси, есть ли ссылки http, есть ли proceed() в onReceivedSslError. В отчёте по нашему приложению здесь было две находки: небезопасная проверка сертификата (высокий риск) и ссылки http (низкий риск).

Проверьте сами: установите на устройство сертификат Burp или mitmproxy и поработайте с приложением. При правильном pinning запросы должны завершаться ошибкой.

Исправление: на Android — network_security_config с отключённым cleartext и pin-set, во Flutter — SecurityContext только с доверенными корневыми сертификатами, на iOS — без исключений ATS:

<base-config cleartextTrafficPermitted="false" />

Подробнее: SSL pinning, allowBackup и cleartext.

M6: Inadequate Privacy Controls

Что это: персональные данные (ФИО, телефон, ПИНФЛ, геолокация, документы) собираются сверх необходимого, пишутся в логи, отправляются в сторонние SDK или видны на снимках экрана и в уведомлениях.

Что проверяет экспертиза: запрашиваемые разрешения, персональные данные в логах (adb logcat), что уходит в аналитику, что остаётся на экране при уходе приложения в фон.

Проверьте сами:

adb logcat | grep -iE "token|phone|password|passport"

Исправление: только необходимые разрешения и данные, логи в release отключены, на чувствительных экранах ограничены снимки экрана (FLAG_SECURE на Android), персональные данные в аналитику не отправляются.

M7: Insufficient Binary Protections

Что это: бинарник приложения не защищён от обратной разработки и модификации: нет обфускации, не обнаруживаются root/jailbreak и эмулятор, нет противодействия инструментам динамического анализа вроде Frida, не проверяется целостность (tamper).

Что проверяет экспертиза: в нашем опыте это категория с наибольшим числом находок. На Android отсутствие обнаружения root, проверки целостности и защиты от динамического анализа было отмечено как высокий риск, отсутствие обнаружения эмулятора — как средний; на iOS высоким риском было отсутствие обнаружения jailbreak и защиты от динамического анализа.

Проверьте сами: запустите release-сборку на рутованном устройстве или эмуляторе, подключитесь через frida-server, переподпишите и установите APK. Приложение должно обнаружить каждую из ситуаций.

Исправление: RASP-библиотека (мы использовали freeRASP) с блокирующим экраном, R8 minify и обфускация Dart:

flutter build apk --release --obfuscate --split-debug-info=build/symbols

Подробнее: обнаружение root и jailbreak, Frida и RASP, целостность приложения и обфускация.

M8: Security Misconfiguration

Что это: ошибки в настройках платформы и приложения — debuggable=true, allowBackup=true, лишние экспортированные компоненты, избыточные разрешения, включённая отладка WebView в release, неправильные права на файлы.

Что проверяет экспертиза: merged-манифест, Info.plist, entitlements, типы сборок.

Проверьте сами:

apktool d app-release.apk -o app_src
grep -nE 'debuggable|allowBackup|exported="true"|usesCleartextTraffic' app_src/AndroidManifest.xml

Исправление: в release нет debuggable, allowBackup="false" и dataExtractionRules, экспортированы только необходимые компоненты, запрашиваются только необходимые разрешения.

M9: Insecure Data Storage

Что это: чувствительные данные хранятся на устройстве без защиты — токен в SharedPreferences или NSUserDefaults, незашифрованный SQLite, персональные файлы в кеше, cookie WebView после выхода, данные, попадающие в резервную копию.

Что проверяет экспертиза: внутренняя папка приложения (/data/data/<пакет>/) просматривается на рутованном устройстве. В нашем приложении здесь была находка высокого риска «чувствительные данные хранятся во внутреннем хранилище в незашифрованном виде».

Проверьте сами:

adb shell run-as uz.example.app ls -R /data/data/uz.example.app/
adb shell run-as uz.example.app cat shared_prefs/FlutterSharedPreferences.xml

(run-as работает только с debug-сборкой; release проверяйте на рутованном тестовом устройстве.)

Исправление: токены и секреты — в Keystore/Keychain (во Flutter — flutter_secure_storage), при выходе очищаются все локальные данные и данные WebView. Подробнее: Keystore и Keychain.

M10: Insufficient Cryptography

Что это: неправильное использование криптографии — устаревшие алгоритмы (MD5 или SHA1 для паролей, DES, режим ECB), ключи в коде, постоянный IV, собственный «алгоритм шифрования», генерация ключа через Random.

Что проверяет экспертиза: в декомпилированном коде — Cipher.getInstance, MessageDigest, откуда берутся ключ и IV.

Проверьте сами:

grep -rnE 'AES/ECB|DES|MD5|SHA1|SecretKeySpec' out/sources

Исправление: AES-GCM, ключи создаются и хранятся в Keystore/Keychain, IV каждый раз случайный, пароли хешируются только на сервере через bcrypt/Argon2. Лучше всего — не писать криптографию самому, а опираться на платформу и проверенные библиотеки.

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

Короткий чек-лист перед экспертизой

• M1: в приложении нет секретных ключей и общего статического токена.
• M2: зависимости обновлены, неиспользуемые SDK удалены.
• M3: права проверяются на сервере, токены аннулируются при выходе.
• M4: входы deep link, intent и WebView проверяются по allowlist.
• M5: cleartext отключён, pinning работает, ошибки SSL не игнорируются.
• M6: в логах и аналитике нет персональных данных, разрешения минимальны.
• M7: RASP (root/jailbreak, эмулятор, hook, debugger, tamper), обфускация включена.
• M8: нет debuggable, allowBackup="false", экспорт компонентов обоснован.
• M9: секреты в Keystore/Keychain, при выходе всё очищается.
• M10: современные алгоритмы, нет ключей в коде, случайный IV.

Вывод

OWASP Mobile Top 10 (2024) раскладывает безопасность приложения на десять понятных вопросов. Почти каждая находка в отчёте экспертизы попадает в одну из этих категорий, поэтому пройти список по пунктам до экспертизы — самый правильный способ уменьшить число находок. По нашему опыту, чаще всего упускают M7 и M9: их не планируют в обычном процессе разработки, но эксперт проверяет их в первую очередь. Общий обзор процесса: что проверяют на экспертизе мобильного приложения.

Если хотите пройти своё приложение от M1 до M10 до экспертизы, оставьте заявку на сканирование. Claude AI агент быстро проанализирует код, манифест и бинарник, а наш специалист подтвердит каждую находку на устройстве и поможет её закрыть.