Безопасность банковских приложений

Банковские приложения часто становятся мишенью злоумышленников. Согласно результатам исследования Solar JSOC, в 2023 году на финансовый сектор было совершено более 6 тысяч атак, в том числе на ПО. Чтобы защитить персональные данные и деньги клиентов, в процессе разработки банковских приложений важно устранять уязвимости, которые могут использовать мошенники.  Рассказываем, какие методы контроля безопасности существуют и как интегрировать их в процесс создания ПО.

Угрозы безопасности банковских приложений

Перечень распространенных уязвимостей ПО — в OWASP Top 10. Указанные в этом списке слабые места могут стать входными точками для атак злоумышленников. Приведем примеры типичных атак на банковские приложения:

• Эксплуатация XSS-уязвимостей (межсайтовый скриптинг) — реализация MitM-атак и получение несанкционированного доступа к интернет-банкингу.
• SQL-инъекции — кража персональной и финансовой информации из баз данных приложений.
• Эксплуатация недостатков механизмов аутентификации — получение доступа к пользовательским аккаунтам.
• Supply-chain-атаки — внедрение закладок в программные компоненты, поставляемые разработчикам банковских приложений. Часто такие киберинциденты связаны с использованием Open Source — открытого кода.

Также на руку злоумышленникам играют недекларированные возможности — функционал ПО, который не описан в сопроводительной документации или не соответствует описанию.

Чтобы снизить риски ИБ, сохранить конфиденциальность клиентских данных и репутацию банков, важно заботиться о безопасности банковских приложений уже с первых этапов разработки. Это поможет избежать негативных последствий, таких как финансовые и репутационных потери, санкции и штрафы за нарушение законодательства.

Разработка защищенных банковских приложений

Залог высокой защищенности интернет-банкингов — применение концепций безопасной разработки Security Development Lifecycle (SDL) и DevSecOps. Их основные принципы:

• Соблюдение требований безопасности банковских приложений с самого начала цикла разработки. Важно учитывать стандарты и нормативы, например PCI DSS и ISO/IEC 27001, а также интегрировать различные виды анализа кода.
• Непрерывный мониторинг угроз безопасности банковских приложений и оперативное устранение обнаруженных уязвимостей.
• Оценка потенциальных рисков, определение самых важных из них и распределение ресурсов для их уменьшения, а также разработка мер реагирования на инциденты.
• Профессиональная подготовка специалистов, работающих над проектом. Важно, чтобы в команде были эксперты, способные оперативно решать проблемы безопасности.

Этапы разработки банковских приложений в рамках концепции DevSecOps:

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

Для всестороннего анализа безопасности банковских приложений необходимо комбинировать несколько видов тестирования. Среди стандартных практик — регулярное рецензирование кода (код-ревью) для устранения уязвимостей, исправления логических ошибок в алгоритмах и выявления других проблем, которые могли быть упущены на ранних этапах разработки. Работать над повышением уровня безопасности ПО помогают и пентесты — имитация реальных атак злоумышленников на приложения.

Методы тестирования безопасности банковских приложений

Мы уже упомянули, что в процессе разработки важно внедрить различные виды тестирования ПО. А именно:

• статическое,
• динамическое,
• исследование состава приложений,
• анализ цепочки поставок.

Такие проверки можно выполнять вручную или с помощью специального анализатора. Ручное тестирование достаточно трудоемкое: оно занимает много времени и в большинстве случаев требует участия опытных тестировщиков, секьюрити-инженеров. Использование анализаторов позволяет автоматизировать процессы и получить детальные отчеты обо всех обнаруженных проблемах.

Расскажем подробнее о перечисленных видах тестирования и о том, как они выполняются с помощью платформы Solar appScreener.

Статическое тестирование

Static Application Security Testing (SAST), или метод White box. Такое тестирование можно интегрировать в цикл разработки уже с первых этапов, так как оно проводится без запуска приложений. Для его реализации нужно иметь доступ к исходному коду, но Solar appScreener позволяет анализировать и бинарный код. Эта опция будет полезна пользователям, которые хотят проверить безопасность мобильных банковских приложений, скачанных из магазинов ПО. В других анализаторах такой функции нет.

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

У статического анализа есть и существенный минус — ложноположительные срабатывания (False Positive). В Solar appScreener эта проблема решается с помощью уникальной технологии Fuzzy Logic Engine.

Динамическое тестирование

Dynamic Application Security Testing (DAST), или метод Black box, обычно проводится на финальных этапах разработки или при проверке уже готового продукта. Чтобы проанализировать безопасность эксплуатируемого банковского приложения, не нужно иметь доступ к коду и разбираться в его структуре, так как внимание сосредоточено не на проблемах с кодом, а на поведении ПО. Для анализа программу нужно развернуть в имитированной рабочей среде, подготовленной для тестирования.

DAST с помощью анализатора имитирует действия хакеров — на вход ПО передаются заведомо ложные или случайно сгенерированные данные. Характер и интенсивность атаки можно регулировать с помощью различных сканеров, доступных в Solar appScreener, — например, фаззера AJAX, пассивного, активного, традиционного. Таким образом удается выявлять уязвимости и проблемы, которые проявляются непосредственно при эксплуатации приложений.

Динамическое тестирование для проверки безопасности банковских мобильных приложений комбинируется со статическим анализом. Такой комплексный подход помогает обнаружить максимум слабых мест ПО и ускорить релиз продукта.

Анализ состава ПО и цепочки поставок

В составе Solar appScreener есть модуль OSA, объединяющий такие виды тестирований, как Software Composition Analysis (SCA) — анализ состава приложений и Supply Chain Security (SCS) — контроль безопасности цепочки поставок.

SCA-анализ помогает проверять безопасность заимствованного кода в банковских приложениях. С его помощью можно найти программные закладки, уязвимости в открытых библиотеках и проблемы с лицензированием open-source-компонентов. Внедрение Solar appScreener повышает эффективность такого анализа, так как для поиска слабых мест ПО используются не только общедоступные базы уязвимостей, но и собственные от экспертов ГК «Солар».

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