Всем привет!

На связи Юрий Шабалин, генеральный директор «Стингрей Технолоджиз». Недавно я проводил вебинар для новых сотрудников компании, в котором рассказывал про проблемы безопасности мобильных приложений, а именно, почему важно их защищать, какие особенности встречаются при разработке и сопровождении, какие для них есть специфические вектора атак и почему мобильная безопасность до сих пор идет самым последним эшелоном. В процессе я понял, что стоит написать об этом на широкую аудиторию. Ну что же, начнем?

Введение

Среднестатистический житель России проводит в своем смартфоне около 4–5 часов ежедневно. Наверняка даже сейчас вы читаете эту статью именно на телефоне.

В мобильных устройствах сегодня — и личная жизнь, и рабочая, мы часами не выпускаем их из рук. По данным банка Тинькофф, аудитория которого насчитывает более 40 млн пользователей, еще в 2018 году количество клиентов мобильного приложения превысило показатель веб‑версии. И с тех пор разрыв только увеличивается.

Сегодня более 90–95% клиентов предпочитают пользоваться исключительно мобильными приложениями. Эта тенденция характерна не только для финансового сектора, но и для многих других сфер — пользователи ценят функциональность и доступность. Есть и компании, весь бизнес которых строится на «мобилке». Открывая для себя новый сервис, я сразу же задаюсь вопросом, есть ли у него мобильное приложение. Согласитесь, ведь оно намного удобнее и проще, чем веб‑версия, в которую нужно заходить через браузер, логиниться и т. д.

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

Вы наверняка неоднократно слышали о сливах персональных данных, массовых утечках информации и повышении активности мошенников. Мы в «Стингрей Технолоджиз» ежегодно выпускаем отчет об оценке уровня защищенности российских мобильных приложений по отраслям. По результатам исследования 2022 года, 86% отечественных программ содержали уязвимости уровня Critical и High. Мы били тревогу и активно пушили компании, чтобы исправить ситуацию. Похоже, наши действия возымели эффект — в 2023 году уязвимости критического и высокого уровня обнаружились в 56% приложений. Но это всё еще большой процент, означающий, что каждое второе мобильное ПО может стать источником утечки данных. Подход к обеспечению безопасности пользователей должен быть более серьезным.

Мобильные технологии — относительно новая, хотя и бурно развивающаяся отрасль. На мой взгляд, эру современных мобильных приложений начал Apple, после запуска iPhone 4 в 2010 году, вышедшем уже с операционной системой iOS. За ней подтянулся и Google, и с тех пор рынок мобильных приложений занял большую часть цифрового пространства, а вскоре обогнал другие каналы по количеству активных пользователей.

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

Давайте подробнее рассмотрим несколько особенностей приложений и подумаем, как они влияют на безопасность. Конечно, сегодня мы разберем далеко не весь перечень отличий, но с чего‑то же нужно начинать, верно?

Мобильное приложение работает во “враждебной среде”

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

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

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

Отсутствие контроля обновлений приложений

Еще один аспект — контроль за обновлениями приложений. Как устраняют критическую уязвимость, найденную в серверной части системы? Ну, для начала пробуют воспользоваться каким‑нибудь средством защиты, например WAF. После этого проблему передают в разработку и выпускают «hotfix». Допустим, на это уходят сутки. Ночью в «техническое окно» система обновляется, и на выходе получается полностью исправленный сервис. Проблема решена, бизнес и пользователи довольны. Весь процесс занимает не более двух дней.

С мобильными приложениям ситуация сложнее. При выявлении критической уязвимости в клиентской части программы специалисты действуют примерно так же, как описано выше. К сожалению, нет возможности поставить «заплатку» через WAF, поэтому первый шаг они пропускают и сразу идут в разработку. Остается устранить уязвимость и обновить ПО, и вроде бы уже можно порадовать клиентов безопасной версией. Однако с этого момента начинаются «нюансы». Перед апдейтом нужно пройти модерацию в магазинах приложений. Этот процесс занимает примерно 2–3 дня для Android и около недели для iOS. Следовательно, от исправления до возможности загрузить обновленную программу проходит несколько дней. А если сборку по каким‑то причинам завернут, всё начинается сначала.

Насколько мне известно, новые версии мобильных приложений не выпускаются одновременно для всех клиентов. Обычно функционал раскатывается по сегментам. Например, сначала доступ получают пользователи с 11 Android или 15 iOS. Затем предоставляется возможность загрузить обновления для юзеров со старыми версиями (также сегментация может идти по моделям устройств или географическому признаку). Такой подход уменьшает количество ошибок и позволяет последовательно обрабатывать алерты и поступающие отчеты о сбоях. За счет этого удается не перегружать техподдержку и аналитиков массой проблем сразу со всех устройств, если вдруг что‑то где‑то сломается (а ведь мы знаем, что если что‑то может сломаться, то так и будет). Таким образом, часть пользователей может ожидать доступ к обновлению очень долго.

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

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

