Топ-10 уязвимостей мобильных приложений — откуда они берутся и чем опасны для бизнеса

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

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

Обычно такие данные лежат в константах, в ресурсах, в конфигурационных файлах, которые попадают в APK или IPA при сборке. Иногда встречаются в BuildConfig или в тестовых фрагментах, которые забыли удалить перед релизом.

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

Токены самая чувствительная часть любой мобильной авторизации. И, к сожалению, их часто хранят так, будто это просто временные файлы. На Android их кладут в SharedPreferences, на iOS — в UserDefaults, причем в открытом виде, без шифрования и без каких-то элементарных мер защиты. Иногда даже не используют специальные контейнеры вроде Keystore или Keychain, хотя они как раз и созданы для таких случаев.

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

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

Многие приложения формально используют HTTPS, но на практике это почти ничего не значит, если отсутствует грамотный SSL pinning. Часто pinning либо вообще не включён, либо реализован так поверхностно, что выключается за пару минут — достаточно перепаковать приложение или подменить библиотеку, которая отвечает за проверку сертификатов.

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

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

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

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

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

На backend начинают всплывать типичные вещи. Сервер не до конца проверяет роли, и пользователь с минимальными правами вдруг получает доступ к действиям, которые ему не положены. В некоторых запросах ID пользователя просто передаётся параметром, и если подставить другой ID, сервер возвращает чужие данные. Бывает и так, что вообще отсутствует отдельная проверка: есть ли у конкретного пользователя право выполнить конкретное действие.

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

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

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

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

Последствия могут быть самыми разными. Удвоенные списания и начисления, бесплатные покупки, обход лимитов вроде «один раз в день» или «один раз на аккаунт». На практике это приводит не просто к багам, а к прямым финансовым потерям.

Push-уведомления и deep-ссылки часто выглядят как простой сервисный механизм, но через них тоже проходят уязвимости. Одна из типичных проблем, когда приложение открывает экран по deep-ссылке, не проверяя, авторизован ли пользователь и имеет ли он право видеть этот раздел. Иногда действие выполняется сразу после перехода по ссылке, без дополнительного подтверждения и без проверки прав.

Еще одна частая история — доверие параметрам, которые приходят в deep-link. Если приложение просто принимает значения из ссылки и не перепроверяет их на сервере, логика может сломаться очень легко.

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

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

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

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

Иногда приложение настолько просто разобрать, что это можно сделать любыми доступными инструментами. Разобрал, собрал обратно и все работает. А если проверки подписи нет или она почти декоративная, подделать сборку вообще не проблема. Делают копию, с виду такая же, иконка та же, интерфейс тот же, а внутри уже другое приложение. Может отправлять данные куда не надо или выполнять чужие команды.

Если при этом нет нормальной проверки целостности, подмененный клиент запускается без вопросов. Дальше остается только выложить такой апдейт где-нибудь в стороннем магазине или раскидать ссылку напрямую и часть пользователей спокойно поставит, даже не заметив подмены.

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

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

И самое неприятное, что тут не нужны никакие навыки реверса. Достаточно просто доступа к телефону. Если данные лежат открыто, их достанут за минуту, а приложение даже не понимает, что это произошло.

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