Утечка данных пользователей: почему базы приложений опаснее

Его просто оставляют открытым, кладут ключ от него прямо в приложение или подключают очередной рекламный SDK, который тащит телеметрию куда-то в свою уютную нору.

Цифры тут неприятные, но без истерики. Около половины мобильных приложений содержат жёстко зашитые секреты: API-ключи, токены, учётные данные для сервисов. Более 77% допускают утечки конфиденциальной информации из-за того, как данные собирают, хранят или передают. Это не означает, что 77% программ уже сливают вашу переписку на форум. Это означает другое: у слишком многих приложений дверь в базу данных держится на честном слове и скотче.

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

Код приложения — не сейф, а коробка, которую можно вскрыть

Мобильное приложение попадает на телефон пользователя. Это очевидно, но некоторые команды разработки продолжают вести себя так, будто их Android APK или iOS-сборка лежит в банковском хранилище.

Не лежит.

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

По данным исследований, защиту от такой разборки не используют примерно 24% Android-приложений и вообще 60% iOS-приложений. Миф «на iPhone всё закрыто» здесь особенно смешон. Закрыт магазин, закрыта экосистема, закрыт исходный код. Но приложение уже лежит на устройстве, и его внутренности можно изучать. Не так удобно, как на Android, но вполне реально.

Самая жирная ошибка — жёстко прописать в коде секрет. Например:

• ключ к облачной базе;
• токен доступа к API;
• пароль сервисного аккаунта;
• ключи для push-уведомлений;
• параметры сторонней платёжной, аналитической или картографической платформы.

Разработчик обычно объясняет это словом «быстрее». Потом приложение выпускают. Потом кто-то вытаскивает ключ. Потом оказывается, что этот ключ умеет не только показывать карту или отправлять пуши, но и читать, а иногда менять записи в базе. Вот и вся магия.

Если ключ лежит в приложении, это не секрет. Это подарок тому, кто умеет открыть упаковку.

Конечно, не каждый найденный API-ключ даёт доступ ко всему подряд. У нормальной инфраструктуры есть ограничения: привязка к конкретному приложению, домену, IP, набору разрешённых операций, сроку жизни токена. Но «нормальная инфраструктура» — не универсальный закон природы. В реальном мобильном рынке по-прежнему хватает сервисов, где ключ открывает больше дверей, чем должен.

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

Firebase и другие облака: база может быть открыта без единого взлома

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

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

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

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

Тут есть важная деталь. Пользователь не способен проверить конфигурацию чужой базы из настроек смартфона. Нельзя открыть Android или iOS, ткнуть переключатель «не сливать мои данные через ошибочные правила Firebase» — и жить спокойно. Это зона ответственности разработчика. Но снизить ущерб всё же можно: не отдавать приложению больше, чем оно реально заслужило, и не превращать один номер телефона в универсальный цифровой паспорт.

Я давно советую разделять аккаунты по уровню доверия. Банк, госуслуги, основной почтовый ящик — один контур. Сервисы скидок, случайные маркетплейсы, приложения мероприятий, доставка из одного заказа — другой. Отдельная почта, алиасы, где возможно — вход через Apple или Google со скрытием реального адреса. Это не паранойя. Это санитарный минимум в среде, где каждая третья компания мечтает «лучше узнать клиента», а потом теряет Excel.

Разрешения: приложение просит не доступ, а куски вашей жизни

На Android 62% проанализированных приложений запрашивают хотя бы одно опасное разрешение. Опасное — не потому, что приложение обязательно вредоносное. А потому, что доступ к SMS, контактам, микрофону, камере, журналу звонков или точной геолокации радикально увеличивает цену возможной утечки.

Фонарик с доступом к контактам — классика из эпохи динозавров. Сегодня всё стало аккуратнее. Приложение не просит «прочитать все ваши сообщения», оно говорит: «Нам нужен доступ к SMS, чтобы автоматически подставить код». Не «следить за вами», а «разрешите геолокацию для персональных предложений». Не «вытащить адресную книгу», а «найдите друзей быстрее».

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

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

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

Вот мой рабочий режим для разрешений. Не красивый, зато практичный:

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

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

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

4. Камеру и микрофон держу в режиме “спросить в следующий раз”. QR-код, видеозвонок, фото чека — нормально. Фоновый доступ — уже повод смотреть на разработчика через прищур.

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

На iPhone это делается в разделе «Конфиденциальность и безопасность», на Android — в «Разрешениях» или через диспетчер разрешений. Названия пунктов слегка пляшут от оболочки к оболочке, но логика одна: не выдавливать кнопку «Разрешить» автоматически, как будто это согласие на доставку пиццы.

Разрешение — не формальность. Это ключ от конкретной комнаты в вашем телефоне.