Итак, от момента устранения критической уязвимости до того, как все пользователи обновят приложение, может пройти от недели до нескольких месяцев. Это значительный промежуток времени, в течение которого часть клиентов, не успевших установить новую версию, остается уязвимой. Представьте, как бы вы отреагировали, если бы компания сообщила, что ее продукт уязвимый, и порекомендовала обновиться? Есть люди, которые сразу запаникуют: «А вдруг мои данные уже попали в сеть?»

Еще один важный момент — выпущенные версии с уязвимостями остаются доступными практически навсегда. Как только приложение попадает в интернет, в Google Play или на устройства пользователей, оно может быть скопировано и распространено через различные неофициальные источники, например, сайты для скачивания APK‑файлов. Это означает, что информация об уязвимостях становится известна широкой публике на неопределенное время. Проблема усугубляется и тем, что даже из официальных магазинов, в некоторых случаях, можно загрузить старые версии приложений. Поэтому почти невозможно быть уверенными в том, что клиент использует безопасную программу, тем более, если он отключил автоматическое обновление или вообще не имеет доступа к стору.

Исполняемый файл приложения находится в открытом доступе

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

В современной разработке мобильных приложений широко применяется функционал, предоставляемый сторонними сервисами. Например, для отправки push‑уведомлений специалисты могут использовать такие платформы, как Firebase, RuStore и другие сервисы. Это позволяет значительно сократить время и ресурсы, необходимые для разработки собственных решений. Например, установка точек банкоматов на карте обычно реализуется через внешние SDK и плагины Яндекс, Google или Apple. Еще бизнес очень любит интеграцию с социальными сетями и системами идентификации пользователей (Social Sign‑On, SSO). Все эти инструменты обеспечивают приложениям доступ к расширенным функциям без необходимости разработки собственного кода.

И здесь мы сталкиваемся с еще одной особенностью мобильной разработки — ненадлежащее управление ключами доступа для аутентификации сторонними сервисами. О сложности их настройки и контроля можно судить по пространной и трудной для понимания документации. Я, как разработчик, однажды пытался создать ключ в Firebase для определенного функционала. Присвоил ему минимальные нужные права согласно документации, но в итоге ключ не заработал. Дал больше полномочий — опять безуспешно. Плюнул и дал максимальные права — наконец, «полетело». И так происходит не только со мной, но и с другими разработчиками.

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

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

Возможность физического доступа

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

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

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

Фрагментация мобильных устройств

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

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

А вот Android с высоким уровнем фрагментации становится более опасной системой для разработчика. ОС может быть модифицирована множеством компаний, каждая из которых стремится внести в нее собственные функции и улучшения. В результате возникает ситуация, когда каждая измененная версия Android может содержать свои уникальные уязвимости. Отличным примером могут служить исследования по устройствам Samsung и Xiaomi, в приложениях которых было обнаружено множество серьезных проблем безопасности. В таком случае разработчики должны учитывать все возможные различия, чтобы обеспечить защиту пользовательских данных на любых устройствах. Задачка из разряда «миссия невыполнима».

Делюсь реальным кейсом из приведенной выше статьи. На телефонах Samsung под управлением Android была выявлена одна интересная уязвимость: любое установленное приложение могло обратиться к системе, указав в параметрах флаг «bypassSecurity=true» и передав ссылку на скачивание нужного злоумышленнику приложения. Наличие этого флага позволяло обойти все возможные ограничения безопасности, которые были в классической ОС Android. В итоге сама система запускала загрузку неоригинального приложения по ссылке, устанавливала его, назначала привилегии администратора системы и удаляла остальные программы. И всё это без уведомления пользователя! Такая ситуация стала возможна только на устройствах Samsung из‑за изменений, внесенных производителем телефона в ОС. При этом на стандартной версии Android описанный запрос был бы отклонен из‑за несоответствия подписи приложения.

Это только один из многих примеров подобных проблем. И кто знает, что именно происходит на многочисленных noname‑устройствах и что конкретно производители поменяли внутри? Вот и аргумент в пользу того, что мобильные приложения необходимо анализировать с учетом специфики их работы и окружения.

Заключение

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

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

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

Если же вы просто интересуетесь безопасностью мобильных приложений, приглашаю в свой Телеграм‑канал.