Безопасность приложений

На этой странице описаны различные аспекты безопасности приложений.

Элементы приложений

Android предоставляет платформу с открытым исходным кодом и среду разработки приложений для мобильных устройств. Основная операционная система основана на ядре Linux. Приложения для Android чаще всего пишутся на языке программирования Java и запускаются в виртуальной машине Android Runtime (ART). Однако приложения также могут быть написаны на нативном коде. Приложения устанавливаются из одного файла с расширением APK.

Основные компоненты, из которых состоит Android-приложение, следующие:

  • AndroidManifest.xml : Файл AndroidManifest.xml — это управляющий файл, который сообщает системе, что делать со всеми компонентами верхнего уровня (в частности, с действиями, службами, широковещательными приемниками и поставщиками контента, описанными ниже) в приложении. Он также определяет, какие разрешения необходимы.

  • Действия: Действие — это, как правило, код для выполнения одной задачи, ориентированной на пользователя, с использованием класса Activity . Действие обычно включает отображение пользовательского интерфейса пользователю, но это необязательно; некоторые действия никогда не отображают пользовательский интерфейс. Как правило, одно из действий приложения является точкой входа в приложение.

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

  • Приемник широковещательной рассылки: Приемник широковещательной рассылки — это объект класса BroadcastReceiver . Он создается, когда механизм межпроцессного взаимодействия, известный как намерение (intent), является экземпляром класса Intent и отправляется операционной системой или другим приложением. Приложение может зарегистрировать приемник, например, для сообщения о низком заряде батареи и изменить свое поведение на основе этой информации.

Модель разрешений Android: доступ к защищенным API.

Все приложения на Android работают в изолированной среде (Application Sandbox) . По умолчанию приложение Android может получить доступ только к ограниченному набору системных ресурсов. Система управляет доступом приложения Android к ресурсам, которые при неправильном или злонамеренном использовании могут негативно повлиять на пользовательский опыт, сеть или данные на устройстве.

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

К числу таких защищенных API относятся:

  • Функции камеры
  • Данные о местоположении (GPS)
  • функции Bluetooth
  • Функции телефонии
  • Функции SMS/MMS
  • Сетевые/передачи данных

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

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

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

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

Системные разрешения по умолчанию описаны в файле Manifest.permission . Приложения могут задавать собственные разрешения для использования другими приложениями. Такие разрешения не указаны в указанном выше месте.

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

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

Как пользователи понимают сторонние приложения

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

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

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

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

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

Разрешения при установке приложения — Google Translate Разрешения установленного приложения — Gmail
Разрешения при установке приложения — Google TranslateПрава доступа установленного приложения — Gmail

Рисунок 1. Отображение разрешений для приложений.

Межпроцессное взаимодействие

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

Android также предоставляет новые механизмы межпроцессного взаимодействия:

  • Binder: Легковесный механизм удаленного вызова процедур на основе возможностей, разработанный для обеспечения высокой производительности при выполнении внутрипроцессных и межпроцессных вызовов. Binder реализован с использованием пользовательского драйвера Linux. Описание класса см. в разделе Binder .

  • Сервисы: Сервисы могут предоставлять интерфейсы, доступ к которым осуществляется непосредственно через Binder. Более подробное описание см. в разделе «Элементы приложений».

  • Интенты: Интент — это простой объект сообщения, представляющий намерение выполнить какое-либо действие. Например, если ваше приложение хочет отобразить веб-страницу, оно выражает свое намерение просмотреть URL-адрес, создавая экземпляр интента и передавая его системе. Система находит другой фрагмент кода (в данном случае, браузер), который знает, как обработать этот интент, и выполняет его. Интенты также можно использовать для трансляции важных событий (например, уведомлений) в масштабах всей системы. Описание класса см. в разделе «Интенты» .

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

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

API, чувствительные к стоимости

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

  • Телефония
  • SMS/MMS
  • Сеть/Данные
  • Встроенные платежи в приложение
  • Доступ по NFC

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

