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

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

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

Основными строительными блоками приложений Android являются:

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

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

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

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

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

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

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

Эти защищенные API включают в себя:

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

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

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

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

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

Разрешения системы по умолчанию описаны по адресу https://developer.android.com/reference/android/Manifest.permission.html . Приложения могут объявлять свои собственные разрешения для использования другими приложениями. Такие разрешения не указаны в приведенном выше месте.

При определении разрешения атрибут ProtectionLevel сообщает системе, как пользователь должен быть проинформирован о приложениях, требующих разрешения, или о том, кому разрешено иметь разрешение. Подробности о создании и использовании разрешений для конкретных приложений описаны на странице https://developer.android.com/guide/topics/security/security.html .

Существуют некоторые возможности устройства, такие как возможность отправлять намерения широковещательной рассылки SMS, которые недоступны сторонним приложениям, но могут использоваться приложениями, предварительно установленными OEM. Эти разрешения используют разрешение SignatureOrSystem.

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

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

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

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

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

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

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

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

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

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

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

• Binder : легкий механизм удаленного вызова процедур на основе возможностей, предназначенный для высокой производительности при выполнении внутрипроцессных и межпроцессных вызовов. Binder реализован с использованием специального драйвера Linux. См. https://developer.android.com/reference/android/os/Binder.html .

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

• Намерения : Намерение — это простой объект сообщения, который представляет собой «намерение» что-то сделать. Например, если ваше приложение хочет отобразить веб-страницу, оно выражает свое «намерение» просмотреть URL-адрес, создавая экземпляр намерения и передавая его системе. Система находит какой-то другой фрагмент кода (в данном случае браузер), который знает, как обработать это намерение, и запускает его. Намерения также можно использовать для трансляции интересных событий (например, уведомлений) по всей системе. См. https://developer.android.com/reference/android/content/Intent.html .

• ContentProviders : ContentProvider — это хранилище данных, обеспечивающее доступ к данным на устройстве; Классический пример — ContentProvider, который используется для доступа к списку контактов пользователя. Приложение может получить доступ к данным, которые другие приложения предоставили через ContentProvider, а также приложение может определить свои собственные ContentProviders для предоставления собственных данных. См. https://developer.android.com/reference/android/content/ContentProvider.html .

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

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

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

• Телефония
• СМС/ММС
• Сеть/Данные
• Биллинг в приложении
• NFC-доступ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Центры сертификации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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