Что такое WebAPK: полное руководство по PWA на Android

  • WebAPK — это APK-файл, создаваемый Chrome при установке PWA, с намерениями, значком и автономным режимом.
  • Манифест и область действия определяют поведение: start_url, display и pathPrefix управляют тем, какие URL-адреса открывает приложение.
  • Разрешения и данные управляются Chrome; файлы cookie и хранилище являются общими, а обновления зависят от версии Chrome.
  • Безопасность прежде всего: защищает HTTPS, CSP и работников служб; предотвращает фишинг и злоупотребления, задокументированные ESET.
Isaac

10 минут

Что такое WebAPK на Android?

Если вы знакомы с функцией «добавить на главный экран» на Android, то знаете, что она несет в себе гораздо больше смысла: Chrome может генерировать собственный установочный пакет для вашего PWA, называемый WebAPK., что позволяет ему вести себя как системное приложение: оно отображается в панели приложений, указано в настройках Android и может открывать ссылки из вашего домена непосредственно в приложении.

В этом руководстве вы узнаете, что такое WebAPK, как Chrome создает его на основе манифеста вашего веб-приложения, какие фильтры намерений он записывает, как он обрабатывает разрешения и хранилище, как часто он обновляется и какие риски безопасности следует учитывать (на примере реальных случаев обнаружения фишинговых кампаний).Кроме того, вы увидите практические рекомендации по сокращению поверхности атаки и обеспечению безопасной работы вашего PWA на Android.

Что такое WebAPK и почему это важно

WebAPK — это специальный APK, который Chrome для Android автоматически генерирует, когда пользователь устанавливает PWA на главный экран.В отличие от простого ярлыка, этот пакет превращает ваш сайт в «приложение» в глазах системы: он интегрируется в переключатель приложений, имеет собственную запись в настройках приложения и, что самое важное, регистрирует фильтры намерений для захвата URL-адресов в области действия вашего приложения.

Браузер проверяет веб-манифест (manifest.json) и другие метаданные для создания WebAPK.Всякий раз, когда Chrome обнаруживает соответствующие изменения в манифесте, он запрашивает и развертывает новый APK, гарантируя, что установленное приложение будет отражать обновленную конфигурацию без каких-либо ручных действий со стороны пользователя.

«Повышение уровня» вашего PWA до WebAPK также означает улучшение UX и интеграции.: Он открывается в автономном режиме, без пользовательского интерфейса браузера, может реагировать на ссылки с домена и отображает значок, название и заставку как нативное приложение. Он не использует WebView: он работает в том экземпляре Chrome, из которого пользователь его установил.

Как Chrome генерирует WebAPK и что следует учитывать

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

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

Минимальный пример манифеста, который открывает приложение независимо от источника:

{
  "start_url": "/",
  "display": "standalone"
}

