Аудит корпоративного софта: оценка рисков и условий оплаты в мобильных приложениях

Каждый квартал на паблик выкладываются дампы клиентских баз, токенов сессий и платёжных идентификаторов, вытащенных из приложений, которые бизнес считал «защищёнными». Безопасники в телеграм-каналах пересылают друг другу скрины с утечками, заказчики кивают на отчёты интеграторов и требуют «провести аудит», а интеграторы радостно выставляют счёт за сканирование сканером. Результат предсказуем: формальный PDF, галочка в тендере и очередной инцидент через полгода.

Аудит безопасности мобильных приложений для бизнеса — это не ритуал и не строчка в бюджете. Это инженерная процедура, которую делают либо руками и головой, либо не делают вообще. Всё остальное — имитация.

Актуальные стандарты защиты: почему OWASP MASVS v2.1.0 стал отраслевым эталоном

В индустрии мобильной безопасности есть только один документ, к которому апеллируют без стыда: OWASP Mobile Application Security Verification Standard. Текущая редакция — v2.1.0, выпущенная в январе 2024 года. Всё, что старше, считается устаревшим, всё, что «допилено на отраслевом консалтинге под заказчика» — маркетинговой шелухой.

Архитектура стандарта перестроена в корне. Вместо прежних уровней L1, L2 и R (Resilience) в v2 введены профили тестирования MASTG — MAS-L1, MAS-L2, MAS-R. Старая логика «проверил на базовый уровень и успокоилась» больше не работает: профили формируются под конкретную модель угроз, а не под желание заказчика сэкономить. MAS-L1 — минимальный набор, который проходит любое приложение, работающее с пользовательскими данными. MAS-L2 — для финансовых, медицинских и корпоративных систем с повышенными требованиями. MAS-R — резистентность к целенаправленным атакам: anti-tampering, anti-debugging, защита среды исполнения.

Сам MASVS v2.1.0 оперирует 24 контролями безопасности, распределёнными по 8 категориям:

Появление MASVS-PRIVACY в v2.1.0 — это прямой ответ на регуляторное давление. Четыре контроля в этой категории закрывают вопросы согласия пользователя, минимизации сбора, прозрачности обработки и управления правами субъекта данных. Кто-то скажет «это GDPR в миниатюре», и будет недалеко от истины. Практика показывает, что подавляющее большинство корпоративных приложений в РФ эти четыре контроля осваивают только после публичного инцидента — а не на этапе проектирования, где им место.

Каждый из 24 контролов — это не абстрактное «должно быть», а конкретное техническое требование. MASVS-STORAGE-1 говорит: «Приложение не хранит чувствительные данные в незашифрованном виде». MASVS-CRYPTO-1: «Приложение не использует жёстко заданные криптографические ключи». MASVS-AUTH-1: «Приложение не использует небезопасные методы аутентификации». Звучит тривиально, но если пройтись по реальной кодовой базе корпоративного приложения с этими 24 пунктами, находок хватит на десяток страниц отчёта.

OWASP MASVS v2.1.0 — это не «один из стандартов», это единственный опорный документ, с которым работают профильные лаборатории. Всё остальное — производные.

Использовать MASVS как чек-лист «для галочки» — путь к формальному отчёту. Использовать его как карту угроз — путь к реальной защите. Разница в том, кто держит карту: аудитор, который понимает, что стоит за каждым контролем, или менеджер, который тикает галочки в Excel.

От MASVS к MASWE: как классификация уязвимостей помогает в проверке кода

В июле 2024 года OWASP выкатил Mobile App Security Weakness Enumeration — MASWE. Это структурированный каталог конкретных уязвимостей, который связывает высокоуровневые контроли MASVS с практическими тестами MASTG. До MASWE пентестеры работали по спискам «на своё усмотрение», и результат зависел от того, насколько хорошо конкретный аналитик помнит OWASP Top 10 Mobile. Теперь уязвимости каталогизированы, и аудитор сверяется с эталоном, а не с собственной памятью.

Структура MASWE — это иерархия. На верхнем уровне — категория (например, «криптография»), ниже — конкретная слабость (например, «использование устаревшего алгоритма хеширования»), и каждый слабости присваивается уникальный MASWE-идентификатор. Каталог работает как библиотека: аудитор находит проблему, привязывает её к MASWE-ID, и в отчёте вместо размытого «слабая криптография» появляется конкретная запись с описанием, классификацией и рекомендациями по исправлению.