доступ к SIM-карте

Низкоуровневый доступ к SIM-карте недоступен для сторонних приложений. Операционная система обрабатывает все коммуникации с SIM-картой, включая доступ к личной информации (контактам) в памяти SIM-карты. Приложения также не могут получить доступ к AT-командам, поскольку они управляются исключительно уровнем радиоинтерфейса (RIL). RIL не предоставляет высокоуровневых API для этих команд.

Персональная информация

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

Доступ к конфиденциальным пользовательским данным предоставляется только через защищенные API.

Рисунок 2. Доступ к конфиденциальным данным пользователей возможен только через защищенные API.

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

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

Устройства ввода конфиденциальных данных

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

Если приложению требуется узнать местоположение пользователя, ему необходимо получить разрешение на доступ к этому местоположению. При установке программа установки запрашивает у пользователя разрешение на доступ к местоположению. В любой момент, если пользователь не хочет, чтобы какое-либо приложение получало доступ к его местоположению, он может открыть приложение «Настройки», перейти в раздел «Местоположение и безопасность» и снять флажки с пунктов « Использовать беспроводные сети» и «Включить спутники GPS» . Это отключит службы определения местоположения для всех приложений на устройстве пользователя.

метаданные устройства

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

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

Сертификационные центры

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

Чтобы быть добавленным в качестве нового публичного центра сертификации (ЦС) в стандартный набор ЦС Android, ЦС должен пройти процедуру включения ЦС Mozilla , а затем подать запрос на добавление функции в Android ( https://code.google.com/p/android/issues/entry ), чтобы его добавили в стандартный набор ЦС Android в проекте Android Open Source Project (AOSP).

Существуют центры сертификации, специфичные для конкретных устройств и не подлежащие включению в основной набор центров сертификации AOSP, например, частные центры сертификации операторов связи, которые могут потребоваться для безопасного доступа к компонентам инфраструктуры оператора, таким как шлюзы SMS/MMS. Производителям устройств рекомендуется включать частные центры сертификации только в те компоненты/приложения, которым необходимо доверять этим центрам. Для получения более подробной информации см. раздел «Конфигурация сетевой безопасности» .

Подписание приложений

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

В Google Play подпись приложений скрепляет доверие Google к разработчику и доверие разработчика к своему приложению. Разработчики знают, что их приложение предоставляется на устройства Android без изменений, и могут нести ответственность за поведение своего приложения.

На Android подписание приложения — это первый шаг к размещению приложения в его «песочнице». Подписанный сертификат приложения определяет, какой идентификатор пользователя связан с каким приложением; разные приложения работают под разными идентификаторами пользователей. Подписание приложения гарантирует, что одно приложение не сможет получить доступ к другому приложению, кроме как через четко определенные межпроцессные соединения (IPC).

При установке приложения (APK-файла) на устройство Android менеджер пакетов проверяет, правильно ли подписан APK-файл с помощью сертификата, входящего в состав этого APK. Если сертификат (или, точнее, открытый ключ в сертификате) совпадает с ключом, используемым для подписи любого другого APK-файла на устройстве, новый APK-файл может указать в манифесте, что он использует тот же UID, что и другие аналогично подписанные APK-файлы.

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

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

Проверка приложения

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

Управление цифровыми правами

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

Архитектура DRM-системы Android реализована в двух слоях (см. рисунок 3):

  • API-интерфейс DRM-фреймворка, предоставляемый приложениям через Android-фреймворк и работающий на виртуальной машине ART для стандартных приложений.

  • Менеджер DRM нативного кода, реализующий фреймворк DRM и предоставляющий интерфейс для плагинов DRM (агентов) для управления правами и расшифровки для различных схем DRM.

Архитектура управления цифровыми правами на платформе Android

Рисунок 3. Архитектура DRM на платформе Android.