SDK-модули, неправильное хранение секретов, перехваты трафика, низкий уровень защиты журналов и другие опасности, которые могут привести к серьезным штрафам.

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

По экспертным оценкам, средний ущерб российских компаний от одной утечки может достигать 11,5 млн руб. Максимальный ущерб для российских участников рынка составил более 41 млн руб. 

Количество утечек в российском сегменте интернета растет: за 2024 год были выявлены случаи компрометации более 1,5 млрд записей. Рост утечек, по сравнению с 2023 годом, составил порядка 30 %. 

Затраты российских компаний на кибербезопасность достигли рекордных 209 млрд руб. 

Если компания не выстроила внутренние процессы хранения данных, это может обернуться серьезными последствиями. За нарушения правил хранения персональных данных в Российской Федерации предусмотрена ответственность, штрафы для юрлиц могут достигать от 1 % до 3 % от оборота. 

За 2023 год суммы штрафов за утечку персональных данных для российских компаний составили 4,6 млн руб. 

Модуль с зависимостями

Для ускорения разработки IT-компании используют готовые модули – SDK: они, в частности, отвечают за показ рекламы, аналитику, отчетность, уведомления и тому подобный функционал. Решение позволяет экономить ресурсы, но добавляет в продукт внешний код, у которого собственные механизмы сбора данных. 

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

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

Сервер с секретом

API-ключи, токены и другие технические секреты обеспечивают доступ к внутренним сервисам компании. Во многих проектах их по инерции могут включить прямо в клиентский код: в файлы сборки Android и iOS, JavaScript-бандлы или конфигурации.

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

Подобные случаи фиксируются достаточно часто: автоматические сканеры находят в открытых источниках тысячи рабочих ключей. Их можно моментально задействовать для получения доступа к пользовательским данным. Один такой «пропавший» ключ дает полный доступ к системе и чреват для компании значительными убытками. 

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

Перехват трафика

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

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

Если приложение неправильно проверяет сертификаты или использует устаревшее шифрование, злоумышленник может:

 — увидеть логины, токены и другую личную информацию;

— подменить ответ сервера;

— выполнять действия от имени пользователя.

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

При каждом подключении должна запрашиваться подлинность сертификата сервера. Кроме того, стоит «привязать» приложение к конкретному сертификату. Тогда подменить его будет крайне затруднительно. Это фактически обязательная процедура для приложений, которые взаимодействуют с финансовыми платежами. 

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

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

Низкий уровень защиты журналов и систем мониторинга

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

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

WebView открывает доступ

Компонент WebView используется для быстрой интеграции веб-контента в мобильное приложение. Например, для демонстрации промо-страниц, форм оплаты или внешнего контента. Это еще один инструмент, которые используется для оптимизации ресурсов при разработке приложений. Но он делает приложение доступным для внедрения внешнего кода. Если страница внутри приложения может запускать свой код или ей разрешено общаться с приложением через специальный «мост», то доступ к функциям приложения может получить внешний сайт. 

У приложения могут существовать свои внутренние команды (например, myapp://выполнение команды). Если эти ссылки не защищены, то к ним могут получить доступ внешние участники (другие сайты). При этом, приложение будет считать эти команды легитимными, как будто бы действия совершает сам пользователь. 

К использованию WebView стоит подходить, как минимум, осторожно: оценивать содержание загружаемых страниц, ограничивать источники контента (whitelist), запрещать выполнение произвольного JavaScript для критичных флоу. Лучше избегать использования WebView в сценариях с авторизацией, платежами или доступом к профилю пользователя.

Как выстроить систему защиты

1.Зафиксируйте правила безопасности на уровне продукта. Необходимо четкое понимание: какие данные вы собираете, зачем, кто за них отвечает и что считается нарушением. В таком случае безопасность становится понятным критерием, а не чьей-то ответственностью по умолчанию.

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

3. Проверки – это регулярная работа. Можно выпускать быстрые релизы, но вслед за ними идет обязательный аудит: проверка подключенных SDK, ключей, анализ журналов. 

4. Используйте внешний аудит. Внешняя проверка помогает увидеть уязвимости, которые команда внутри уже не замечает.

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