Что это даёт на практике:

• Стандартизация терминологии. В отчёте больше не пишут «слабая криптография» — пишут конкретный MASWE-ID с описанием слабого места.
• Сопоставимость результатов. Заказчик может сравнить два отчёта от разных лабораторий по единой шкале.
• Снижение зависимости от аудитора. Новичок с MASWE-каталогом под рукой пропустит меньше, чем опытный аналитик без него.
• Приоритизация. Каждая слабость в MASWE связана с конкретным контролем MASVS, что позволяет сразу видеть, насколько критична находка.

В лабораторной работе MASWE используется как «корзина» для сортировки находок. По масштабу: аудит корпоративного мобильного приложения средней сложности обычно приносит десятки MASWE-идентификаторов — от утечек в логах до слабых криптопримитивов. Без классификации эта груда находок превращается в кашу из абзацев, которые невозможно приоритизировать. С MASWE заказчик видит: вот 12 находок в криптографии, вот 8 в хранении данных, вот 15 в сетевом взаимодействии — и может начинать с того, что болит сильнее.

Отдельный вопрос — верификация исправлений. MASWE позволяет провести повторный аудит по тому же каталогу: лаборатория проверяет, закрыты ли конкретные идентификаторы, и ставит статус «устранено» или «не устранено». Без этого механизма «закрытие уязвимостей» остаётся на уровне обещаний интегратора в письме заказчику.

Критические векторы атак: что именно ищут аудиторы в API и серверной части

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

Что ищут в API и серверной части:

1. IDOR (Insecure Direct Object Reference) — уязвимости авторизации. Замена одного идентификатора в запросе на чужой и доступ к чужому заказу/счёту/документу. Классика, которая живёт в корпоративных приложениях годами. OWASP MASVS фиксирует эту проблему в контролях категории MASVS-AUTH, но на практике её ловит только ручной анализ API.

2. Утечка токенов и PII в логах. Серверные логи любят писать всё подряд: заголовки, тела запросов, токены авторизации. Через полгода эти логи уезжают в ELK, оттуда — к подрядчику на аудите, оттуда — в паблик.

3. Несанитизированные данные в платёжных шлюзах. Прямой путь к компрометации транзакций. Слабое место — когда мобильное приложение шлёт сумму платежа со своей стороны, а сервер её не пересчитывает. Подмена суммы в Burp Suite занимает три секунды.

4. Захардкоженные учётные данные внешних сервисов. SMS-шлюзы, интеграции с 1С, платёжные провайдеры. Логин и пароль в коде, в конфигах, в комментариях к коммитам. Каждый такой ключ — дыра, через которую утекает вся экосистема.

5. Отсутствие rate limiting и аномальной активности. Без этих двух механизмов API отдаёт всё, что у него просят, сколько угодно раз в секунду. Это база для брутфорса, энумерации и автоматизированного вывода данных.

6. Недостаточная валидация серверной бизнес-логики. Типичный пример: проверка прав на клиенте (кнопка не отображается) при отсутствии проверки на сервере (эндпоинт отвечает без авторизации). Прямой путь к эскалации привилегий.

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

Практика показывает: в отчётах лабораторий доля находок на серверном API и интеграциях значительно превышает клиентские. Это объяснимо — серверная часть сложнее, интеграций больше, а проверяют её реже. Заказчики, которые заказывают «только аудит приложения» и экономят на backend-части, получают дырявый продукт с красивым отчётом. Экономия на серверном аудите — это не экономия, а осознанный выбор в пользу уязвимости.

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

Экономика безопасности: сравнение моделей Fixed Price и Time & Material

Деньги — единственное, что заказчик понимает быстрее, чем технический отчёт. Поэтому выбор модели оплаты аудита — это не бухгалтерский вопрос, а инженерно-стратегический. Две базовых модели, которые доминируют на рынке:

Fixed Price — это лотерея. Исполнитель закладывает риски в цену, режет скоуп до минимума, чтобы не уйти в минус, и закрывает сделку формальным отчётом. Time & Material — это партнёрство: заказчик платит за реальную работу, исполнитель копает до последнего слабого места.

Когда выбирают Fixed Price:

• Приложение небольшое, до 50 тысяч строк кода.
• ТЗ чёткое, изменения в скоупе не предвидятся.
• Заказчик хочет закрыть процедуру в тендере фиксированной суммой.

Когда выбирают Time & Material:

