Дырявые приложения: топ-5 популярных уязвимостей

Пять уязвимостей

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

Один из недавних инцидентов — 72 тысячи пользовательских фото утекли в сеть после взлома мобильного приложения для знакомств Tea в 2025 году. Другой пример — Chat & Ask AI. Это одно из самых популярных AI-чат-приложений в Google Play и Apple App Store с более чем 50 млн пользователей. ИБ-исследователи обнаружили открытую базу данных сервиса и получили доступ к 300 млн сообщений 25 млн подписчиков. Кстати, это приложение возглавляет реестр Firehound по количеству раскрытых файлов и записей. Всего ИБ-исследователи внесли в Firehound 194 iOS-приложения, которые раскрывают данные пользователей.

По данным Solar appScrenner, в широко используемых приложениях (доставка еды, онлайн-аптеки, продуктовый и непродуктовый ретейл, сервисы онлайн-знакомств), аудитория которых превышает 50 млн человек, чаще всего выявляются пять основных категорий уязвимостей. «Они встречаются в более чем 75% приложений и позволяют киберпреступникам реализовать MITM‑атаки (man in the middle — «человек посередине»). Результат — утечки данных пользователей», — говорит руководитель отдела операционной поддержки платформы для комплексной безопасности приложений Solar appScreener Антон Прокофьев.

Топ-5 уязвимостей мобильных приложений:

1. Небезопасное обращение к DNS

Приложение доверяет DNS-ответам без должной проверки. Создаётся риск компрометации пользовательских данных и загрузки вредоносного контента.

Как работает: злоумышленник, находясь в одной сети с жертвой (например, публичный Wi-Fi), может подменить DNS-ответ и перенаправить трафик приложения на свой поддельный сервер. Пользователь вводит логин/пароль в «знакомом» интерфейсе, но данные уходят хакеру.

2. Небезопасная рефлексия (Insecure Reflection)

Механизм рефлексии позволяет программе исследовать и изменять свою структуру во время выполнения. При небезопасном использовании это приводит к утечке данных и нарушению целостности работы софта.

Как работает: если разработчик не фильтрует входные данные, злоумышленник может обойти проверки доступа, заставить приложение создать экземпляр произвольного класса или вызвать метод, который не должен быть доступен извне. Это создает риск RCE (Remote Code Execution) — удалённого выполнения вредоносного кода. Например, приложение подгружает и вызывает внутренние методы по имени, полученному из пользовательского ввода. Злоумышленник подставляет имя скрытого системного метода путём перебора, получает доступ к недоступным функциям и может, например, читать данные всех зарегистрированных пользователей в приложении. Такая уязвимость по итогам исследования популярных приложений экспертами Solar appScrenner была выявлена у большинства мобильных сервисов, в 75% случаев — в приложениях маркетплейсов для заказа электроники и бытовой техники.

3. Небезопасная собственная реализация SSL (Broken SSL Implementation)

Позволяет нарушить подлинность сертификатов защиты данных и установить защищённое соединение без должной валидации. Нередко разработчики сознательно отключают или ослабляют проверку сертификатов «для удобства». Например, для тестирования, работы с self-signed-сертификатами, в демо-окружениях, а потом забывают убрать это в проде. Хакеры также могут выполнить MITM-атаку, перехватить или подменить передаваемые данные.

Как работает: при подключении через публичную или скомпрометированную сеть Wi-Fi злоумышленник подменяет сертификат и получает все передаваемые данные. Это токены, пароли и другая конфиденциальная информация. Также хакер может подделать перехваченную информацию, нарушая целостность передаваемых данных. Чаще всего такая уязвимость встречается в приложениях онлайн-аптек (93%), сервисах заказа готовой еды, цветов и подарков (75%), DIY-приложениях (72%).

4. Слабые алгоритмы хеширования

Использование MD5, SHA-1 или самописных алгоритмов для хранения паролей. Создаёт риск восстановления паролей при компрометации базы данных, а также позволяет подделывать данные.

Как работает: при компрометации базы данных через SQL-инъекцию или инсайд хакеры получают хеши паролей. Слабые алгоритмы позволяют злоумышленнику восстановить исходные пароли за считанные минуты с помощью «радужных таблиц» или перебора на видеокартах.

5. Использование HTTP вместо HTTPS

Есть риск подмены данных, раскрытия передаваемой информации.

Как работает: даже если основное API работает по HTTPS, часто вспомогательные запросы — загрузка картинок, аналитика, рекламные SDK — идут по незащищённому HTTP. Злоумышленник может перехватить токены сессии, куки или другие идентификаторы сеанса или подменить контент. Например, вместо баннера подсунуть фишинговую форму.

Зоны риска

