Риски безопасности в банковских приложениях: аналитика и рекомендации
В 2024 году в открытых источниках сообщалось о 1583 уязвимостях, выявленных в банковских приложениях, из которых 569 классифицировались как критические. Эти данные отражают системную проблему, с которой сталкиваются как финансовые организации, так и их клиенты. Понимание природы таких рисков и методов защиты становится необходимым минимумом для всех, кто использует мобильный банкинг.
Почему эта тема важна для бизнеса и пользователей
Финансовый сектор остаётся одной из главных целей для атакующих. По данным открытых источников, в популярных финансовых приложениях за год было обнаружено 3555 уязвимостей, причём 2006 из них отнесены к высокому или критическому уровню серьёзности. Это означает, что речь идёт не о мелких недочётах, а о потенциальных каналах для компрометации персональных данных, учётных записей и средств.
Ключевые факторы возникновения уязвимостей
На основе анализа публичных отчётов и практики аудита можно выделить несколько типовых причин, по которым в банковских приложениях возникают критические недостатки защиты.
Недостаточная проверка исходного кода перед выпуском релизной сборки. В ряде проектов, по информации из открытых источников, CI/CD пайплайн не включал автоматический статический анализ кода (SAST), что повышает риск попадания уязвимостей в прод.
Использование шаблонных решений и сторонних библиотек с открытым исходным кодом без своевременного обновления. Сообщалось о случаях, когда старая версия популярной библиотеки становилась причиной уязвимости сразу нескольких приложений, которые её использовали.
Сжатые сроки разработки. В таких условиях в финальную сборку могут попадать логические ошибки, проблемы с валидацией вводимых данных и другие просчёты, которые впоследствии могут рассматриваться как уязвимости.
Что может следовать за эксплуатацией уязвимостей
При успешной атаке на инфраструктуру владельца сервиса злоумышленники могут получить доступ к персональным данным и банковским реквизитам. В ряде публичных кейсов зафиксированы ситуации, когда через уязвимости в API мобильного банка совершались несанкционированные операции от имени пользователей.
По данным международной технологической группы Thales, атаки через API привели к 40 000 инцидентов информационной безопасности. В первом полугодии 2025 года на финансовые услуги пришлись 27% всех атак, направленных на API. API часто рассматривается как вход для внешних сервисов, и в некоторых случаях разработчики уделяют недостаточно внимания их защите.
В российских реалиях дополнительным фактором становится форсированный переход на отечественное программное обеспечение, СУБД и библиотеки. На основе данных из открытых источников можно предположить, что в период такой миграции количество уязвимостей в банковских приложениях может увеличиваться. При этом требования 187-ФЗ о защите критической информационной инфраструктуры (КИИ) остаются в силе, однако практика показывает, что нередко фокус смещается в сторону формального отчёта.
Пример из практики
В ходе аудита одного из мобильных приложений (название не разглашается) были выявлены следующие особенности: приложение не проверяло сертификат TLS должным образом, в локальных логах устройства обнаруживались токены авторизации в незащищённом виде, а также присутствовал эндпоинт, возвращавший историю операций без ограничения частоты запросов. После обращения в службу поддержки часть проблем была исправлена в следующем обновлении, однако некоторые аспекты остались без изменений. Такие ситуации, по данным открытых источников, могут возникать даже в крупных финансовых организациях.
Рекомендации по защите данных для пользователей
На основе анализа типовых рисков можно предложить следующие меры, которые помогают снизить вероятность компрометации.
Регулярно обновляйте банковские приложения. В обновлениях часто закрываются выявленные уязвимости, в том числе критические. Игнорирование обновлений может оставлять устройство под угрозой.
Используйте уникальные и сложные пароли для каждого сервиса. Менеджеры паролей (Bitwarden, 1Password, встроенные в ОС решения) помогают соблюдать эту практику без запоминания сложных комбинаций.
Активируйте двухфакторную аутентификацию (2FA) везде, где это возможно. Даже при компрометации пароля или сессионного токена второй фактор (например, код из SMS или приложения-аутентификатора) может предотвратить несанкционированное подтверждение операций.
Будьте внимательны при вводе личных данных. Если приложение неожиданно запрашивает PIN-код, CVV или другую чувствительную информацию на подозрительном экране, следует закрыть его и переустановить приложение только из официального магазина (Google Play, App Store, RuStore, NashStore). Встречались случаи распространения поддельных приложений, визуально неотличимых от настоящих.
Используйте антивирусное программное обеспечение. Современные EDR-решения для мобильных устройств (например, Kaspersky, Dr.Web, MobileIron) могут обнаруживать вредоносные приложения до того, как они начнут передавать данные.
Проверяйте настройки конфиденциальности. Отключайте доступ к контактам, камере, микрофону, геолокации, если приложению это не требуется для базовой работы. В современных версиях Android и iOS можно разрешить доступ «только при использовании» или «один раз».
Используйте VPN при подключении к общественным Wi-Fi сетям. Открытые сети в кафе, аэропортах и других местах могут быть небезопасны. VPN шифрует трафик, но следует выбирать проверенные сервисы с политикой отсутствия логирования.
Регулярно делайте резервные копии важных данных. В случае атаки вымогателей или потери устройства резервная копия на облачном сервисе или внешнем носителе может быть единственным способом восстановить данные. Не храните пароли от банковских сервисов в заметках телефона.
Риски, связанные с мобильными устройствами сотрудников
По данным из открытых источников, значительная доля утечек данных в компаниях происходит через мобильные устройства сотрудников, особенно если они используют личные телефоны для работы. В практике известны случаи, когда кража телефона топ-менеджера и последующая перевыпуск SIM-карты по поддельной доверенности приводили к доступу к мобильному банку. Такие инциденты могут свидетельствовать об отсутствии правил подтверждения смены устройства через колл-центр и защиты от перехвата SMS.
Типовые схемы, о которых сообщается в открытых источниках
Схема 1. Фейковое обновление приложения. Пользователь получает push-уведомление с предложением обновить приложение по ссылке, ведущей на поддельный сайт. Скачанный APK-файл оказывается трояном, перехватывающим SMS и пароли. Рекомендуется обновляться только через официальные магазины приложений.
Схема 2. Атака через WebView. Некоторые приложения используют встроенный браузер для отображения страниц. При неправильной настройке или устаревшей версии WebView возможна инъекция JavaScript-кода, который может перехватывать вводимые данные. В публичных кейсах описывались подобные уязвимости.
Схема 3. Подмена биометрии. На некоторых Android-устройствах при наличии root-доступа теоретически возможна подмена биометрических данных. Рекомендуется использовать биометрию только в паре с PIN-кодом или паролем и не рутировать устройства, используемые для финансовых операций.
Подход DevSecOps и его роль
DevSecOps — это методология, объединяющая разработку (Dev), операции (Ops) и безопасность (Sec). На практике она подразумевает встраивание защитных механизмов на всех этапах жизненного цикла приложения:
автоматический статический анализ кода (SAST) при каждом коммите;
динамическое тестирование (DAST) перед каждым релизом;
сканирование зависимостей (библиотек) на известные уязвимости;
контейнеризация с изоляцией модулей.
По данным из открытых источников, внедрение полноценного DevSecOps позволяет снизить количество критических уязвимостей в банковских приложениях на 70–80% в течение первых шести месяцев. Однако для этого требуется не просто покупка инструментов, а изменение культуры разработки.
Инструменты для поиска уязвимостей
Существует ряд инструментов, которые используются для анализа безопасности приложений. Важно понимать, что ни один инструмент не даёт 100% гарантии, и лучшие результаты достигаются при комбинации автоматизированных и ручных методов.
MobSF (Open Source) — для статического и динамического анализа мобильных приложений, требует тонкой настройки.
QARK (бесплатный) — для поиска уязвимостей в Android-приложениях (обновления ограничены).
Burp Suite Pro (платный) — для анализа трафика и тестирования API.
OWASP ZAP (бесплатный) — для автоматизированного пентеста (может давать ложные срабатывания).
Kaspersky Mobile Security (подписка) — для защиты на устройстве.
Рекомендуется использовать 2–3 инструмента в связке и проводить ручной пентест не реже двух раз в год, поскольку автоматизация не всегда находит логические ошибки.
Часто задаваемые вопросы
Какие типы приложений наиболее уязвимы?
На основе анализа открытых источников, в первую очередь это банковские приложения, приложения микрофинансовых организаций и страховых компаний, затем криптокошельки и платёжные агрегаторы.
Что делать, если обнаружена уязвимость в приложении?
Рекомендуется сообщить разработчикам через официальные каналы (обычно security@bank.ru или через программу Bug Bounty, если она существует). Публикация информации об уязвимости до её исправления может создать дополнительные риски.
Можно ли полностью защитить свои данные?
100% безопасность технически недостижима. Однако соблюдение описанных выше рекомендаций позволяет снизить риски до приемлемого уровня.
Что такое DevSecOps и зачем он нужен?
Это подход, при котором безопасность встроена в процесс разработки, а не добавляется в конце. Он необходим для предотвращения появления критических уязвимостей на этапе написания кода.
Как оценить безопасность банковского приложения?
Можно проверить, есть ли у банка сертификат ФСТЭК на приложение (для объектов КИИ это обязательно с 2025 года), изучить отзывы в магазинах приложений, а также протестировать, требует ли приложение подтверждения при входе с нового устройства (при включённой 2FA).
Что делать при подозрении на кражу данных?
Немедленно заблокировать карту через колл-центр, обратиться в полицию с заявлением, сменить пароли во всех сервисах, где использовался тот же пароль, и запросить в банке выписку по операциям.
Как защитить пожилых родственников?
Установить приложение самостоятельно, настроить 2FA на контролируемый номер телефона, объяснить, что нельзя переходить по ссылкам из SMS и сообщать коды. Рекомендуется выделить отдельную карту с небольшим лимитом.
Какие законы регулируют безопасность банковских приложений в России? 152-ФЗ о персональных данных, 187-ФЗ о безопасности КИИ, Положение ЦБ № 716-П, устанавливающее требования к обеспечению информационной безопасности при переводе денежных средств. На практике соблюдение требований может быть формальным.
Безопасно ли использовать биометрию? На устройствах с защищённым элементом (iPhone с FaceID, Samsung Knox) биометрия достаточно надёжна. На бюджетных Android-устройствах без отдельного защищённого элемента использовать биометрию как единственный фактор не рекомендуется. Всегда следует добавлять PIN или пароль.
Вместо заключения
В 2026 году ключевая проблема — не столько сами уязвимости, сколько отношение к безопасности внутри организаций. На основе практики аудита финансовых организаций можно отметить, что нередко безопасность воспринимается как препятствие для бизнеса. В то же время в открытых источниках сообщается о деятельности хакерских группировок, которые атакуют не только отдельных пользователей, но и целые банки через мобильные приложения.
Для руководителей банков, страховых компаний и МФО полезно регулярно задавать себе следующие вопросы:
Когда в последний раз проводился пентест мобильного приложения?
Существует ли программа Bug Bounty?
Проходят ли разработчики обучение безопасному кодированию?
Если на какой-либо из этих вопросов нет чёткого ответа, это может указывать на зону потенциального риска.
Для обычных пользователей достаточно простых действий: регулярно обновлять приложения, включить двухфакторную аутентификацию и не переходить по ссылкам из подозрительных SMS. Эти меры не требуют значительных усилий, но существенно повышают уровень защиты средств.
Если вам важно понять уровень защищённости используемых вами или вашей компанией мобильных приложений, можно провести аудит. Специалисты в области кибербезопасности помогают выявить потенциальные уязвимости, внедрить подходы DevSecOps и обеспечить соответствие требованиям по защите КИИ. На основе практики проверок можно отметить, что значительная часть банковских приложений имела хотя бы одну критическую уязвимость, причём в ряде случаев эти уязвимости могли эксплуатироваться удалённо без каких-либо прав доступа.
⚖️ Данный материал носит информационно-аналитический характер. Все выводы основаны на открытых источниках и не являются утверждением фактов, не подтверждённых официально. Материал не является юридической или технической рекомендацией. Любые решения принимаются читателем самостоятельно.
══════
Больше материалов: Центр знаний SecureDefence.
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]