• Приложение корпоративное, с десятками интеграций и разросшимся API.
• Архитектура «живая», кодовая база меняется.
• Цель — не отчёт, а устранение уязвимостей в долгую.

Реальный разброс цен по российскому рынку на 2024–2025 годы: стартовый аудит одной платформы — от 100 000 рублей у RTM Group, от 300 000 рублей за платформу у Spider Group. Комплексный аудит крупной корпоративной системы с доработками — от 1 000 000 рублей у ЕВРААС. В эти суммы не входит стоимость переписывания кода, пересборки инфраструктуры и внедрения новых политик — это отдельная статья расходов, которую заказчики почему-то всегда забывают.

Дешёвый Fixed Price — это не экономия. Это аванс за формальный PDF, который не защитит ни от одной реальной атаки.

Заказчики, которые выбирают T&M и не контролируют часы, попадают в другую ловушку: бесконечный аудит, размытый скоуп, регулярные счета. Решение — фиксированный лимит часов с покрытием по скоупу и этапная отчётность. В лабораториях, которые работают в T&M-формате давно, бюджеты согласовываются пакетами: пакет 1 — анализ, пакет 2 — эксплуатация уязвимостей, пакет 3 — верификация исправлений. Платите за пакет, получаете результат.

Третий вариант — гибридная модель. Фиксированная цена на первичный анализ (сканирование, обзор архитектуры, формирование списка находок), T&M на глубокую проверку и верификацию исправлений. На российском рынке гибрид встречается всё чаще, потому что он снимает страх заказчика перед «бесконечным счётом» и страх исполнителя перед «бесконечным скоупом».

Проверка условий оплаты в мобильных приложениях — отдельная тема, которая часто выпадает из скоупа аудита. Скрытые платежи в лицензиях мобильного ПО, автоматические продления подписок, сбор данных для таргетированной рекламы — всё это финансовые риски, которые не видны в коде, но видны в пользовательском соглашении. Аудит, который не заглядывает в юридические документы приложения, неполон.

Мифы о сертификации: почему соответствие стандарту не равно официальному документу

OWASP не сертифицирует мобильные приложения. Это нужно выжечь на стене в кабинете каждого заказчика, который приходит с формулировкой «нам нужна OWASP-сертификация». Организация прямо заявляет: никаких аккредитаций, никаких штампов «соответствует MASVS», никаких авторизованных центров.

Что есть на самом деле:

• Отчёт о верификации. Документ, который выпускает конкретная лаборатория по результатам аудита. Не аккредитованный, не унифицированный, но содержащий фактаж.
• Соответствие контролям MASVS. Внутренняя оценка приложения по 24 контролям. Может быть проведена самостоятельно, но без независимой верификации — это самообман.
• Публичный отчёт MASTG. Тесты и методики, которые лаборатория может приложить к отчёту. Полезная опция, не обязательная.

Подделок и псевдосертификатов на рынке — десятки. Компании рисуют красивые штампы «OWASP MASVS Compliant», вешают их на сайт и продают «сертифицированный» софт. Юридической силы у этих бумаг — ноль. Технической — тоже.

Когда у заказчика спрашиваешь «а покажите сертификат OWASP», в большинстве случаев начинается долгая пауза и поиск в почте. После паузы выясняется, что «это внутренний отчёт нашей лаборатории», «это PDF, который выдали подрядчики», «это письмо от интегратора о соответствии». Ни одно из этих подтверждений не является тем, чем кажется.

«Сертификат OWASP» — это миф, который кормит маркетологов. Реальность: есть отчёты лабораторий, есть пройденные контроли MASVS, есть подтверждённые исправления. Никакого штампа.

Что делать заказчику, если требуют «официальный документ о соответствии»:

1. Заказать аудит у лаборатории с публичными кейсами и командой, которая публикуется на конференциях.

2. Потребовать отчёт по форме MASTG с привязкой к контролям MASVS v2.1.0.

3. Провести повторный аудит после устранения критических и высоких уязвимостей.

4. Сохранить отчёт и запросить его обновление при каждом релизе с существенными изменениями.

Это не сертификат. Это инженерная практика, которая даёт результат. Стандарт один — OWASP MASVS v2.1.0. Методология одна — MASTG с профилями MAS-L1, MAS-L2, MAS-R. Классификация находок одна — MASWE. Всё, что не укладывается в эту схему, — это либо невежество, либо развод. В обоих случаях платит заказчик, и в обоих случаях течёт клиентская база. Дальше — выбор каждого.