На аудите Android-приложения для одного из банков клиент запросил «проверку на L2 по MASVS». Открываю актуальную версию стандарта - уровней L1, L2 и R в нём больше нет. OWASP убрал их в MASVS v2.0.0, наметив переход к системе Testing Profiles, которые планируется формализовать в MASTG. Разговор о скоупе затянулся на два часа: клиент оперировал терминами из v1.5.0, а стандарт жил по другим правилам. Ситуация типичная - OWASP MASVS обновление вышло весной 2023 года, но многие команды до сих пор строят чеклисты по старой версии. И потом удивляются, почему отчёт не маппится ни на что актуальное.
Почему OWASP пересмотрел стандарт безопасности мобильных приложений
Предыдущая версия MASVS (v1.5.0) копила проблемы несколько лет. С позиции мобильного пентестера, три вещи раздражали больше всего. Архитектура мобильных ОС изменилась. Защитные механизмы стали стандартом из коробоки. Разделение на "обычное" и "защищённое" приложение потеряло смысл.
Пересечения между контролями. Одно и то же требование формулировалось в разных разделах с минимальными вариациями. При составлении отчёта приходилось решать, куда вписать находку - в STORAGE или в CRYPTO - и часто это был вопрос вкуса, а не методологии. Пересказывать спеку в сотый раз не вижу смысла, но поверьте - дублирование было повсюду.
Нетестируемые контроли. Раздел MASVS-ARCH описывал архитектурные рекомендации и процессы governance. При внешнем аудите мобильного приложения у пентестера нет доступа к процессу разработки - только к результату. Эти контроли создавали видимость полноты, но верифицировать их на практике невозможно. Красивый фантик без содержимого.
Жёсткая привязка тестов к уровням. L1 означал «базовый», L2 - «для чувствительных данных», R - «устойчивость к реверсу». Одно и то же приложение могло требовать L2 по хранилищу и L1 по сетевому взаимодействию - стандарт такую гранулярность не предусматривал. Тупо: один уровень на всё приложение, хочешь не хочешь.
При рефакторинге команда OWASP MAS поставила четыре задачи (озвученные в официальном релизе на mas.owasp.org):
- Сохранить абстракцию - детали тестирования оставить для MASTG.
- Упростить - убрать дублирование контролей.
- Навести терминологическую ясность - опираться на NIST SP 800-175B, NIST OSCAL, CWE.
- Сузить скоуп - архитектурные и процессные требования безопасности мобильных приложений делегировать OWASP SAMM и NIST SP 800-218 (SSDF).
MASVS 2.0 изменения: уровни L1/L2/R уступают место Testing Profiles
Самое заметное изменение в OWASP MASVS v2.0.0, и именно оно вызывает путаницу в индустрии.В v1.5.0 три уровня определяли скоуп тестирования:
- L1 - базовый, для любого приложения.
- L2 - глубокая проверка для приложений с чувствительными данными (финансы, здоровье).
- R - дополнительные требования к устойчивости против реверс-инжиниринга и тамперинга.
Логика: один контроль MASVS может приводить к разным тестам в зависимости от профиля приложения. Возьмём контроль MASVS-STORAGE-1 («The app securely stores sensitive data»): для базового профиля допустимо хранение в internal storage, для расширенного - ожидается шифрование. Контроль один, а проходные критерии разные. Одна формулировка - два совершенно разных теста.
MAS Testing Profiles выровнены с NIST OSCAL (Open Security Controls Assessment Language) - стандартный формат описания контролей безопасности, позволяющий обмениваться наборами контролей между организациями в машиночитаемом виде. Для мобильной безопасности OWASP это означает интеграцию с другими фреймворками без ручного перемаппинга. Кто хоть раз маппил контроли руками между двумя стандартами - оценит.
На практике подход к отчёту меняется: вместо «приложение соответствует/не соответствует L2» теперь «приложение проверено по профилю L2 для категорий STORAGE и NETWORK, профилю L1 для AUTH». Гранулярность выше, но отчёт структурировать сложнее - нужно согласовывать профили с клиентом до начала работ. Без этого на сдаче отчёта начнётся цирк.
Сравнение MASVS vs MASVS 2.0 в части скоупинга:
| Параметр | MASVS v1.5.0 | MASVS v2.0.0 |
|---|---|---|
| Определение глубины | Уровни L1/L2/R в самом стандарте | Testing Profiles в MASTG (в разработке) |
| Гранулярность | Один уровень на всё приложение | Профиль per категория контролей |
| Формат | Текстовый документ | Выровнен с NIST OSCAL |
| Серверная аутентификация | Внутри MASVS | Делегирована OWASP ASVS |
| Архитектурные контроли | MASVS-ARCH (нетестируемые) | Удалены, делегированы SAMM/NIST SSDF |
MASVS контроли безопасности: новая структура в v2.0.0
OWASP MASVS v2.0.0 делит атакуемую поверхность мобильного приложения на контрольные группы. Каждая маркируется как MASVS-XXXXX, а индивидуальные контроли внутри - MASVS-XXXXX-Y.
| Группа | Покрытие | Что изменилось в v2.0.0 |
|---|---|---|
| MASVS-STORAGE | Хранение данных на устройстве (data-at-rest): KeyStore/Keychain, шифрованные БД, отсутствие открытого текста в sandbox | Упрощена до 2 контролей из десятка |
| MASVS-CRYPTO | Криптография: генерация ключей, отсутствие hardcoded-ключей, корректные алгоритмы | Выровнена с NIST SP 800-175B и SP 800-57 |
| MASVS-AUTH | Аутентификация: биометрия, MFA, валидация сессий, хранение токенов | Разделена на клиентскую и серверную; серверная делегирована OWASP ASVS |
| MASVS-NETWORK | Сетевое взаимодействие: TLS, certificate pinning, запрет clear-text HTTP | Однозначная позиция: pinning обязателен для максимальной безопасности канала |
| MASVS-PLATFORM | Взаимодействие с платформой: WebView, IPC, deep links, Android intents, iOS URL schemes | Без радикальных изменений, уточнения формулировок |
| MASVS-CODE | Качество кода, обработка данных, актуальность приложения | Минимальные изменения |
| MASVS-RESILIENCE | Устойчивость к реверсу и тамперингу | 13 требований v1.5.0 сжаты в 4 абстрактных контроля |
По данным документации OWASP MAS, позднее добавилась группа MASVS-PRIVACY - требования к приватности пользовательских данных. Она не входила в первоначальный релиз v2.0.0, но является частью актуальной модели стандарта.
Что это значит для пентестера на практике:
MASVS-STORAGE - группа, которая раньше содержала десяток контролей, сведена к двум. Проверок не стало меньше - конкретные тесты переехали в MASTG. Но в отчёте пентестер оперирует двумя высокоуровневыми контролями, а не десятком пересекающихся. То же самое с MASVS-CRYPTO - два контроля вместо россыпи. Жить стало проще.
MASVS-AUTH - чёткое разделение: клиентская аутентификация (биометрия, локальный PIN) остаётся в MASVS, серверная делегирована OWASP ASVS. Логично: API-бэкенд проверяется по другому стандарту, пентестер мобильного приложения фокусируется на клиентской части. Раньше это была серая зона - теперь граница проведена.
MASVS-NETWORK - по данным Approov, в v2.0.0 OWASP однозначно заявил: certificate pinning обязателен для максимального уровня безопасности канала. В v1.5.0 формулировки были размытыми, и некоторые команды ссылались на рекомендации Apple и Google (которые сами по себе противоречивы) как на основание не реализовывать пиннинг. Двусмысленность устранена. Попробуй теперь отмазаться.
MASVS-RESILIENCE: что проверять на мобильном пентесте
Группа MASVS-RESILIENCE описывает противодействие тем техникам, которые пентестер использует ежедневно - поэтому она заслуживает отдельного разбора.В v1.5.0 раздел «V8: Resilience Requirements» содержал 13 специфичных требований. В v2.0.0 они сведены к четырём абстрактным контролям. По данным Digital.ai, каждый контроль настолько абстрактен, что покрывает не только существующие, но и будущие векторы атак - конкретика вынесена в MASTG.
MASVS-RESILIENCE-1 - валидация целостности платформы. Приложение проверяет: рутован/джейлбрейкнут ли девайс, запущено ли оно в эмуляторе или виртуализаторе, установлены ли потенциально вредоносные приложения. Маппится на Subvert Trust Controls (T1553, Defense Evasion) по MITRE ATT&CK.
MASVS-RESILIENCE-2 - защита от тамперинга: проверка подписи пакета, валидация целостности DEX-кода и нативных библиотек, проверка ресурсов. Маппится на Code Signing (T1553.002, Defense Evasion).
MASVS-RESILIENCE-3 - защита от статического анализа: обфускация, шифрование строк, control flow flattening, удаление символов, инъекция мёртвого кода. Маппится на Obfuscated Files or Information (T1027, Defense Evasion).
MASVS-RESILIENCE-4 - защита от динамического анализа: детекция дебаггера, обнаружение Frida и аналогичных фреймворков, детекция hooking и swizzling.
На практике проверка RESILIENCE-4 начинается с подключения Frida к целевому приложению:
Bash:
frida -U -f com.target.appДля RESILIENCE-3 - распаковка APK и анализ читаемости классов:
Bash:
apktool d target.apk -o decoded_app
jadx -d jadx_output/ target.apka.b.c() и зашифрованных строк, а не как учебник по Java.В v2.0.0 зафиксирована позиция: обфускация необходима, но недостаточна. Approov отмечает новый акцент на защите от динамического анализа и runtime-тамперинга - эволюция по сравнению с v1.5.0, где основной упор был на статические меры. Правильное направление: статический анализ обходится проще, чем качественный anti-debug.
Маппинг MASVS на MITRE ATT&CK для мобильной безопасности
Верификация безопасности мобильных приложений: обновляем рабочий процесс
Переход на MASVS v2.0.0 - не одномоментное событие. OWASP сам признаёт «transition phase»: MASTG в версии v1.5.0 изначально оставался привязан к MASVS v1.5.0. Полная синхронизация MASTG с MASVS v2.0.0 потребовала времени, и команда продолжала работу над маппингом на протяжении 2023–2024 годов.Ключевая концепция нового MASTG - элементарные тесты. Старые крупные тест-кейсы разбиваются на мелкие управляемые блоки. Каждый целостный тест привязан к конкретному контролю MASVS и конкретному профилю (L1, L2, R). Это даёт гранулярную картину покрытия и упрощает применение профилей к конкретному типу приложения. Вместо монолитного «проверить хранение данных» - набор точечных проверок, каждая с чётким pass/fail.
Ещё одно пополнение - MASWE (Mobile Application Security Weakness Enumeration). Согласно официальной странице OWASP MAS, MASWE - перечень типовых уязвимостей и проблем приватности мобильных приложений, который служит мостом между MASVS (что проверять) и MASTG (как проверять). По сути, MASWE делает для мобильного AppSec то же, что CWE для веба - стандартизирует описание слабостей.
Для обновления пентест-процесса под MASTG и MASVS 2024 рекомендую три шага:
- Скачать актуальный чеклист с mas.owasp.org. Чеклист объединяет все категории MASVS в одну таблицу с трассируемостью до конкретных версий MASVS и MASTG. Поддерживает добавление колонок - можно расширить под формат отчёта вашей компании.
- Перемаппить старые тесты на новые контроли. Если раньше чеклист содержал 15 пунктов по STORAGE, теперь их два - но каждый покрывается набором атомарных тестов из MASTG. Нужно убедиться, что все прежние проверки вошли в новые тесты и ни одна не потерялась при переходе. Потратьте на это день - это дешевле, чем обнаружить пробел на сдаче отчёта.
- Согласовать профили с клиентом до начала работ. Вместо «L1 или L2» обсуждение идёт по категориям: STORAGE-L2, NETWORK-L2, AUTH-L1, RESILIENCE-R. Это требует более детального скоупинга, но снижает риск недоразумений при сдаче отчёта. Я теперь включаю таблицу профилей в оффер - клиент подписывает конкретный скоуп, а не абстрактный «уровень».
За два года с момента выхода OWASP MASVS v2.0.0 наблюдаю одну и ту же картину: стандарт стал лучше, а его применение - хаотичнее. Команда OWASP MAS сделала правильные вещи: убрала нетестируемые контроли, разделила «что проверять» и «как проверять», выровнялась с NIST. На бумаге структура безупречна. В реальности - разрыв. На проектах команды нередко продолжают использовать чеклисты v1.5.0. Клиенты просят «L2-аудит», а объяснение про профили отнимает время, которое можно потратить на тестирование. Добавление MASWE как промежуточного звена - сильный ход, но вся эта система всё ещё собирается по частям.
Мой прогноз: к середине 2026 года переход завершится окончательно и MASVS v1.x перестанут упоминать даже в корпоративных тендерных документах. Кто сейчас пишет чеклисты под старую версию - остановитесь и потратьте день на перемаппинг. Это инвестиция, которая окупится на ближайшем проекте. А привязка контролей к ATT&CK-техникам, описанная выше, превращает отчёт по мобильному аудиту из формальной бумаги в документ, понятный SOC-команде заказчика. Попробуйте добавить колонку с ATT&CK ID в свой следующий отчёт - и посмотрите на реакцию.
Последнее редактирование модератором:
