Безопасность мобильного приложения для бизнеса: аудит защиты данных, техподдержки и платежей

84% — не погрешность, а приговор

За год до этого в мобильном софте обнаружили 48 800 багов безопасности — рост на 63% по сравнению с 2024-м. Из них более 19 000 классифицированы как критические.

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

Финансовый сектор — отдельная боль. Не потому, что там «всё плохо», а потому, что цена ошибки выше. Число наиболее опасных уязвимостей за три года выросло почти в 10 раз: до 1921 случая в 2025-м. Это не статистика инцидентов и не размер потерь, а именно рост опасных технических дефектов — тех самых, которые потом становятся входной дверью для атаки. Приложения проводят платежи, хранят токены доступа, передают паспортные данные и открывают пользователю путь к деньгам. Одного нетронутого эксплойта в одном нетронутом приложении бывает достаточно, чтобы разговор про «теоретический риск» закончился.

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

Если вы — руководитель, принимающий решение о запуске мобильного приложения для бизнеса, у вас нет роскоши верить словам разработчика про «наш код прошёл все проверки». Вам нужен не красивый отчёт из автоматического сканера, а нормальный аудит: что хранится на устройстве, как ходит трафик, что происходит с платежами, как устроена поддержка и кто имеет доступ к переписке.

Да, фраза «безопасность мобильного приложения для бизнеса чек-лист» звучит как заголовок скучного PDF на 40 страниц. Но сама идея правильная: безопасность проверяется не по ощущениям, а по точкам контроля. Только эти точки должны быть не декоративными, а привязанными к реальным стандартам, атакам и процессам эксплуатации.

OWASP MASVS: стандарт вместо веры в «у нас всё закрыто»

Отрасль мобильной безопасности не изобрела ничего практичнее, чем OWASP MASVS — Mobile Application Security Verification Standard. Это не религиозный текст и не бюрократическая папка ради папки. Это способ перевести разговор с разработчиком из зоны «ну мы старались» в зону конкретных требований.

У MASVS есть уровни. L1 — базовая гигиена, которую должны проходить все приложения без исключения. L2 — для приложений, работающих с финансовыми данными, медицинской информацией, персональными данными повышенной чувствительности и другими вещами, за которые бизнесу потом больно не только репутационно.

Почему именно MASVS, а не «рекомендации нашего тимлида»? Потому что стандарт формализует то, что иначе превращается в субъективную оценку. Вот простой пример: требование MASVS-STORAGE-2 касается защиты конфиденциальных данных при хранении на устройстве. Звучит очевидно? По данным Positive Technologies, 76% мобильных приложений не проходят эту проверку. Три четверти рынка спотыкаются на том, что должно быть базовой санитарией.

Причины обычно не в гениальных хакерах, а в скучных архитектурных ошибках:

• SharedPreferences / UserDefaults без шифрования. Логины, пароли, токены сессий, идентификаторы клиента — всё лежит в plaintext-файлах. На рутированном или джейлбрейкнутом устройстве это не «защищённое локальное хранилище», а папка с подарками.
• Жёстко зашитые ключи шифрования в коде. Да, приложение шифрует данные. Нет, это не помогает, если ключ лежит прямо в бинарнике. Декомпиляция через apktool, поиск по строкам — и ключ уже не ваш. Классический rookie move, который встречается не только у стартапов.
• Логирование чувствительных данных. Debug-логи забыли отключить в релизной сборке, и туда попали токены, персональные данные, параметры платежей. Потом эти логи уезжают в crash-репортёр — Firebase Crashlytics, Sentry или другой сервис. И теперь проблема живёт не только в приложении, но и в сторонней инфраструктуре.
• Неправильно настроенный Keystore/Keychain. Android Keystore и iOS Keychain сами по себе не спасают. Нужны ограничения доступа, привязка к аутентификации, корректные таймауты, понятная политика инвалидирования ключей. Иначе получается замок, который вроде есть, но ключ лежит под ковриком.