При такой конфигурации открытие приложения из панели приложений загрузит источник (например, https://example.com/) в автономном режиме., без Chrome bar и типичных элементов управления браузера.

Android Intents: захват ссылок в области действия

Когда PWA устанавливается как WebAPK, Android регистрирует фильтры намерений для всех URL-адресов, которые попадают в область действия приложения.Если пользователь нажмет на ссылку в этой области, она откроется непосредственно в приложении, а не во вкладке браузера.

APK включает фильтры намерений с действием VIEW, категориями DEFAULT и BROWSABLE, а также данные, определяющие схему (https), хост и путь, которые контролирует ваше приложение.Типичный фильтр, охватывающий всю область, может выглядеть следующим образом (вкратце):

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="https" android:host="example.com" android:pathPrefix="/" />
</intent-filter>

С этим фильтром нажатие ссылки типа https://example.com/read в другом приложении запустит ваш WebAPK для его обслуживания. Кроме того, если пользователь вручную переходит по URL-адресу в пределах области действия из адресной строки Chrome, браузер предполагает намерение пользователя посетить сайт и откроет его соответствующим образом, как и в случае с нативным приложением с заявленными намерениями.

Определите область применения с помощью scope

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

Пример манифеста с областью действия, ограниченной /app/:

{
  "scope": "/app/",
  "start_url": "/app/",
  "display": "standalone"
}

При таком подходе фильтр намерений WebAPK будет использовать android:pathPrefix="/app/" чтобы открывать в приложении только то, что попадает под этот путь, оставляя остальную часть сайта для браузера.

Разрешения, уведомления и как ими управлять

Разрешения в WebAPK ведут себя как в любом веб-приложении.: Они не запрашиваются во время установки. Их следует запрашивать во время выполнения и, по возможности, именно в тот момент, когда пользователю нужна эта возможность (например, запрашивать камеру при съёмке фотографии, а не при загрузке домашней страницы).

Важный нюанс с уведомлениямиХотя Android обычно быстро предоставляет разрешения на уведомления установленным приложениям, WebAPK-приложения получают их не сразу. Ваше приложение должно явно запросить их во время выполнения, используя соответствующий веб-API, и пользователь увидит диалоговые окна Chrome, а не нативные окна Android.

Хранилище и состояние: чем оно делится с браузером

Несмотря на то, что установка представляет собой APK, данные WebAPK находятся в текущем профиле Chrome.Файлы cookie, клиентское хранилище (IndexedDB, localStorage, Cache Storage) и сервис-воркеры используются совместно с браузером. Это обеспечивает унифицированный интерфейс между версией браузера и установленным приложением.

Прямое следствие: если пользователь удаляет данные сайта или очищает профиль Chrome, это также повлияет на WebAPK.То есть установленное приложение не изолируется на уровне хранилища; оно пользуется преимуществами согласованности, но наследует удаленные файлы.

Обновления WebAPK: частота и триггеры

Chrome периодически просматривает манифест и решает, следует ли запрашивать и устанавливать новый WebAPK.. Частота обновления зависит от версии Chrome:

  • Chrome 76 и более поздние версии: попытки проверки каждый день. В редких случаях, когда сервер обновлений не может обработать изменения, интервал сокращается до 1 дней.
  • Chrome 75 и более ранние версии: Обычный цикл был каждые 3 дня с 30-дневным резервным копированием на случай сбоя сервера обновлений.

Гипотетический пример для Chrome 76+ Это будет выглядеть так: вы устанавливаете WebAPK 1 января; если вы открываете его 2 января, то через 24 часа начинается проверка обновлений; само по себе открытие Chrome не приводит к принудительной проверке; если вы очищаете данные Chrome (например, 6 января), то с точки зрения браузера следующий запуск WebAPK считается «первым», и отсчет дней до повторной проверки сбрасывается.

В Chrome 75- Поведение было аналогичным, но с 3-дневными окнами между проверками, когда все идет хорошо, и тем же 30-дневным запасным вариантом, если сервер не отвечает должным образом.

WebAPK, PWA и APK: соответствие и различия

APK — это формат пакета приложения Android, тогда как PWA — это веб-приложение, которое использует такие стандарты, как service works, manifest и HTTPS.WebAPK — это мост: браузер упаковывает PWA в «промежуточный» APK, чтобы интегрировать его в качестве установленного приложения.

На практике WebAPK «поднимает» поведение веб-сайта до уровня, привычного пользователю.: собственный значок, наличие в панели задач, многозадачность, удаление из настроек, намерения открывать ссылки, заставка и внутренний кэш, управляемый сервисным работником.

Исторически Chrome поддерживал этот подход.От простых веб-ярлыков и уведомлений до все более функциональных PWA; и, наконец, до WebAPK, которые выглядят как полноценные приложения, но при этом по-прежнему основаны на веб-технологиях.

Работники сферы услуг и работа в автономном режиме

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

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

Риски безопасности в PWA и WebAPK

Как и любая технология, PWA/WebAPK может стать объектом злоупотреблений при плохой реализации или развертывании.Некоторые векторы для рассмотрения:

  • Фишинг через PWA/WebAPK: Создание поддельных веб-приложений, устанавливаемых как WebAPK и выдающих себя за банковские приложения или сервисы. Внешний вид очень убедительный, а интеграция с Android снижает подозрения.
  • Преданные работники сферы услуг: может привести к отравлению кэша и постоянному отображению вредоносного контента.
  • Человек посередине (МитМ): Неправильная настройка HTTPS, сертификатов или политик HSTS открывает возможности для перехвата и манипуляции трафиком.
  • XSS (межсайтовый скриптинг)- Веб-приложения по своей природе уязвимы, если они не прошли надлежащую проверку/экранирование; XSS в установленном PWA особенно опасен, поскольку он влияет на приложение, которому пользователи доверяют больше.
  • Вредоносные скрипты от слабых CSP: Плохо определенная политика безопасности контента позволяет загружать небезопасные ресурсы или опасные встроенные скрипты.
  • CSRF- Отсутствие защиты конфиденциальных действий с помощью соответствующих токенов и заголовков может привести к выполнению несанкционированных запросов от имени аутентифицированного пользователя.
  • SQL-инъекция в бэкэнде- Не относится только к PWA, но все еще действует, если сервер не очищает входные данные.
  • Манипулирование APK: Неофициальные каналы могут распространять измененные APK-файлы, содержащие вредоносный код (хотя WebAPK, сгенерированный Chrome, не распространяется самостоятельно, это общий риск, если пользователь устанавливает сторонние пакеты).
  • Перцептивная устойчивость: После установки APK-файл можно удалить из хранилища, не останавливая работу приложения, что затрудняет обнаружение пользователем подозрительных артефактов.

Обнаружены реальные кампании: банковский случай, проанализированный ESET

Исследователи ESET задокументировали необычную фишинговую кампанию, нацеленную на клиентов мобильного банкинга., с упором на Чешскую Республику и отдельными случаями в Венгрии и Грузии. Этот метод был примечателен тем, что устанавливал фишинговое приложение со стороннего сайта без необходимости разрешения «неизвестных источников» со стороны пользователя.

  • На Android PWA превратился в WebAPK, который, судя по всему, был загружен из Google Play.В то время как на iOS жертве было предложено добавить PWA на главный экран. В обоих случаях полученные приложения были практически неотличимы от легитимных.
  • каналы распределенияАвтоматические звонки с предупреждением об «устаревшем банковском приложении» и отправка SMS-сообщений со ссылкой; массовые SMS-кампании; вредоносная реклама в социальных сетях с призывами к действию, например, «загрузить обновление». После открытия URL-адреса пользователь видел страницу, имитирующую страницу Play Store или клонированный сайт банковского приложения, и получал предложение установить «новую версию».
  • Инфраструктура злоумышленниковБыли замечены варианты, хранящие учётные данные через Telegram-бота, использующего официальный API, а также варианты, использующие традиционные серверы управления и контроля с административной панелью. Данные свидетельствуют о том, что за этой деятельностью стоят как минимум две отдельные группы.
  • Почему это возможно?PWA-приложения являются кроссплатформенными и при установке в виде WebAPK интегрируются в Android, не выводя предупреждений о «ненадёжном источнике», что обуславливает социальную эффективность этой схемы. ESET немедленно сообщила о результатах анализа пострадавшим банкам и совместно с ними блокировала фишинговые домены и командные серверы.

Передовая практика снижения рисков

  • Усиление защиты HTTPS и заголовков: Действительные сертификаты, HSTS, перенаправления HTTPS и строгая политика безопасности контента (CSP), ограничивающая источники скриптов/ресурсов.
  • Относитесь к сервисному работнику как к критическому программному обеспечению: проверки безопасности, чёткий контроль версий, безопасное аннулирование кэша и тестирование обновлений. Избегайте шаблонов, способствующих отравлению кэша.
  • Предотвращение XSS/CSRF: Очищает и экранирует входные данные, использует безопасные шаблоны, токены защиты от CSRF и заголовки SameSite для файлов cookie. Поддерживает целостность подресурсов (SRI) для внешних зависимостей.
  • Минимальное и контекстное управление разрешениями: Запрашивайте разрешения вовремя, предлагайте понятное и обратимое копирование; периодически проверяйте, какие разрешения еще нужны вашему приложению.
  • Регулярно обновляйте PWA и сервер- Устраняет известные уязвимости и проверяет, что Chrome обнаруживает и применяет новые WebAPK при изменении ключевых свойств манифеста.
  • Ответственное распределениеПоощряйте пользователей устанавливать приложение с вашего официального домена; предупреждайте их о рисках использования ссылок в SMS, звонках и рекламе. Если вы хотите опубликовать приложение в Play Маркете, используйте Trusted Web Activities вместо того, чтобы пытаться упаковать WebAPK, сгенерированный Chrome.
  • Мониторинг бренда и фишинга- Отслеживает похожие регистрации доменов, подозрительную рекламу и упоминания в социальных сетях; инструменты анализа угроз помогают вам реагировать до того, как ситуация обострится.