SDK: приложение может быть приличным, а его пассажиры — нет

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

В одном приложении легко уживаются:

• аналитика, которая считает нажатия и экраны;
• рекламная сеть, которой нужен рекламный идентификатор;
• сервис пушей, знающий токен устройства;
• система записи ошибок, куда случайно может улететь часть формы, номер заказа или e-mail;
• чат поддержки с историей обращений;
• платёжный модуль;
• библиотека для карт и геопозиционирования.

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

В OWASP Mobile Top 10 2024 это уже не второстепенная мелочь. Среди ключевых рисков отдельно стоят некорректное использование учётных данных, слабая безопасность цепочки поставок и небезопасное хранение данных. Человеческий перевод простой: нельзя прятать пароль в приложении, нельзя слепо доверять чужому коду и нельзя хранить чувствительные данные так, будто телефон никогда не попадёт в чужие руки.

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

Но можно хотя бы не усложнять им задачу:

• ставить приложения только из официальных магазинов, а не из Telegram-архивов с подписью «без рекламы и подписки»;
• смотреть не только на рейтинг, но и на издателя, число скачиваний, историю обновлений, странные отзывы о списаниях и спаме;
• не держать на смартфоне пять клонов одного сервиса — особенно банков, доставок и маркетплейсов;
• не логиниться везде через основной аккаунт Google или Apple, если сервис одноразовый и не вызывает доверия;
• не отключать обновления «потому что новая версия неудобная». Иногда она неудобная, потому что закрывает дыру, через которую вас могли вынести.

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

Перехват трафика: VPN не делает приложение честным

Есть ещё один канал утечки, про который любят говорить рекламщики VPN. Открытый Wi‑Fi, злой человек в кафе, перехват трафика, спасительная кнопка «Подключиться». В реальности VPN полезен, особенно в чужих сетях. Но считать его универсальным бронежилетом — значит покупать себе ложное чувство безопасности.

Исследования показывали уязвимость к атакам Man-in-the-Middle у каждого третьего финансового приложения на Android и у каждого пятого туристического приложения на iOS. MitM — это ситуация, когда злоумышленник вклинивается между приложением и сервером, читает или подменяет трафик. Обычно такая возможность появляется из-за слабой проверки сертификатов, неаккуратной работы с HTTPS или других ошибок в сетевой части.

VPN может скрыть часть трафика от владельца публичной Wi‑Fi-сети и усложнить жизнь локальному перехватчику. Но он не исправит приложение, которое:

• отправляет данные на плохо защищённый сервер;
• доверяет поддельному сертификату;
• хранит токены в небезопасном виде;
• сливает события аналитическому SDK;
• подключается к облачной базе с дырявыми правилами.

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

Если нужно зайти в банк, почту или корпоративный сервис, я предпочитаю мобильную сеть или свой проверенный VPN, а не Wi‑Fi с названием Airport_Free_SuperFast. Но главная защита всё равно начинается раньше: с нормального приложения, обновлённой системы и двухфакторной аутентификации.

Как понять, что ваш адрес уже уехал в чужую базу

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

Но есть признаки, после которых стоит действовать, а не ждать:

1. На адрес, который вы использовали только в одном сервисе, пришёл тематический спам. Регистрировались в приложении клиники — и вдруг получаете «выгодные обследования» от незнакомцев? Совпадение бывает, но слишком часто это след базы.

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

3. Приходят коды входа, которые вы не запрашивали. Пароль меняйте сразу. Завершайте активные сессии. Проверяйте привязанные устройства и резервную почту.

4. В приложении появились неизвестные действия. Новый адрес, заказ, карта, вход с чужого устройства — это уже не повод «понаблюдать». Это повод резать доступы.

5. Спам стал слишком персональным. Не просто «вам одобрен кредит», а «Илья, подтвердите доставку заказа №…». Чем точнее приманка, тем меньше оснований играть в вежливость.

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

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

Утечки не исчезнут, пока данные считают бесплатным сырьём

Я не верю в сказку, что рынок вдруг проснётся этичным. Приложения будут собирать данные, потому что данные помогают продавать рекламу, строить профили, измерять воронки и объяснять инвесторам, почему очередная кнопка стала синее. Разработчики будут подключать SDK, потому что сроки горят. Компании будут извиняться после очередного инцидента, потому что до него безопасность обычно проигрывает «приоритетам квартала».

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

Пользователь не может провести аудит Firebase, разобрать APK и проверить сертификатный пиннинг перед каждым заказом кофе. Это не его работа. Но он может не раздавать приложению контакты, SMS и геолокацию за красивую иконку; не ставить сомнительные сборки; не использовать один пароль везде; не путать VPN с магическим щитом.

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