Чаще всего встречаются проблемы с авторизацией и контролем доступа, когда система плохо проверяет, кто и к каким данным имеет доступ, отметил ведущий инженер CorpSoft24 Михаил Сергеев. Популярная проблема — слабая защита от перебора паролей и автоматических ботов. В числе распространённых уязвимостей эксперт также выделил API. «Мобильные приложения активно ими пользуются, а защищают их не всегда тщательно. Данные пользователей хранятся или передаются без достаточного шифрования», — сказал он.

Управляющий RTM Group Евгений Царев выделяет IDOR (Insecure Direct Object Reference, небезопасная прямая ссылка на объект) — уязвимость контроля доступа. Мобильный клиент (так же как веб-клиент) шлёт запросы к API с идентификаторами объектов, и если сервер (или бэкенд мобильного приложения) не проверяет, что пользователь имеет право на запрошенный объект, атакующий может перехватить и изменить эти идентификаторы в мобильном трафике и получить доступ к чужим данным. «Представьте, что вы смотрите историю своих заказов, и в адресной строке браузера или в сетевом запросе приложения видите order_id=100500. Меняем это число на 100501 и внезапно видим чек, адрес, телефон и состав заказа совершенно постороннего человека», — говорит Евгений Царев.

Есть и специфическая проблема для финтеха — злоупотребление SMS-шлюзами. Разработчики внедряют 2FA для безопасности, но забывают про лимиты. В итоге злоумышленник может отправить тысячи запросов, сжигая бюджет компании на SMS за минуты.

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

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

Истоки проблем

Основные причины уязвимостей в мобильных приложениях связаны с отсутствием проверки кода на этапах разработки и использованием непроверенных open-source-компонентов. Например, в библиотеках встречаются подложные пакеты с «накрученными звёздами» (starjacking), говорит Антон Прокофьев.

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

Эксперты связывают распространённость уязвимостей в мобильных приложениях с бизнес-подходом, ориентированным на сокращение Time-to-Market. «В масс-маркете идёт гонка за «фичами». Нужно быстро выкатить темную тему, запустить сторис в приложении банка или доставку за 15 минут. Безопасность в таких условиях часто воспринимается как тормоз прогресса. Идеально защищённых приложений не существует, есть только недообследованные», — говорит управляющий RTM Group Евгений Царев.

Чек-лист для Product Owner и Team Lead

Исправлять баги в готовом приложении дорого. Эксперты рекомендуют менять подход к процессу разработки:

• Внедряйте DevSecOps. Безопасность должна быть частью CI/CD-пайплайна, а не финальным этапом перед релизом. Автоматические сканеры типа SAST/DAST найдут использование HTTP и слабых хешей ещё до того, как код попадёт в репозиторий.
• Контролируйте Open Source. Используйте инструменты для анализа состава ПО, чтобы избежать Starjacking-а и не затащить в проект уязвимые библиотеки.
• Не задушите UX безопасностью. «Баланс достигается, когда безопасность встроена в продукт незаметно для пользователя. Например, когда дополнительные проверки включаются только при подозрительной активности. Очень важно не перегружать пользователя, но защищать критические действия: вход, платежи, смену данных», — отметил Михаил Сергеев.
• Запретите TrustAll на уровне линтеров. Настройте правила статического анализа так, чтобы коммит с отключённой валидацией SSL просто не проходил сборку.
• Подружите ИТ и ИБ. «Уязвимости невидимы для пользователя, эту проблему нужно решать внутри, внедряя практики безопасной разработки», — сказал Антон Прокофьев.
• Никогда не доверяйте пользователям. «Пользователь — априори хакер, даже по незнанию. Начинайте думать о безопасности на этапе проектирования архитектуры, а не за неделю до релиза. Никогда не полагайтесь на то, что приложение что-то запретило нажать. Используйте стандартные и общепризнанные библиотеки и протоколы авторизации и криптографии — самописная защита хуже паяльника», — говорит Евгений Царев.
• Не доверяйте внешним источникам информации. «Разработчикам массовых сервисов следует исходить из недоверия к любым данным, поступающим от клиента или внешних интеграций, и обеспечивать строгую серверную валидацию антифрод-сигналов. Решения скоринговых моделей должны основываться на совокупности факторов, а пользовательские действия — анализироваться в рамках полного сценария, а не изолированных событий», — рекомендует Федор Богословский.

Что делать пользователям?

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

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

«Используйте менеджеры паролей, пароль должен быть уникальным для каждого сервиса. Везде, где можно, включите двухфакторную аутентификацию и желательно не через СМС. Не заполняйте необязательные поля профиля. Сервису доставки не нужно знать вашу ссылку на соцсети», — отметил Евгений Царев.