У аудита корпоративных мобильных приложений есть неприятное свойство: он быстро показывает, где команда делала безопасность «по памяти». Например, разработчик говорит: «Мы всё шифруем». Хорошо. Чем? Где ключ? Как он создаётся? Можно ли извлечь его после рутования устройства? Что происходит при смене биометрии? Что попадает в резервную копию? Ответы на эти вопросы часто звучат заметно тише, чем презентация на пресейле.

MASVS не гарантирует защиту. Это не амулет. Но он даёт каркас, по которому можно задать разработчику 30–40 конкретных вопросов и получить конкретные ответы. Или не получить — что тоже ответ.

PCI DSS 4.0.1: деньги любят не тишину, а границы ответственности

С марта 2025 года PCI DSS версии 4.0.1 стал полностью обязательным. Если мобильное приложение принимает, обрабатывает или передаёт данные банковских карт, оно попадает в зону внимания стандарта. И нет, фраза «мы используем сторонний платёжный шлюз» не снимает ответственность автоматически. Она только меняет контур проверки.

Здесь важно не путать три вещи: хранение, обработку и передачу данных карты. Полный номер карты — PAN — может участвовать в платёжном процессе, но сам факт передачи или обработки PAN не равен хранению. PCI DSS не говорит: «Если приложение на секунду увидело номер карты, оно его хранит». Стандарт регулирует, как такие данные обрабатываются, передаются и защищаются, а небезопасное хранение — запрещает. Разница не академическая: от неё зависит архитектура приложения и реальная область действия PCI DSS.

Вот более честная таблица, без мифа о том, что токенизация «обязательна всегда»:

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

В правильной схеме мобильное приложение не тащит номер карты через весь свой backend «потому что так быстрее сделать». Оно передаёт карточные данные в платёжный компонент или шлюз по согласованной схеме, получает токен и дальше работает уже с токеном. Сам номер карты не должен оседать в локальном хранилище, логах, аналитике, crash-репортах, очередях событий и временных файлах.

Токенизация не отменяет PCI DSS. Она просто помогает сделать так, чтобы меньше частей вашей системы вообще соприкасались с карточными данными.

Главная ловушка — побочные следы. Формально команда может использовать токены, но при этом мобильная форма оплаты отправляет события в аналитику вместе с полями ввода. Или backend пишет тело запроса в лог «для отладки». Или crash-репорт захватывает экран с введённым номером карты. В презентации это называется «у нас токенизация». В аудите — неконтролируемая обработка чувствительных данных.

Проверка здесь простая по идее и неприятная по последствиям: поднимается тестовый сценарий оплаты, трафик прогоняется через прокси вроде Charles или Burp Suite, отдельно смотрятся логи приложения, серверные логи, события аналитики и crash-репортинг. Если полный PAN появляется там, где его быть не должно, вопрос уже не в том, «есть ли у нас токенизация», а в том, почему карточные данные гуляют по системе без необходимости.

Технический периметр: пиннинг, root-детекты и ловушки для MITM

Допустим, данные хранятся правильно, платежи не превращают приложение в пылесос для PAN, а логи не похожи на дамп чужой жизни. Следующий вопрос: как данные передаются и что происходит на устройстве пользователя.

SSL-pinning: почему стандартного TLS недостаточно

TLS шифрует трафик между приложением и сервером. Для обычного веба этого часто достаточно. Для мобильного приложения, которое живёт на чужом устройстве, — уже не всегда.

Что если на устройстве установлен пользовательский CA-сертификат, а трафик проходит через прокси злоумышленника? Что если пользователь поставил «ускоритель интернета», корпоративный фильтр, сомнительный VPN или просто дал доступ человеку, который знает, что делает? Стандартная проверка цепочки доверия может принять сертификат, если система считает его доверенным. Для приложения это выглядит как нормальное соединение. Для атакующего — как открытое окно.

SSL-pinning решает проблему жёстче: приложение хранит хеш конкретного сертификата или публичного ключа сервера и при каждом подключении сверяет его с фактическим. Не совпало — соединение обрывается. Данные не уходят.

Для атаки на приложение с нормальным пиннингом злоумышленнику нужен уже не бытовой прокси, а инструменты обхода: Frida, Objection, модификация рантайма, рутированное устройство. Это не делает атаку невозможной, но резко поднимает стоимость.

Что смотреть на аудите:

1. Пиннинг реализован в приложении, а не только в декларациях. Конфигурация сети — полезна, но нужно понимать, где именно происходит проверка и нельзя ли отключить её флагом.

2. Есть backup-pin. Сертификаты ротируются. Если команда не предусмотрела резервный ключ, приложение может умереть для пользователей после легитимного обновления инфраструктуры.

3. Пиннинг активен в production-сборке. Разработчики часто отключают его для тестирования. Иногда «временно». Иногда это временно до первого инцидента.

4. Ошибки соединения не превращаются в обход. Бывает, что при проблеме проверки приложение откатывается на менее строгий режим. Это не graceful degradation, это дырка.

Root и jailbreak-детекция: пассивная защита или иллюзия?

OWASP MASVS для более чувствительных приложений ожидает, что приложение умеет реагировать на модифицированную среду выполнения. На практике это проверки на root в Android и jailbreak в iOS.

Проблема в том, что базовые проверки обходятся быстро. Библиотеки типа RootBeer на Android и IOSSecuritySuite на iOS ловят простые индикаторы: su-бинарник, Magisk, Cydia, подозрительные пути в файловой системе. Это лучше, чем ничего. Но продвинутые решения маскируют следы, а инструменты динамического анализа давно умеют притворяться «нормальной» средой.

Для мобильного приложения бизнеса это означает простую вещь: один root-детектор — не детектор. Нужна комбинация сигналов:

• проверка файловой системы на типичные следы модификации;
• проверка целостности среды через Play Integrity API на Android и аналогичные механизмы на iOS;
• обнаружение отладчиков, хуков и фреймворков инструментирования вроде Frida и Xposed;
• контроль целостности критичных библиотек и участков кода;
• реакция приложения на риск: запрет платежей, ограничение доступа к чувствительным данным, повторная аутентификация, отказ в работе.

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

Поддержка: место, где криптография заканчивается и начинается человек

А теперь — про самый неприятный раздел.

По данным CYBERDEF за III квартал 2025 года, более 80% атак с использованием социальной инженерии проходили через мессенджеры и чаты поддержки. Не через «письма от нигерийского принца» и не через грубые звонки «из службы безопасности банка», а через каналы, где пользователь расслаблен. Он уже внутри приложения. Он видит знакомый интерфейс. Он пришёл за помощью. Значит, доверяет.

Механизм может идти в обе стороны.

Первый сценарий: злоумышленник пишет в поддержку, представляясь клиентом с проблемой. Оператор, следуя скрипту, просит данные для идентификации. Если процесс выстроен плохо, оператор сам помогает собрать профиль жертвы: ФИО, телефон, последние операции, адрес, фрагменты документов. Всё выглядит как обычное обслуживание.

Второй сценарий: злоумышленник имитирует поддержку и пишет реальному пользователю. Просит «подтвердить личность», назвать код из SMS, прислать номер карты, установить приложение удалённой помощи или перейти по ссылке. Пользователь видит знакомую лексику, логотип, тон коммуникации — и делает то, что ему говорят.

При аудите мобильного приложения это нельзя оставлять «службе поддержки, они сами знают». Не знают. Вернее, знают свою операционную часть, но не всегда понимают, что их чат — такой же атакуемый контур, как API.

Что проверять по каналу поддержки:

• Шифрование переписки. Встроенные чаты часто используют TLS на транспорте, но хранят сообщения на сервере в доступном для операторов виде. Это не обязательно нарушение само по себе, но это должно быть честно описано в модели угроз. Если приложение обещает сквозное шифрование, требуйте технического подтверждения E2EE, а не фразу в маркетинговом тексте.
• Идентификация оператора. Пользователь должен понимать, что говорит с реальным сотрудником внутри доверенного канала. Визуальный бейдж без криптографической или серверной проверки — просто картинка.
• Запрет на опасные запросы. Поддержка не должна просить пароль, CVV, полный код из SMS, seed-фразы, одноразовые коды подтверждения. Никогда. Даже «для проверки».
• Доступ к архиву. Кто читает переписку? Как выдаются права? Есть ли журнал доступа? Через какое время сообщения удаляются или обезличиваются?
• Сценарии эскалации. Что делает оператор, если пользователь сообщает о подозрительном сообщении? Как быстро блокируется мошеннический сценарий? Кто принимает решение?

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

Самая дорогая ошибка в мобильной безопасности часто выглядит не как эксплойт, а как вежливое сообщение оператора: “Для подтверждения личности пришлите код”.

Точки контроля перед запуском: без декоративной безопасности

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

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

По хранению данных должны быть закрыты базовые вещи: нет открытых токенов в SharedPreferences, UserDefaults и SQLite; ключи не захардкожены; чувствительные значения не попадают в логи; буфер обмена не превращается в вечное хранилище пароля; резервные копии не уносят то, что не должно покидать устройство.

По платежам — отдельная дисциплина. CVV/CVC не хранится нигде: ни на устройстве, ни на сервере, ни в логах, ни в аналитике. PAN не должен проходить через лишние компоненты системы. Токенизация, если используется, должна реально сокращать PCI scope, а не украшать архитектурную схему. Доступ к платёжной инфраструктуре — через контролируемые роли, MFA и мониторинг.

По транспорту — проверка пиннинга, TLS-конфигурации, поведения при подмене сертификата, реакции на прокси и пользовательские CA. Здесь не нужно верить словам. Это проверяется руками.

По среде выполнения — root, jailbreak, Frida, Xposed, отладчики, модификация приложения, повторная подпись APK, integrity checks. Важно не только «обнаружили или нет», но и что приложение делает дальше. Если оно показывает тост «обнаружена небезопасная среда», а затем спокойно проводит платёж — это театр.

По поддержке — скрипты операторов, права доступа, хранение архива, запрет опасных запросов, верификация канала, журналирование действий сотрудников. Социальная инженерия любит места, где техническая команда говорит: «Это уже не к нам».

И ещё один неприятный пункт: сборка, которую проверяли, должна совпадать с той, которую выкладывают в сторы. В аудите мобильных приложений нередко встречается цирковой номер: на проверку дают «чистую» сборку, а в прод уезжает другая — с включённым debug, другим endpoint, отключённым пиннингом или экспериментальной аналитикой. Поэтому в отчёте должны быть хеши сборок, версии, окружения и понятная процедура приёмки.

Позиция практика

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

Каждая уязвимость, которую вы пропускаете на этапе аудита, — не абстрактная строчка в risk register. Это будущий сценарий атаки, который кто-то уже пробует автоматизировать. Восемьдесят четыре процента российских Android-приложений содержат критические или высокие уязвимости. В финансовом секторе почти десятикратно выросло число наиболее опасных уязвимостей. Социальная инженерия через чаты и мессенджеры стала одним из главных рабочих маршрутов атаки.

Не верьте словам. Не верьте портфолио. Не верьте скриншотам из автоматических сканеров.

Требуйте формальный аудит по OWASP MASVS. Требуйте понятного разбора PCI DSS 4.0.1 для любого приложения, которое работает с платежами или хотя бы приближается к карточным данным. Проверяйте пиннинг, root-детекты, хранение секретов, логи, аналитику, crash-репорты, чаты поддержки. Проводите пентест — ручной, от живых специалистов, а не автоматический отчёт из коробки.

И если разработчик не может ответить чётко, с демонстрацией и артефактами проверки, — у вас не подрядчик. У вас инцидент, который ещё не случился.