Менеджер паролей андроид: анализ уязвимостей и методов защиты

Уязвимость AutoSpill показала, что при определённых условиях учётные данные, введённые в WebView, могут стать доступны приложению, которое открыло страницу. А отдельный канал риска создают службы специальных возможностей: они способны читать содержимое интерфейса и наблюдать за действиями пользователя.

Поэтому безопасность хранения паролей на смартфоне зависит не только от шифрования базы. Важно, как менеджер взаимодействует с системным Autofill Framework, что происходит с данными в WebView и кто может видеть экран или буфер обмена. Удобство здесь не бесплатное: каждый способ упростить вход добавляет ещё одно звено, которое приходится защищать.

Эволюция автозаполнения: от Android 8.0 до Credential Manager

Нативный Autofill Framework появился в Android 8.0 Oreo в 2017 году. До этого менеджеры паролей опирались на нестандартные способы интеграции, например на клавиатуры и наложенные поверх приложений окна. Поведение зависело от конкретного клиента и версии системы, а единый системный механизм отсутствовал.

С Autofill Framework приложение может зарегистрировать AutofillService. Когда пользователь открывает форму входа, приложение сообщает системе о полях ввода, а сервис автозаполнения предлагает подходящие сохранённые данные. Пользователь выбирает запись, после чего Android передаёт её полям. Это более предсказуемый путь, чем ручной ввод или вставка из буфера, но сам по себе он не делает каждый экран одинаково безопасным.

Встроенная веб-страница усложняет схему. В нативном приложении может открываться WebView, а поля входа внутри него обрабатываются не совсем так, как обычные поля интерфейса Android. На этом стыке и обнаружили проблему AutoSpill: значение, которое должно попасть в форму, при определённых условиях становилось доступно и приложению-хосту.

Следующий этап, Credential Manager, объединяет работу с паролями и passkey через общий API Android Jetpack. Разработчику не нужно отдельно выстраивать взаимодействие с каждым способом входа, а пользователь получает единый системный сценарий. При этом Credential Manager не является отдельной гарантией безопасности: результат всё равно зависит от приложения, провайдера учётных данных, версии системы и того, как устроена форма входа.

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

Системное автозаполнение снижает трение при входе, но не отменяет проверки того, куда именно Android передаёт выбранные учётные данные.

AutoSpill: как WebView раскрывает учётные данные

AutoSpill описали исследователи IIIT Hyderabad. Уязвимость связана с обработкой автозаполнения в WebView, встроенном в нативное приложение. В обычном сценарии менеджер передаёт данные в поля веб-страницы. Исследователи показали, что в некоторых конфигурациях те же значения могут оказаться доступны хост-приложению через связанные с WebView механизмы обмена сообщениями и callback-интерфейсы.

Для такого сценария не требовались root-права. Достаточно, чтобы пользователь выбрал запись автозаполнения на странице, открытой внутри WebView. Это важное уточнение: риск возникает не при каждом входе и не в любом приложении, а при сочетании конкретных условий, связанных с реализацией WebView и обработкой данных.

В исследовании проверяли несколько клиентов. В базовом сценарии уязвимыми оказались 1Password 7.9.4, LastPass 5.11.0.9519, Enpass 6.8.2.666, Keeper 16.4.3.1048 и Keepass2Android 1.09c-r0. При добавлении JavaScript-инъекции в загружаемую страницу список охватил всю протестированную выборку. Эти результаты относятся к проверенным версиям и условиям эксперимента. Их нельзя переносить на все современные сборки без проверки, но они наглядно показывают, почему важны обновления и аккуратная работа с WebView.

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

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

Accessibility API: привилегия, которая требует доверия

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

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

Исследование Friedrich-Alexander-Universität Erlangen-Nürnberg отмечало, что 99,25% популярных приложений Google Play в проверенной выборке не препятствовали чтению экранного содержимого через Accessibility API. Этот результат относится к исследованию конкретного набора приложений и не означает, что любой установленный сервис может беспрепятственно прочитать любой экран. Но он показывает, что приложения не всегда закрывают интерфейс от служб, которым пользователь уже выдал специальные права.

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

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

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

Буфер обмена: короткое окно для утечки

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

Версии Android по-разному ограничивали такой доступ. В Android 10 усилились ограничения на чтение буфера приложениями в фоне. Системные уведомления о том, что приложение обращается к буферу обмена, появились в Android 12. Это не отдельный пользовательский флаг, который можно включить на Android 10: наличие уведомления зависит от версии системы.

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

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

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

Шифрование, биометрия и passkey: что именно они защищают

Менеджеры паролей обычно шифруют локальную базу симметричным алгоритмом, например AES-256. Ключ может выводиться из мастер-пароля с помощью PBKDF2, Argon2 или scrypt. Параметры этих алгоритмов влияют на то, насколько дорого перебирать пароль при попытке получить доступ к зашифрованной базе. Поэтому длина и непредсказуемость мастер-пароля важны даже тогда, когда приложение использует современное шифрование.

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

Модель Zero-Knowledge означает, что провайдер проектирует сервис так, чтобы не иметь доступа к расшифрованному содержимому хранилища. Это ограничивает последствия доступа к серверным данным: полученный зашифрованный блоб сам по себе не равен открытой базе паролей. Но такую модель нельзя описывать как полное исключение риска компрометации серверной инфраструктуры. Остаются угрозы, связанные с учётной записью, метаданными, ошибками в реализации, вредоносным обновлением или компрометацией устройства.

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

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

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

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

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

Практическая защита складывается из нескольких привычек:

• Устанавливать обновления Android и менеджера паролей, особенно если производитель исправил уязвимость в работе автозаполнения или WebView.
• Проверять, каким приложениям выдан доступ к специальным возможностям. Если служба не нужна для конкретной функции, её лучше отключить.
• По возможности использовать системное автозаполнение вместо ручного копирования пароля.
• Не искать в Android 10 настройку уведомлений о чтении буфера: системные уведомления такого типа появились в Android 12.
• Проверять, включена ли синхронизация буфера обмена на устройстве и нужна ли она для повседневной работы.
• Использовать длинный мастер-пароль, который не повторяется на других сервисах.
• Включать биометрическую разблокировку как удобный локальный способ доступа, не полагаясь на неё как на единственную защиту учётной записи.
• По возможности переходить на passkey, учитывая, что одни ключи привязаны к устройству, а другие синхронизируются через аккаунт поставщика.

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