На последнем мобильном пентесте клиент прислал PDF - OWASP MASVS v1.5.0, русский перевод - и попросил «пройтись по всем пунктам». Часть контролей оказалось невозможно проверить без доступа к исходному коду, ещё часть дублировала требования ASVS к бэкенду. Итого: треть чеклиста помечена «N/A», клиент недоволен, тимлид объясняет, что стандарт - не чеклист для black box. Ситуация повторяется на каждом втором engagement, связанном с MASVS. Версия 1.5.0 - финальный релиз перед масштабной перестройкой стандарта в v2.0.0, и от пентестера требуется чётко понимать: что в ней работает, где ограничения и как скоро правила игры изменятся.
Контекст MASVS v1.5.0: последняя версия перед перестройкой стандарта
MASVS v1.5.0 - финальная точка линейки v1.x. MASTG (Mobile Application Security Testing Guide) той же версии до сих пор ссылается именно на этот стандарт, и связка MASVS v1.5.0 + MASTG v1.5.0 остаётся рабочим инструментом для большинства мобильных пентестов.
Проект OWASP MAS (Mobile Application Security) прошёл ребрендинг в августе 2022 года: из «OWASP MSTG project» стал «OWASP MAS project». MSTG переименовали в MASTG, всё семейство ресурсов получило единый префикс MAS. Параллельно появился MASWE (Mobile Application Security Weakness Enumeration) - в v2.0.0 он станет мостом между MASVS и MASTG. По данным mas.owasp.org, в v2.0.0 привычные уровни верификации (L1, L2, R) убраны полностью и заменены на «MAS Testing Profiles», перенесённые в MASWE.
Для мобильного пентестера: пока клиент в ТЗ ссылается на MASVS v1 (а так делает подавляющее большинство), чеклист строится по v1.5.0. Переход на v2 изменит методологию принципиально - готовиться стоит, но работать нужно с тем, что есть.
Контроли безопасности MASVS v1.5.0 и маппинг на MITRE ATT&CK
MASVS v1.5.0 содержит восемь групп контролей, структурированных по поверхности атаки мобильного приложения: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE и MASVS-PRIVACY.Ни один русскоязычный источник не связывает эти группы с конкретными техниками MITRE ATT&CK - а зря, потому что именно такой маппинг даёт операционный контекст: что атакующий получает, если контроль не реализован.
| MASVS-группа | MITRE ATT&CK | Что проверяется на пентесте |
|---|---|---|
| MASVS-STORAGE | T1552 Unsecured Credentials | Открытый текст в SharedPreferences, SQLite, логах, Keychain |
| MASVS-CRYPTO | T1552.004 Private Keys | Хардкод ключей, MD5/SHA1, отсутствие ротации |
| MASVS-NETWORK | T1573 Encrypted Channel | TLS-конфигурация, certificate pinning, cleartext HTTP |
| MASVS-PLATFORM | T1056.001 Keylogging | WebView-инъекции, IPC (intents, URL schemes), deep links |
| MASVS-RESILIENCE | T1027 Obfuscated Files, T1553.002 Code Signing | Обфускация, anti-tamper, root/jailbreak-детект |
| MASVS-AUTH | - (оверлап с ASVS) | Биометрия, MFA, серверная валидация сессий |
| MASVS-CODE | - | Зависимости, обработка ошибок, безопасность сборки |
| MASVS-PRIVACY | - | Минимизация данных, трекеры, согласие пользователя |
Хранение и криптография: MASVS-STORAGE и MASVS-CRYPTO
MASVS-STORAGE - первое, что проверяется на каждом engagement. Контроли требуют: чувствительные данные в KeyStore (Android) или Keychain (iOS), базы данных зашифрованы, в логах и бэкапах нет открытого текста.Начинаю с
Сеть и аутентификация: MASVS-NETWORK и MASVS-AUTH
MASVS-NETWORK - TLS-конфигурация, certificate pinning и отсутствие cleartext-трафика. В терминах MITRE ATT&CK - противодействие T1573 (Encrypted Channel): если приложение не пиннит сертификат, атакующий с позиции MitM перехватывает «зашифрованный» канал, подставив свой CA.Проверка через Burp Suite с кастомным CA-сертификатом на устройстве - основная процедура. Если трафик перехватывается без дополнительных манипуляций - pinning отсутствует. Для обхода пиннинга в защищённых приложениях -
objection с командой android sslpinning disable или специализированный Frida-скрипт, адаптированный под конкретную реализацию (OkHttp, TrustManager, Network Security Config).MASVS-AUTH покрывает серверную валидацию сессий, биометрию и MFA. Тут стандарт безопасности мобильных приложений v1.5.0 пересекается с ASVS. Карлос Хольгера, со-лидер проекта OWASP MAS, в интервью NowSecure прямо указывал на «clear overlap with the ASVS, which is much more thorough for various backend vulnerabilities»«Явное совпадение с ASVS, который гораздо тщательнее проверяет различные уязвимости бэкэнда». На мобильном пентесте AUTH-контроли чаще закрываются через тестирование API: подмена токенов, IDOR, brute-force OTP - зона ASVS, но формально входит и в MASVS. Получается двойной учёт: одну и ту же проверку можно записать в оба стандарта, а клиент думает, что получил два независимых слоя защиты.
Платформа, код и устойчивость к реверсу
MASVS-PLATFORM проверяет взаимодействие с ОС: конфигурация WebView, IPC-механизмы (Android intents, iOS URL schemes), deep links. Exported activity без проверки вызывающего компонента или WebView с включённымaddJavascriptInterface - классика для эксфильтрации данных и выполнения произвольного кода.MASVS-CODE - обновления зависимостей, обработка ошибок, отсутствие debug-флагов в продакшн-сборке. MobSF закрывает большую часть статических проверок этой группы.
MASVS-RESILIENCE - группа, вызывающая больше всего споров. Она требует обфускации, root/jailbreak-детекта, anti-debugging. Маппинг на MITRE ATT&CK: T1027 (Obfuscated Files or Information) и T1553.002 (Code Signing). На пентесте проверка RESILIENCE сводится к попытке обойти защиты:
- Подключить Frida к процессу
- Пропатчить APK через
apktool - Переподписать
- Запустить на рутованном устройстве
MagiskHide - ну, разработчики хотя бы попытались. Спойлер: обычно не попытались.MASVS-PRIVACY - группа, добавленная в поздних версиях v1.x. Минимизация данных, трекеры, согласие. На пентесте проверяется анализом трафика при первом запуске приложения до принятия privacy policy.
Уровни верификации MASVS L1, L2 и R: как выбрать скоуп мобильного пентеста
MASVS v1.5.0 определяет три уровня, и от выбора зависит объём работ.| Уровень | Для каких приложений | Что добавляется к скоупу |
|---|---|---|
| MASVS-L1 | Все мобильные приложения | Базовые контроли: хранение, крипто, сеть, платформа, код |
| MASVS-L2 | Финтех, здравоохранение, PII | Threat model, глубокая аутентификация, усиленная криптография |
| MASVS-R | IP-защита, высокорисковый клиент | Обфускация, anti-tamper, anti-debug, root-детект |
По данным Zimperium, MASVS-L1 рекомендуется как baseline для любого мобильного приложения. MASVS-L2 применяется, когда возможные потери от компрометации значительно превышают стоимость внедрения расширенных контролей безопасности. MASVS-R релевантен для финансовых приложений, игровых клиентов и приложений с интеллектуальной собственностью.
Решение об уровне принимает владелец продукта, но пентестер обязан объяснить последствия. Если клиент заказал L1 для мобильного банка - результат формально корректен, но бесполезен. Всё равно что проверить замки на двери, проигнорировав открытое окно на первом этаже.
Рекомендация: в scope-документе фиксировать уровень явно. Если клиент не определился - предлагать L1+R для финтеха, L1 для всего остального. L2 без L1 не имеет смысла: он расширяет базовый уровень, а не заменяет.
MASVS v1.5.0 в мобильном пентесте: от стандарта к рабочему чеклисту
OWASP предоставляет MAS Checklist - табличный документ, связывающий контроли MASVS с тест-кейсами MASTG. На engagement этот чеклист - основа отчёта: контроль, тест, результат, доказательство.
Рабочий процесс верификации безопасности мобильных приложений:
- Зафиксировать целевой уровень (L1/L2/R) в scope-документе с указанием версии MASVS
- Скачать MAS Checklist с mas.owasp.org - версия привязана к конкретным коммитам MASVS и MASTG
- Развернуть окружение: рутованный Android-эмулятор или jailbroken iOS, Burp Suite с CA, Frida, objection, jadx, MobSF
- Проходить группу за группой, выполняя тест-кейсы MASTG
- Фиксировать проваленные контроли с доказательствами - скриншот, лог Frida, перехваченный запрос
Переход на MASVS v2.0.0: что меняется для мобильного пентестера
MASVS v2.0.0 - не инкрементальный патч, а пересборка с нуля. Ключевые изменения, описанные со-лидером проекта MAS Карлосом Хольгерой в интервью NowSecure:MASVS-ARCH удалена. Группа «Architecture, Design and Threat Modeling» содержала контроли, непроверяемые при внешнем тестировании. Для пентестера - плюс: меньше строк с «N/A» в отчёте. Наконец-то.
Оверлапы с ASVS устранены. Бэкенд-контроли вынесены из скоупа. MASVS v2.0 фокусируется строго на клиентской стороне мобильного приложения.
Контроли переформулированы. Каждый начинается с «The app...», используется позитивная формулировка. Терминология приведена к стандартам NIST-SP 800-175B и CWE. Цель - убрать неоднозначность: одинаковая формулировка должна одинаково интерпретироваться разными тестировщиками. На бумаге - красиво. Посмотрим, как это будет работать, когда два пентестера прочитают один контроль и всё равно поймут его по-разному.
Уровни L1/L2/R убраны. Замена - MAS Testing Profiles в MASWE. На практике это переход от «пройти L1» к выбору набора weakness-паттернов. Пока MASTG v2.0.0 в разработке, MAS Checklist временно сохраняет старые уровни с привязкой к MASTG v1.
MASWE как новое звено. OWASP MASWE - перечень мобильных слабостей, аналог CWE, но для мобильных платформ. Он становится мостом: MASVS определяет «что», MASWE описывает «какие слабости», MASTG показывает «как проверять».
Для пентестера переходный период создаёт неопределённость. MASTG v1.5.0 привязан к MASVS v1.5.0, а MASTG v2.0.0 ещё не завершён. Рабочая стратегия: в scope-документе указывать версию стандарта явно - не «по OWASP MASVS», а «по OWASP MASVS v1.5.0». Защищает обе стороны от путаницы при смене версий.
Девять из десяти клиентов, которые просят «проверить по MASVS», не различают L1 и L2 и не имеют threat model для приложения. Они увидели аббревиатуру в требованиях регулятора или конкурента и включили её в ТЗ. Пентестер в этой ситуации становится переводчиком: объясняет, что MASVS-ARCH нельзя проверить извне, что половина AUTH-контролей - про бэкенд, и что RESILIENCE без threat model - бессмысленная трата бюджета.
Переход на v2.0.0 эту проблему не решит. Убрав уровни L1/L2/R, OWASP передаёт ответственность за формирование скоупа клиенту. В теории правильно - не все банковские приложения одинаково критичны. На практике - клиент без threat model теряет даже «L1» как отправную точку и приходит к пентестеру с MASWE-списком из сотен weakness: «а что из этого нам надо?».
Мой подход - не ждать, пока клиент разберётся в MAS Testing Profiles. Формировать скоуп самостоятельно на pre-engagement этапе, исходя из типа приложения, обрабатываемых данных и реальных угроз. MASVS - хороший чеклист, но плохая замена threat model. Пока индустрия не перестроится на v2.0.0, связка MASVS v1.5.0 + MASTG v1.5.0 остаётся тем инструментом, который стоит довести до автоматизма - потому что через год чеклист будет другим, а навык структурной верификации мобильного приложения останется. На WAPT эту связку разбирают на практике с реальными APK и лабами - если хочется не просто прочитать про контроли, а руками пройти весь цикл от
objection до финального отчёта.
Последнее редактирование модератором:
